idnits 2.17.1 draft-ietf-rserpool-tcpmapping-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 752. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 742. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 2005) is 6770 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 672, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 692, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '3') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2960 (ref. '4') (Obsoleted by RFC 4960) == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '7') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '8') Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Lei 3 Internet-Draft Cisco Systems, Inc. 4 Expires: April 9, 2006 P. Conrad 5 University of Delaware 6 October 6, 2005 8 TCP Mapping for Reliable Server Pooling Enhanced Mode 9 draft-ietf-rserpool-tcpmapping-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 9, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This memo defines the shim protocol that maps the requirements of the 43 ASAP protocol [5] to the capabilities of the TCP protocol [3]. In 44 particular, this shim protocol adds the following capabilties that 45 are required by ASAP, but not provided by TCP: (1) message 46 orientation, (2) heartbeat messages, (3) multiple streams, and (4) 47 undelivered message retrieval (if provided). 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Brief overview of RSerPool . . . . . . . . . . . . . . . . 3 53 1.2. Role of the TCP Mapping Protocol . . . . . . . . . . . . . 3 54 1.3. Consistency of Service . . . . . . . . . . . . . . . . . . 5 55 2. Conventions Used In This Document . . . . . . . . . . . . . . 6 56 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Basic Chunk Format . . . . . . . . . . . . . . . . . . . . 6 58 3.2. DATA Chunk . . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.3. INIT Chunk . . . . . . . . . . . . . . . . . . . . . . . . 11 60 3.4. ACK Chunk . . . . . . . . . . . . . . . . . . . . . . . . 13 61 3.5. HEARTBEAT Chunk . . . . . . . . . . . . . . . . . . . . . 14 62 3.6. HEARTBEAT ACK Chunk . . . . . . . . . . . . . . . . . . . 15 63 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 16 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 69 Intellectual Property and Copyright Statements . . . . . . . . . . 19 71 1. Introduction 73 This memo defines the shim protocol that maps the requirements of the 74 ASAP protocol [5] to the capabilities of the TCP protocol [3]. See 75 [6] for details of these mapping requirements. 77 1.1. Brief overview of RSerPool 79 The RSerPool framework is designed to provide high availability for 80 client/server applications. Servers (called "pool elements" or 81 "PEs") are grouped into "pools". Each pool is named by a "pool 82 handle", which is simply an octet string that identifies the pool. 83 PEs join or leave a pool by registering and deregistering with an 84 RSerPool nameserver (called an "ENRP server", after the ENRP protocol 85 [8] that is used to share information among RSerPool nameservers). 87 Clients (called "pool users" or "PUs") that want to obtain service 88 contact the ENRP server; the PU provides a pool handle, and the ENRP 89 server returns a list of available servers. Associated with each 90 server is a policy value; the PU then uses a "pool element selection 91 policy" (such as round robin, or least used) to determine which of 92 the PEs to contact. 94 The ASAP protocol [5] is used to communicate between the PU and the 95 ENRP server, and between the PE and ENRP server, while the ENRP 96 protocol [8] is used to communicate between and among RSerPool ENRP 97 nameservers. 99 The RSerPool services framework provides two distinct channels, 100 control and data, for delivery of RSerPool control messages and 101 application layer data messages. Mappings provide the adaptions of 102 the ASAP services to the specific transport protocols. 104 1.2. Role of the TCP Mapping Protocol 106 The actual application-specific communication between the PU and PE 107 is defined by the application layer protocol, and does not use the 108 ASAP protocol, per se. However, when failover services (such as 109 forwarding of undelivered/unacknowledged messages) are desired by the 110 application, all communication between a PU and a PE takes place 111 through services provided by RSerPool, and more specifically, by the 112 ASAP entity on the PU or PE. Furthermore, in order for the RSerPool 113 framework to provide a consistent set of services for both 114 application-specific data and RSerPool messages, this transport 115 service must follow a particular model. This model includes features 116 that are present in SCTP, but are lacking in TCP. Specifically, 117 these are: 119 (1) Message Orientation. Messages must be framed within the TCP byte 120 stream to allow for undelivered message retrieval (see below), and 121 so that ASAP transport services can be consistent between SCTP and 122 TCP. 124 (2) Heartbeat Messages. Heartbeats are needed so that a failed 125 connection can be detected in a timely manner, even if that 126 connection is idle. The "keepalive" mechanism provided in some 127 TCP implementations (but not a standard feature of the protocol; 128 see RFC1122) is not sufficient for this purpose. 130 (3) Retreival of Undelivered Messages. A PU can request that the ASAP 131 layer detects when the transport layer association/connection 132 between that PU and some PE has failed, and automatically failover 133 to a new PE. In this case, it is necessary for the ASAP layer to 134 determine which messages were not successfully delivered to the 135 PE, retrieve them from the transport layer below, and resend them 136 to the new PE. SCTP provides the RETRIEVE_UNSENT primitive 137 (Section 10.1, item (E) of RFC2960) to enable this retrieval. TCP 138 has no such facility. 140 To provide this capability over TCP, the mapping protocol provides 141 another layer of acknowledgements on top of TCP; these acks are 142 sent only when a message is actually delivered to the end system 143 application (as opposed to when the message is handed up from the 144 IP layer to the TCP layer). The sending side buffers messages 145 until this acknowledgement is received, so that in the event of 146 failover, these messages can be retrieved by the ASAP entity, and 147 resent to the new PE. 149 This feature is optional and is NOT required. However, an 150 appropriate error code must be returned to the upper layer if this 151 feature is requested, but is unavailable (not implemented). 153 (4) Other features present in SCTP. Two other features present in 154 SCTP are simulated by the TCP mapping layer, namely the multiple 155 streams feature and the protocol payload identifier field (PPID). 156 Strictly speaking these features are not necessary for RSerPool 157 operation. However, it is trivial to provide these features in 158 the TCP mapping layer, and providing them offers an important 159 benefit, without significantly increasing the complexity of the 160 protocol or the on-the-wire overhead. This is discussed further 161 in Section 1.3 163 NOTE: PU-PE communication that is NOT mediated by the RSerPool 164 framework is allowable when the application layer does not require 165 data channel services. In this case, no mapping for application 166 layer data is used regardless of the transport protocol used as they 167 will be tranported over the appropriate application-defined tranport 168 protocol. 170 1.3. Consistency of Service 172 The main benefit of including provision for multiple streams and the 173 PPID field in the RSerPool TCP mapping protocol is "consistency of 174 service." By "consistency of service", we mean that the data 175 transport service provided by RSerPool is consistent regardless of 176 the underlying transport protocol used. 178 To see the benefit of consistency of service, consider an RSerPool 179 enabled application that will be used by clients with a wide range of 180 capabilities, e.g. wired desktop PCs at the one end, down to PDAs or 181 cell phones at the other. On some of these platforms, SCTP may be 182 available, while on others, only TCP will be available. If the 183 multiple stream and PPID features are provided in the TCP mapping, 184 then the application designer can design once to a single API, where 185 regardless of the underlying transport used, multiple streams can be 186 used to multiplex various kinds of messages. On PUs where SCTP is 187 supported, an additional benefit is available, in that partial order 188 delivery allows head of line blocking to be avoided. This is not the 189 case for the systems where the TCP mapping is used, since all streams 190 are mapped onto a single ordered TCP byte-stream. However, either 191 way, the application designer doesn't have to be concerned; one can 192 write to a single API, and the software will function correctly over 193 either protocols, taking advantage of optimizations where available. 195 The alternative is to omit these features from the TCP mapping, and 196 indicate that when the underlying protocol is TCP, that all data is 197 implicitly sent over stream zero, and that the PPID field is ignored. 198 However, this will encourage designers of application that run in a 199 "mixed" environment to write to the "lowest common denominator" of 200 functionality to avoid having to maintain special case code for each 201 transport layer mapping. Thus, few applications will take advantage 202 of the features offered by SCTP. The result may be that application 203 with multiple streams will do their own multiplexing within the 204 application layer protocol, send all data over stream zero, thus 205 defeating the SCTP mechanism for avoiding head of line blocking. 206 Similiarly, few applications will take advantage of the PPID field, 207 meaning that it will be wasted space in the case where SCTP is 208 available. 210 Of course, providing these extra features is not without some cost; 211 in particular extra fields in the protocol header, and extra 212 complexity in the implementation. Our compromise solution to the 213 overhead of the extra fields is to include them in the data chunk 214 definition, however to allow the service user to turn them off as an 215 optimization if they are not going to be used (see Section 3.3 and 216 Section 3.2 for more details.) 218 As for the complexity, it turns out that because the TCP byte-stream 219 preserves the order of each stream, providing for multiple streams is 220 trivial; it involves only passing the stream number through just as 221 the PPID is "passed through". 223 Thus, for minimal extra cost, "consistency of service" is preserved 224 by including multiple streams and the PPID field in the TCP mapping. 225 It is RECOMMENDED that any future mappings of RSerPool to other 226 transport protocols SHOULD follow this model of providing 227 "consistency of service" where possible. 229 2. Conventions Used In This Document 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in RFC 2119 [2]. 235 The terms "transmission sequence number" (TSN), "stream number", 236 "stream identifier", "stream sequence number", and "payload protocol- 237 id(PPID)" are used in this document with meanings analogous to their 238 meanings in RFC2960 [4]; it is assumed that the reader is familiar 239 with these terms as they appear in that document. 241 Comparisons and arithmetic on TSNs and stream sequence numbers are 242 governed by the rules in Section 1.6 of RFC2960 [4]. 244 3. Packet Format 246 In the RSerPool TCP mapping protocol, each peer transmits a series of 247 chunks over the TCP byte stream. The format of these chunks is 248 similar to that of the chunk format of SCTP. 250 3.1. Basic Chunk Format 252 The figure below illustrates the field format for the chunks to be 253 transmitted in the SCTP packet. Each chunk is formatted with a Chunk 254 Type field, a chunk-specific Flag field, a Chunk Length field, and a 255 Value field. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Chunk Type | Chunk Flags | Chunk Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 \ \ 263 / Chunk Value / 264 \ \ 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Chunk Type: 8 bits (unsigned integer) 268 This field identifies the type of information contained in the 269 Chunk Value field. It takes a value from 0 to 254. The value 270 of 255 is reserved for future use as an extension field. 272 The values of Chunk Types are defined as follows: 274 ID Value Chunk Type 275 -------- ---------- 276 0 - Payload Data (DATA) 277 1 - Initiation (INIT) 278 2 - reserved by IETF 279 3 - Acknowledgement (ACK) 280 4 - Heartbeat Request (HEARTBEAT) 281 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 282 6 to 255 - reserved by IETF 284 Chunk Flags: 8 bits 286 The usage of these bits depends on the chunk type as given by 287 the Chunk Type. Unless otherwise specified, they are set to 288 zero on transmit and are ignored on receipt. 290 Chunk Length: 16 bits (unsigned integer) 292 This value represents the size of the chunk in bytes including 293 the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value 294 fields. Therefore, if the Chunk Value field is zero-length, the 295 Length field will be set to 4. The Chunk Length field does not 296 count any padding. 298 Chunk Value: variable length 300 The Chunk Value field contains the actual information to be 301 transferred in the chunk. The usage and format of this field 302 is dependent on the Chunk Type. 304 The total length of a chunk (including Type, Length and Value 305 fields) MUST be a multiple of 4 bytes. If the length of the chunk 306 is not a multiple of 4 bytes, the sender MUST pad the chunk with 307 all zero bytes and this padding is not included in the chunk 308 length field. The sender should never pad with more than 3 bytes. 309 The receiver MUST ignore the padding bytes. 311 3.2. DATA Chunk 313 The figure below illustrates the field format for the DATA chunk. 314 Note that it is nearly identical to the format of the DATA chunk in 315 SCTP. The following differences should be noted: (1) No B and E bits 316 for fragmentation (2) the second, third, and fourth 32-bit words are 317 all optional, and can be supressed (independently) through flags in 318 the INIT message (as explained further below.) 320 All ASAP protocol messages and application-layer data (when sent 321 through the RSerPool framework data channel) MUST be carried in DATA 322 chunks. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type = 0 | Reserved|U|R R| Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | TSN | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Stream Identifier S | Stream Sequence Number n | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Payload Protocol Identifier | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 \ \ 336 / User Data (seq n of Stream S) / 337 \ \ 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Reserved, and bits marked "R": 5 bits and 2 bits, respectively 342 The sender SHOULD set all '0's and the receiver SHOULD ignore. 344 U bit: 1 bit 346 The (U)nordered bit, if set to '1', indicates that this is an 347 unordered DATA chunk, and there is no Stream Sequence Number 348 assigned to this DATA chunk. Therefore, the receiver MUST 349 ignore the Stream Sequence Number field. 351 Length: 16 bits (unsigned integer) 353 This field indicates the length of the DATA chunk in bytes from 354 the beginning of the type field to the end of the user data 355 field excluding any padding. 357 TSN : 32 bits (unsigned integer) 359 This value represents the TSN for this DATA chunk. The valid 360 range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps 361 back to 0 after reaching 4294967295. In the TCP mapping 362 protocol (unlike in SCTP), this field MUST start at 0 with each 363 new connection. Also note that this field is redundant; TSN of 364 each data chunk is implicit by its position in the TCP byte 365 stream. It does server the purpose of providing additional 366 robustness against errors in a sender or receiver protocol 367 implementation, however if desired, it MAY be supressed for the 368 lifetime of the TCP connection via a flag in the INIT chunk. 370 Stream Identifier S: 16 bits (unsigned integer) 372 Identifies the stream to which the following user data belongs. 373 if desired, the entire 32-bit word containing Stream Identifier 374 and Stream Sequence Number MAY be supressed to save bandwidth; 375 in this case, all data chunks MUST be interpreted by the receiver 376 to be part of stream 0, and should be delivered to the end user 377 as such. 379 Stream Sequence Number n: 16 bits (unsigned integer) 381 This value represents the stream sequence number of the following 382 user data within the stream S. Valid range is 0 to 65535. Note 383 that this field, like TSN, is redundant, but it provides extra 384 robustness. 386 Note that unlike SCTP, there is no concept of fragmentation in 387 the TCP mapping protocol. 389 Payload Protocol Identifier: 32 bits (unsigned integer) 391 This value represents an application (or upper layer) specified 392 protocol identifier. This value is passed to the TCP mapping 393 layer from the upper layer and sent to its peer. This identifier 394 is not used by the TCP mapping layer but can be used by certain 395 network entities as well as the peer application to identify the 396 type of information being carried in this DATA chunk. 398 The IANA assigned SCTP protocol payload identifier value for 399 ASAP (11) MUST be used for the transport of ASAP messages (eg. 400 RSerPool control channel messages). 402 The value 0 indicates no application identifier is specified by 403 the upper layer for this payload data. If the application has 404 no use for this field, it can be supressed for all data chunks 405 over the lifetime of the TCP connection via a flag in the INIT 406 message. 408 User Data: variable length 410 This is the payload user data. The implementation MUST pad the 411 end of the data to a 4 byte boundary with all-zero bytes. Any 412 padding MUST NOT be included in the length field. A sender MUST 413 never add more than 3 bytes of padding. 415 3.3. INIT Chunk 417 The figure below illustrates the field format for the INIT chunk. 418 The INIT chunk is transmitted only once at the beginning of the TCP 419 connection. The purpose of the INIT chunk is to transmit flags 420 indicating which fields will be enabled/disabled in all subsequent 421 data chunks over the lifetime of the TCP connection. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type = 1 |reservd |P|S|T| Chunk Length = 4 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Chunk Type: 8 bits (unsigned integer) 431 0x01, indicating INIT chunk 433 Chunk Flags: 8 bits 435 The five high order bits are reserved; the sender SHOULD 436 set them to zero, and the receiver SHOULD ignore them. 438 The three low order bits are to be intepreted as follows; 440 0x01: The TSN value is omitted in subsequent DATA chunks. 441 Additionally, this indicates that the receiver of the 442 INIT chunk SHOULD omit the TSN on ACK chunks. 443 0x02: The Stream Number/Stream Seq Number is omitted in 444 subsequent DATA chunks 445 0x04: The PPID value is omitted in subsequent DATA chunks 447 Chunk Length: 16 bits (unsigned integer) 449 MUST be set to 0x0004. 451 NOTE: Unlike SCTP, there is no INIT-ACK defined in the RSerPool TCP 452 mapping protocol. 454 The following examples illustrate the use of the flags in the INIT 455 message. 457 Example 1: Flags in the INIT are 0x00. Data chunk format is: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type = 0 | Reserved|U|R R| Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | TSN | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Stream Identifier S | Stream Sequence Number n | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Payload Protocol Identifier | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 \ \ 471 / User Data (seq n of Stream S) / 472 \ \ 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Example 2: Flags in the INIT are 0x01. Data chunk format is: 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type = 0 | Reserved|U|R R| Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Stream Identifier S | Stream Sequence Number n | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Payload Protocol Identifier | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 \ \ 487 / User Data (seq n of Stream S) / 488 \ \ 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 In this example, TSN is implicit from the order in which the chunk 492 appears in the TCP byte stream. 494 Example 3: Flags in the INIT are 0x05. Data chunk format is: 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type = 0 | Reserved|U|R R| Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Stream Identifier S | Stream Sequence Number n | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 \ \ 504 / User Data (seq n of Stream S) / 505 \ \ 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 In this example, TSN is implicit from the order in which the chunk 509 appears in the TCP byte stream, and PPID is treated as zero. 511 Example 4: Flags in the INIT are 0x07. Data chunk format is: 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Type = 0 | Reserved|U|R R| Length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 \ \ 519 / User Data (seq n of Stream S) / 520 \ \ 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 In this example, TSN and Stream Sequence Number are implicit from 524 the order in which the chunk appears in the TCP byte stream, and 525 Stream Identifier and PPID are always considered zero. 527 3.4. ACK Chunk 529 The figure below illustrates the field format for the ACK chunk. An 530 RSerPool TCP mapping layer entity MUST transmit exactly one 531 corresponding ACK chunk over the TCP connection immediately after 532 delivering each DATA chunk to the upper layer. Each such ACK chunk 533 SHOULD contain the TSN corresponding to the DATA chunk that was 534 delivered, unless inclusion of the TSN has been supressed by receipt 535 of the 0x01 flag value in a previous INIT chunk from the data sender 536 to the data receiver. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type = 3 |Chunk Flags | Chunk Length | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Cumulative TSN Ack | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Chunk Flags: 8 bits 548 Set to all zeros on transmit and ignored on receipt. 550 Cumulative TSN Ack: 32 bits (unsigned integer) 552 This field is OPTIONAL, and SHOULD NOT be included if the side 553 sending the ack previously received a value of 0x01 in the INIT 554 from the peer. The receiver of an ACK chunk can determine 555 whether the TSN field is present by checking whether the length 556 of the ACK chunk is 4 bytes or 8 bytes. 558 This field contains the TSN of the last DATA chunk delivered to 559 the upper layer protocol. Note that this value is implicit from 560 the position of the ACK chunk in the TCP byte stream. 562 3.5. HEARTBEAT Chunk 564 The figure below illustrates the field format for the HEARTBEAT 565 chunk. 567 The parameter field contains the Heartbeat Information which is 568 a variable length opaque data structure understood only by the 569 sender. 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Type = 4 | Chunk Flags | Heartbeat Length | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 \ \ 577 / Heartbeat Information TLV (Variable-Length) / 578 \ \ 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Chunk Flags: 8 bits 583 Set to zero on transmit and ignored on receipt. 585 Heartbeat Length: 16 bits (unsigned integer) 587 Set to the size of the chunk in bytes, including the chunk header 588 and the Heartbeat Information field. 590 Heartbeat Information: variable length 592 Defined as a variable-length parameter using the format described 593 in Section 3.2.1, i.e.: 595 Variable Parameters Status Type Value 596 ------------------------------------------------------------- 597 Heartbeat Info Mandatory 1 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Heartbeat Info Type=1 | HB Info Length | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 / Sender-specific Heartbeat Info / 605 \ \ 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 3.6. HEARTBEAT ACK Chunk 610 The figure below illustrates the field format for the HEARTBEAT ACK 611 chunk. The RSerPool TCP mapping layer MUST transmit exactly one 612 HEARTBEAT ACK chunk in response to each HEARTBEAT chunk received. 613 The Heartbeat Information parameter received in the HEARTBEAT chunk 614 MUST be included in the HEARTBEAT ACK chunk. 616 The parameter field contains a variable length opaque data 617 structure which was received in the HEARTBEAT. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Type = 5 | Chunk Flags | Heartbeat Ack Length | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 \ \ 625 / Heartbeat Information TLV (Variable-Length) / 626 \ \ 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Chunk Flags: 8 bits 631 Set to zero on transmit and ignored on receipt. 633 Heartbeat Ack Length: 16 bits (unsigned integer) 635 Set to the size of the chunk in bytes, including the chunk header 636 and the Heartbeat Information field. 638 Heartbeat Information: variable length 640 This field MUST contain the Heartbeat Information parameter of 641 the Heartbeat Request to which this Heartbeat Acknowledgement is 642 responding. 644 Variable Parameters Status Type Value 645 ------------------------------------------------------------- 646 Heartbeat Info Mandatory 1 648 4. Protocol Operations 650 [TBD: In this section describe the basic operation of the protocol. 651 Most of this is already pretty much spelled out in the descriptions 652 of the packets, but a few details need to be ironed out, mainly how 653 and under what conditions the TCP mapping layer decides that a 654 failure occured. Perhaps the upper layer needs to be able to specify 655 a timeout value for data, and a heartbeat interval? Are there any 656 other details that need to specified in this section?] 658 5. Security Considerations 660 There are no known additional security considerations over what is 661 already present for TCP. 663 6. IANA Considerations 665 [Open Issue TBD: Will there be an enumeration of the various 666 transport layer mappings that must be registered with IANA?] 668 7. Acknowledgements 670 8. References 672 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 673 BCP 9, RFC 2026, October 1996. 675 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 676 Levels", BCP 14, RFC 2119, March 1997. 678 [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 679 September 1981. 681 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 682 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 683 "Stream Control Transmission Protocol", RFC 2960, October 2000. 685 [5] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 686 draft-ietf-rserpool-asap-12 (work in progress), July 2005. 688 [6] Lei, P. and P. Conrad, "Services Provided By Reliable Server 689 Pooling", draft-ietf-rserpool-service-02 (work in progress), 690 October 2005. 692 [7] Tuexen, M., "Architecture for Reliable Server Pooling", 693 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 695 [8] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 696 draft-ietf-rserpool-enrp-12 (work in progress), July 2005. 698 Authors' Addresses 700 Peter Lei 701 Cisco Systems, Inc. 702 8735 W Higgins Rd, Suite 300 703 Chicago, IL 60631 704 US 706 Phone: +1 773 695 8201 707 Email: peterlei@cisco.com 709 Phillip T. Conrad 710 University of Delaware 711 Dept. of Computer and Information Sciences 712 103 Smith Hall 713 Newark, DE 19716 714 US 716 Phone: +1 302 831 8622 717 Email: conrad@acm.org 718 URI: http://udel.edu/~pconrad 720 Intellectual Property Statement 722 The IETF takes no position regarding the validity or scope of any 723 Intellectual Property Rights or other rights that might be claimed to 724 pertain to the implementation or use of the technology described in 725 this document or the extent to which any license under such rights 726 might or might not be available; nor does it represent that it has 727 made any independent effort to identify any such rights. Information 728 on the procedures with respect to rights in RFC documents can be 729 found in BCP 78 and BCP 79. 731 Copies of IPR disclosures made to the IETF Secretariat and any 732 assurances of licenses to be made available, or the result of an 733 attempt made to obtain a general license or permission for the use of 734 such proprietary rights by implementers or users of this 735 specification can be obtained from the IETF on-line IPR repository at 736 http://www.ietf.org/ipr. 738 The IETF invites any interested party to bring to its attention any 739 copyrights, patents or patent applications, or other proprietary 740 rights that may cover technology that may be required to implement 741 this standard. Please address the information to the IETF at 742 ietf-ipr@ietf.org. 744 Disclaimer of Validity 746 This document and the information contained herein are provided on an 747 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 748 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 749 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 750 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 751 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 752 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 754 Copyright Statement 756 Copyright (C) The Internet Society (2005). This document is subject 757 to the rights, licenses and restrictions contained in BCP 78, and 758 except as set forth therein, the authors retain all their rights. 760 Acknowledgment 762 Funding for the RFC Editor function is currently provided by the 763 Internet Society.