idnits 2.17.1 draft-ietf-sigtran-reliable-udp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 8) being 445 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 94 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 296 has weird spacing: '...be saved for ...' -- 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 (25 Feburary 1999) is 9254 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 733, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 737, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 740, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 743, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 746, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 755, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 758, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 761, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 766, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '3') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Experimental RFC: RFC 908 (ref. '4') ** Downref: Normative reference to an Experimental RFC: RFC 1151 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1071 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2001 (ref. '8') (Obsoleted by RFC 2581) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bova 3 INTERNET-DRAFT T. Krivoruchka 4 Cisco Systems 6 Expires in six months 25 Feburary 1999 8 RELIABLE UDP PROTOCOL 9 11 Status of This Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC 2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This Internet Draft discusses Reliable UDP (RUDP). RUDP is a simple 33 packet based transport protocol. RUDP is based on RFCs 1151 and 908 - 34 Reliable Data Protocol. RUDP is layered on the UDP/IP Protocols and 35 provides reliable in-order delivery (up to a maximum number of 36 retransmissions) for virtual connections. RUDP has a very flexible 37 design that would make it suitable for a variety of transport uses. 38 One such use would be to transport telecommunication signaling 39 protocols. 41 Bova & Krivoruchka [Page 1] 42 TABLE OF CONTENTS 44 1. Introduction...............................................3 45 1.1 System Overview.......................................3 46 1.2 Background............................................5 47 1.3 Data Structure Format.................................5 48 1.4 Feature Negotiation..................................16 49 2. Future Potential Enhancements.............................16 50 3. References................................................17 51 4. Author's Addresses........................................17 53 Bova & Krivoruchka [Page 2] 54 1. Introduction 56 This Internet Draft discusses a simple packet based transport 57 protocol designed to support applications that require a 58 reliable, sequenced packet based transport protocol. RUDP is based 59 on RFCs 1151 and 908 - Reliable Data Protocol. RUDP is layered on 60 the UDP/IP Protocols and provides reliable in-order delivery (up to 61 a maximum number of retransmissions) for virtual connections. 63 1.1 Background 65 A reliable transport protocol is needed to transport of telephony signaling 66 across IP networks. This reliable transport must be able to provide an 67 architecture for a variety of applications (i.e. signaling protocols) 68 requiring transport over IP. 70 Existing IP protocols have been scrutinized and it has been concluded that 71 a new reliable transport mechanism for telecommunication signaling 72 protocols is needed. This protocol should meet the following criteria: 74 * transport should provide reliable delivery up to a maximum number of 75 retransmissions (i.e. avoid stale signaling messages). 76 * transport should provide in-order delivery. 77 * transport should be a message based. 78 * transport should provide flow control mechanism. 79 * transport should have low overhead, high performance. 80 * characteristics of each virtual connection should be configurable 81 (i.e. timers). 82 * transport should provide a keep-alive mechanism. 83 * transport should provide error detection. 84 * transport should provide for secure transmission. 86 RUDP is designed to allow characteristics of each connection to be 87 individually configured so that many protocols with different transport 88 requirements can be implemented simultaneously on the same platform. 90 1.3 Data Structure Format 92 1. Six octet minimum RUDP header for data transmissions 94 Each UDP packet sent by RUDP must start with at least a six octet header. 95 The first octet contains a series of single bit flags. The next three 96 fields are each one octet in size. They are: Header length, Sequence 98 Bova & Krivoruchka [Page 3] 99 number, and Acknowledgment number. These three octets are followed by a 100 two octet checksum. 102 0 1 2 3 4 5 6 7 8 15 103 +-+-+-+-+-+-+-+-+---------------+ 104 |S|A|E|R|N|C|T| | Header | 105 |Y|C|A|S|U|H|C|0| Length | 106 |N|K|K|T|L|K|S| | | 107 +-+-+-+-+-+-+-+-+---------------+ 108 | Sequence # + Ack Number | 109 +---------------+---------------+ 110 | Checksum | 111 +---------------+---------------+ 113 Figure 1, RUDP Header 115 Control bits 117 The control bits indicate what is present in the packet. The SYN bit 118 indicate a synchronization segment is present. The ACK bit indicates the 119 acknowledgment number in the header is valid. The EACK bit indicates an 120 extended acknowledge segment is present. The RST bit indicates the packet 121 is a reset segment. The NUL bit indicates the packet is a null segment. 122 The TCS bit indicates the packet is a transfer connection state segment. 123 The SYN, EACK, RST, and TCS bits are mutually exclusive. The ACK bit is 124 always set when the NUL bit is set. The CHK bit indicates whether the 125 Checksum field contains the checksum of just the header or the header 126 and the body (data). If the CHK bit is zero, the Checksum field only 127 contains the checksum of the header. If the CHK bit is one, the 128 Checksum field contains the checksum of the header and data. 130 Header length. 132 The Header length field indicates where user data begins in the packet. 133 If total length of the packet is greater than the value of the header 134 length field, user data exists in the packet. User data cannot be present 135 in packets with the EACK, NULL, or RST bits set. A packet with user data 136 in it always has the ACK bit set and is called a data segment. 138 Sequence number. 140 Each packet contains a sequence number. When a connection is first opened, 141 each peer randomly picks an initial sequence number. This sequence number 142 is used in the SYN segments to open the connection. Each transmitter 143 increments the sequence number before sending a data, null, or reset 144 segment. 146 Bova & Krivoruchka [Page 4] 147 Acknowledgment Number. 149 The acknowledgment number field indicates to a transmitter the last in- 150 sequence packet the receiver has received. 152 Checksum. 154 A checksum is always calculated on the RUDP header to ensure integrity. 155 In addition, the checksum can be calculated on the header and body 156 if the CHK bit is set to one. The checksum algorithm used in RUDP is 157 the same algorithm used in UDP and TCP headers which is the 16-bit 158 one's complement of the one's complement sum of bytes being checksumed. 160 2. SYN Segment 162 The SYN is used to establish a connection and synchronize sequence numbers 163 between two hosts. The SYN segment also contains the negotiable parameters 164 of the connection. All configurable parameters that the peer must know 165 about are contained in this segment. This includes the maximum number of 166 segments the local RUDP is willing to accept and option flags that indicate 167 the features of the connection being established. A SYN segment must not 168 be combined with user data. A SYN segment is also used to perform an auto 169 reset on a connection. Auto reset is described later. 171 Figure 2 shows a SYN segment. 173 Bova & Krivoruchka [Page 5] 174 0 7 8 15 175 +-+-+-+-+-+-+-+-+---------------+ 176 | |A| | | | | | | | 177 |1|C|0|0|0|0|0|0| 28 | 178 | |K| | | | | | | | 179 +-+-+-+-+-+-+-+-+---------------+ 180 + Sequence # + Ack Number | 181 +---------------+---------------+ 182 | Vers | Spare | Max # of Out | 183 | | | standing Segs | 184 +---------------+---------------+ 185 | Option Flags | Spare | 186 +---------------+---------------+ 187 | Maximum Segment Size | 188 +---------------+---------------+ 189 | Retransmission Timeout Value | 190 +---------------+---------------+ 191 | Cumulative Ack Timeout Value | 192 +---------------+---------------+ 193 | Null Segment Timeout Value | 194 +---------------+---------------+ 195 | Transfer State Timeout Value | 196 +---------------+---------------+ 197 | Max Retrans | Max Cum Ack | 198 +---------------+---------------+ 199 | Max Out of Seq| Max Auto Reset| 200 +---------------+---------------+ 201 | Connection Identifier | 202 + + 203 | (32 bits in length) | 204 +---------------+---------------+ 205 | Checksum | 206 +---------------+---------------+ 208 Figure 2, SYN segment 210 Sequence Number 212 The sequence number field contains the initial sequence number selected for 213 this connection. 215 Acknowledgment Number 217 This field is valid only if the ACK flag is set. In that case, this 218 field will contain the sequence number of the SYN segment received from 219 the other RUDP. 221 Version 223 The version field contains the version of RUDP. The initial version is 224 one (1). 226 Bova & Krivoruchka [Page 6] 227 Maximum Number of Outstanding Segments 229 The maximum number of segments that should be sent without getting an 230 acknowledgment. This is used by the receiver as a means of flow control. 231 The number is selected during connection initiation and may not be 232 changed later in the life of the connection. This is not a negotiable 233 parameter. Each side must use the value provided by its peer when 234 sending data. 236 Options Flag Field 238 This field of two octets contains a set of options flags that specify 239 the set of optional functions that are desired for this connection. 240 A preliminary subset of flags are defined as follows: 242 Bit # Bit Name Description 243 0 not used not used, must always be set to 1. 244 1 CHK Data Checksum enable. If this bit is set 245 then the checksum field will contain a 246 checksum of the entire RUDP packet (header 247 and data). This is a negotiable 248 parameter. 249 2 REUSE This bit must be set during an auto reset to 250 indicate the previous negotiable parameters 251 should be used. When this bit is set the 252 following fields of the SYN should be set to 253 zero by the sender and must be ignored by the 254 receiver: Maximum Segment Size, 255 Retransmission Timeout Value, Cumulative Ack 256 Timeout Value, Max Retransmissions, Max 257 Cumulative Ack, Max Out of Sequence, and Max 258 Auto Reset. 259 3-7 Spare 261 Maximum Segment Size 263 The maximum number of octets that can be received by the peer sending the 264 SYN segment. Each peer may specify a different value. Each peer must not 265 send packets greater than the value of this field received from its peer 266 during connection negotiation. This number includes the size of the RUDP 267 header. This is not a negotiable parameter. 269 Retransmission Timeout Value 271 The timeout value for retransmission of unacknowledged packets. This value 272 is specified in milliseconds. The valid range is 100 to 65536. This is a 273 negotiable parameter, both peers must agree on the same value for this 274 parameter. 276 Bova & Krivoruchka [Page 7] 277 Cumulative Ack Timeout Value 279 The timeout value for sending an acknowledgment segment if another segment 280 is not sent. This value is specified in milliseconds. The valid range is 281 100 to 65536. This is a negotiable parameter, both peers must agree on the 282 same value for this parameter. In addition, this parameter should be 283 smaller than the Retransmission Timeout Value. 285 Null Segment Timeout Value 287 The timeout value for sending a null segment if a data segment has not 288 been sent. Thus, the null segment acts as a keep-alive mechanism. 289 This value is specified in milliseconds. The valid range is 0 to 65536. 290 A value of 0 disables null segments. This is a negotiable parameter, both 291 peers must agree on the same value for this parameter. 293 Transfer State Timeout Value 295 This timeout value indicate the amount of time the state information will 296 be saved for a connection before an auto reset occurs. This value is 297 specified in milliseconds. The valid range is 0 to 65536. This is a 298 negotiable parameter, both peers must agree on the same value for this 299 parameter. A value of 0 indicates the connection will be auto-reset 300 immediately. 302 Max Retrans 304 The maximum number of times consecutive retransmission(s) will be attempted 305 before the connection is considered broken. The valid range for this value 306 is 0 to 255. A value of 0 indicates retransmission should be attempted 307 forever. This is a negotiable parameter, both peers must agree on the same 308 value for this parameter. 310 Max Cum Ack 312 The maximum number of acknowledgments that will be accumulated before 313 sending an acknowledgment if another segment is not sent. The valid range 314 for this value is 0 to 255. A value of 0 indicates an acknowledgment 315 segment will be send immediately when a data, null, or reset segment is 316 received. This is a negotiable parameter, both peers must agree on the 317 same value for this parameter. 319 Max Out of Seq 321 The maximum number of out of sequence packets that will be accumulated 322 before an EACK (Extended Acknowledgement) segment is sent. The valid range 323 for this value is 0 to 255. A value of 0 indicates an EACK will be sent 324 immediately if an out of order segment is received. This is a negotiable 325 parameter, both peers must agree on the same value for this parameter. 327 Max Auto Reset 329 The maximum number of consecutive auto reset that will performed before 330 a connection is reset. The valid range for this value is 0 to 255. A 331 value of 0 indicates that an auto reset will not be attempted, the 332 connection will be reset immediately if an auto reset condition occurs. 333 This is a negotiable parameter, both peers must agree on the same value 334 for this parameter. The consecutive auto reset counter is cleared once 335 a connection is opened. 337 Connection Identifier 339 When opening a new connection each peer transmits a connection identifier 340 that is unique among all RUDP current connections. Each side then saves 341 the connection ID received. When an auto reset is performed, the peer 342 shall send the saved connection ID originally received to indicate that 343 an auto reset is being performed on the connection. 345 3. ACK Segment 347 The ACK Segment is used to acknowledge in-sequence segments. It contains 348 both the next send sequence number and the acknowledgment sequence number 349 in the RUDP header. The ACK segment may be sent as a separate segment, but 350 it should be combined with data whenever possible. Data and Null segments 351 must always include the ACK bit and Acknowledgment Number field. The size 352 of a stand-alone ACK segment is six octets. Figure 3 shows a stand-alone 353 ACK segment. 355 0 1 2 3 4 5 6 7 8 15 356 +-+-+-+-+-+-+-+-+---------------+ 357 |0|1|0|0|0|0|0|0| 6 | 358 +-+-+-+-+-+-+-+-+---------------+ 359 | Sequence # | Ack Number | 360 +---------------+---------------+ 361 | Checksum | 362 +---------------+---------------+ 364 Figure 3, Stand-alone ACK segment 366 4. EACK segment 368 The EACK segment is used to acknowledge segments received out of sequence. 369 It contains the sequence numbers of one or more segments received out of 370 sequence. The EACK is always combined with an ACK in the segment, giving 371 the sequence number of the last segment received in sequence. The header 372 length is variable for the EACK segment. Its minimum value is seven and 373 its maximum value depends on the maximum receive queue length. Figure 4 374 shows a stand-alone EACK segment. 376 0 1 2 3 4 5 6 7 8 15 377 +-+-+-+-+-+-+-+-+---------------+ 378 |0|1|1|0|0|0|0|0| N + 6 | 379 +-+-+-+-+-+-+-+-+---------------+ 380 | Sequence # | Ack Number | 381 +---------------+---------------+ 382 |1st out of seq |2nd out of seq | 383 | ack number | ack number | 384 +---------------+---------------+ 385 | . . . |Nth out of seq | 386 | | ack number | 387 +---------------+---------------+ 388 | Checksum | 389 +---------------+---------------+ 391 Figure 4, EACK segment 393 5. RST segment 395 The RST segment is used to close or reset a connection. Upon receipt of an 396 RST segment, the sender must stop sending new packets, but must continue 397 to attempt delivery of packets already accepted from the API. The RST is 398 sent as a separate segment and does not include any data. Figure 5 shows 399 a RST segment. 401 0 1 2 3 4 5 6 7 8 15 402 +-+-+-+-+-+-+-+-+---------------+ 403 | |A| | | | | | | | 404 |0|C|0|1|0|0|0|0| 6 | 405 | |K| | | | | | | | 406 +-+-+-+-+-+-+-+-+---------------+ 407 | Sequence # | Ack Number | 408 +---------------+---------------+ 409 | Header Checksum | 410 +---------------+---------------+ 412 Figure 5, RST segment 414 6. NUL segment 416 The NUL segment is used to determine if the other side of a connection 417 is still active. Thus, the NUL segment performs a keep-alive function. 418 When a NUL segment is received, an RUDP implementation must immediately 419 acknowledge the segment if a valid connection exists and the segment 420 sequence number is the next one in sequence. The segment is then 421 discarded. The NUL must be combined with an ACK in a segment but never 422 combined with user data. Figure 6 shows a NUL segment. 424 0 1 2 3 4 5 6 7 8 15 425 +-+-+-+-+-+-+-+-+---------------+ 426 |0|1|0|0|1|0|0|0| 6 | 427 +-+-+-+-+-+-+-+-+---------------+ 428 | Sequence # | Ack Number | 429 +---------------+---------------+ 430 | Checksum | 431 +---------------+---------------+ 433 Figure 6, NUL segment 435 7. TCS Segment 437 The TCS is used to transfer the state of connection. Figure 7 shows a TCS 438 segment. 440 0 1 2 3 4 5 6 7 8 15 441 +-+-+-+-+-+-+-+-+---------------+ 442 | |A| | | | | | | | 443 |0|C|0|0|0|0|1|0| 12 | 444 | |K| | | | | | | | 445 +-+-+-+-+-+-+-+-+---------------+ 446 | Sequence # | Ack Number | 447 +---------------+---------------+ 448 | Seq Adj Factor| Spare | 449 +---------------+---------------+ 450 | Connection Identifier | 451 + + + 452 | (32 bits in length) | 453 +---------------+---------------+ 454 | Checksum | 455 +---------------+---------------+ 457 Figure 7, TCS segment 459 Sequence Number 461 The sequence number field contains the initial sequence number selected for 462 this connection. 464 Acknowledgment Number 466 The acknowledgment number field indicates to a transmitted that last in- 467 sequence packet the receiver has received. 469 Seq Adj Factor 471 This field is used during transfer of state to adjust sequence numbers 472 between the old and current connections. 474 Connection Identifier 476 When opening a new connection each peer transmits a connection identifier 477 that is unique among all current RUDP connections. Each side then saves 478 the connection ID received. This field is used to inform the peer connection 479 of the connection record that is being transferred to this connection. 481 1.3.1 Detailed Design 483 A separate internet draft is being prepared which details in connections 484 state transitions in Specification and Description Language (SDL) format. 485 It also contains more details on the internal design of RUDP. 487 1.3.2 Feature Description 489 The following features are supported by RUDP. In the following description, 490 transmitter and receiver refer to either clients or servers that are sending 491 or receiving a data segment respectively on a connection. Client refers to 492 the peer that initiates the connection and Server refers to the peer that 493 listened for a connection. A connection is defined as an interface that 494 serves a unique peer IP address/UDP port pair. A server or a client can 495 have multiple connections on a particular IP address/UDP port, each 496 connection will be with a unique peer IP address/UDP port pair. 498 1. Retransmission timer. 500 The transmitter has a retransmission timer with a configurable time- 501 out value. This timer is initialized every time a data, null, or 502 reset segment is sent and there is not a segment currently being timed. 503 If an acknowledgment for this data segment is not received by the time 504 the timer expires, all segments that have been sent but not acknowledged 505 are retransmitted. The Retransmission timer is re-started when the 506 timed segment is received, if there is still one or more packets that 507 have been sent but not acknowledged. The recommended value of the 508 retransmission timer is 600 milliseconds. 510 2. Retransmission Counter. 512 The transmitter maintains a counter of the number of times a segment 513 has been retransmitted. The maximum value of this counter is configurable 514 with a recommended value is 2. If this counter exceeds its maximum, the 515 connection will be considered broken. Refer to paragraph item 14 below, 516 Broken Connection Handling, for a description of how RUDP handles a 517 broken connection. 519 3. Stand-alone acknowledgments. 521 A stand-alone acknowledgment segment is a segment that contains only 522 acknowledgment information. Its sequence number field contains the 523 sequence number of the next data, null, or reset segment to be sent. 525 4. Piggyback acknowledgments. 527 Whenever a receiver sends a data, null, or reset segment to the transmitter, 528 the receiver includes the sequence number of the last in-sequence data, 529 null, or reset segment received from the transmitter in the acknowledgment 530 number field of the header of the segment being sent by the receiver. 532 5. Cumulative acknowledge counter. 534 The receiver maintains a counter of unacknowledged segments received 535 without an acknowledgment being sent to the transmitter. The maximum 536 value of this counter is configurable. If this counter's maximum is 537 exceeded, the receiver sends either a stand-alone acknowledgment, or an 538 extended acknowledgment if there are currently any out-of-sequence 539 segments. The recommended value for the cumulative acknowledge counter 540 is 3. 542 6. Out-of-sequence acknowledgments counter. 544 The receiver maintains a counter of the number of segments that have arrived 545 out-of-sequence. Each time this counter exceeds its configurable maximum, 546 an extended acknowledgment segment containing the sequence numbers of all 547 current out-of-sequence segments that have been received is sent to 548 the transmitter. The counter is then reset to zero. The recommended 549 value for the out-of-sequence acknowledgements counter is 3. 551 When a transmitter receives an Extended Acknowledgment, it retransmits 552 the missing data segments to the receiver. 554 7. Cumulative acknowledge timer. 556 When a receiver has any segments that it has not acknowledged or if it has 557 segments on its out-of-sequence queue, it waits a maximum amount of 558 time before sending a stand-alone acknowledgment or an extended acknowledg- 559 ment, respectively. When this timer expires, if there are segments on the 560 out-of-sequence queue, an extended acknowledgment is sent. Otherwise, 561 if there are any segments currently unacknowledged, a stand-alone 562 acknowledgment is sent. The recommended value of the cumulative 563 acknowledgement timer is 300 milliseconds. 565 The cumulative acknowledge timer is restarted whenever an acknowledgment is 566 sent in a data, null, or reset segment, provided that there are no segments 567 currently on the out-of-sequence queue. If there are segments on the out- 568 of-sequence queue, the timer is not restarted, so that another extended 569 acknowledgment will be sent when it expires again. 571 8. Null segment timer 573 The client maintains a timer which is started when the connection is opened 574 and is reset every time a data segment is sent. If the client's null 575 segment timer expires, the client sends a null segment to the server. 577 The null segment is acknowledged by the server if its sequence number 578 is valid. The server maintains a null segment timer with a time-out 579 value of twice the client's time-out value. The server's timer is reset 580 whenever a data or null segment is received from the client. If the 581 server's null segment timer expires, the connection is considered broken. 582 Refer to paragraph item 14 below, Broken Connection Handling, for a 583 description of how RUDP handles a broken connection. The recommended 584 value of the Null segment timer is 2 seconds. 586 9. Auto Reset 588 Either side of a connection can initiate an auto reset. An auto reset 589 can be caused by the retransmission count exceeding its maximum, the 590 the expiration of the server's Null segment timer, or the expiration 591 of the transfer state timer. An auto reset will cause both peers to 592 reset their current states including flushing retransmission and 593 out-of-sequence queues and then reset their initial sequence number 594 and re-negotiate the connection. Each peer will notify its Upper Layer 595 Protocol (ULP) of the auto reset. There is a consecutive reset counter 596 that sets the maximum number of auto-reset that can occur without the 597 connection opening. If this counter exceeds its maximum the connection 598 is reset. The recommended value for the consecutive reset counter is 3. 600 10. Receiver Input Queue Size 602 The size of the receiver's input queue is a configurable parameter. 603 The recommended value of the receiver input queue size is 32 packets. The 604 input queue size acts as a flow control mechanism. 606 11. Congestion control and slow start 608 RUDP does not provide any congestion control or slow start algorithms. 610 12. UDP port numbers 612 RUDP doesn't place any restrictions on which UDP port numbers are used. 613 Valid port numbers are ports not defined in RFC 1700. 615 13. Support for redundant connections 617 If an RUDP connection fails, the Upper Layer Protocol will be signaled 618 and the transfer state timer will be started. The ULP can initiate the 619 transfer of this state to another RUDP connection via an API call and 620 RUDP will transfer the state information to the new connection ensuring 621 that packets are not duplicated or lost. If the ULP does not transfer 622 the state to another connection before the Transfer State Timer expires, 623 the connection state is lost and buffers of the queues of the 624 connection are freed. The time-out value for the Transfer State 625 timer is configurable. The recommended value for the Transfer State 626 timer is 1 second. 628 14. Broken connection handling 630 An RUDP connection is considered broken if either of the following 631 situations occur: 633 - The Retransmission Timer expires and the Retransmission Count has 634 been exceeded its maximum. 636 - A server's Null Segment Timer expires. 638 If either of the above two situations occur and the Transfer State 639 timeout value is non-zero, the ULP will be notified of the connection 640 failure via the Connection failure signal of the API and the Transfer 641 State Timer will be started. If the Transfer State Timer expires, an 642 Auto Reset is performed and the ULP is notified via the Connection auto 643 reset signal of the API. 645 If the transfer state timeout value is zero, then an auto reset will be 646 performed immediately when either of the above two situlations occur. 647 The ULP will be notified of a connection failure via the Connection 648 auto reset signal of the API. 650 15. Retransmission Algorithm 652 Retransmission occurs as a result of receiving an EACK segment or the 653 time-out of the Retransmission timer. 655 When an EACK segment is received. The segments specified in the message 656 are removed from the unacknowledged sent queue. The segments to be 657 retransmitted are determined by examining the Ack Number and the last out 658 of seq ack number in the EACK segment. All segments between but not 659 including these two sequence numbers that are on the unacknowledged sent 660 queue are retransmitted. 662 When a retransmission time-out occurs, all messages on the unacknowledged 663 sent queue are retransmitted. 665 16. Signals to Upper Layer Protocol (ULP) 667 The following signals are sent to the ULP via the API. These are used to 668 signal asynchronous events to the ULP: 670 Connection open - This signal is generated when the state of the 671 connection transitions to Open. 672 Connection refused - This signal is generated when the state of a 673 connection transitions to the Closed state from other 674 than the Close Wait state. 675 Connection closed - This signal is generated when the state of a 676 connection transitions from the Close Wait state to 677 the Closed state. 679 Connection failure - This signal is generated when a connection is 680 declared broken, as described in section 1.3.2, 681 item 15 (Retransmission Algorithm) above. 682 Connection auto reset - This signal is generated when a connection auto 683 resets. This is an indication to the ULP that data 684 may have been lost and RUDP is attempting to return 685 the connection to the Open state. 687 17. Checksum Algorithm 689 The checksum algorithm used in RUDP is the same algorithm used in UDP and 690 TCP headers which is the 16-bit one's complement of the one's complement 691 sum of data being checksumed. The checksum is calculated over the entire 692 RUDP packet if negotiated at the time the connection was opened. The 693 negotiation is based on setting the CHK bit of the options field in the 694 SYN segment used to open the connection. Otherwise, the checksum is 695 calculated over the RUDP header only. Refer to RFC 1071 for implementation 696 information for this algorithm. 698 18. FEC 700 RUDP does not define a procedure for generate Forward Error Correction 701 (FEC). It is compatible with FEC algorithms that generate duplicate 702 packets because it will throw away any duplicate packets it receives. 704 19. Security 706 RUDP will be compatible with the IPsec standard for secure IP 707 communications. 709 1.4 Feature Negotiation 711 When client initiates a connection its sends a SYN segment which contains 712 the negotiable parameters defined by the ULP via the API. The server can 713 accept these parameters by echoing them back in its SYN with ACK response 714 or propose different parameters in its SYN with ACK response. The client 715 can then choose to accept the parameters sent by the server by sending an 716 ACK to establish the connection or it can refuse the connection by sending 717 send a RST. Features cannot be re-negotiated during an auto reset. 719 2.0 Future Potential Enhancements 721 RUDP should support a symmetrical mode of operation in addition to the 722 current client/server mode of operation. This would allow both sides to 723 actively start the connection. 725 RUDP should support the ability to expand the sequence and acknowledge 726 fields from their current one octet length to two octets. This will allow 727 transmission windows of greater than 255 buffer to be used. 729 Investigate use of the Nagle algorithm to improve network efficiency. 731 3.0 References 733 [1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program 734 Protocol Specification", RFC 791, USC/Information Sciences Institute, 735 September 1981. 737 [2] Postel, J., "User Datagram Protocol", RFC 768, USC/Information 738 Sciences Institute, August 1980. 740 [3] Postel, J. (ed.), "Transmission Control Protocol", RFC 793, 741 USC/Information Sciences Institute, September 1981. 743 [4] Velten, D., Hinden, R. and Sax, J., "Reliable Data Protocol", RFC 744 908, BBN Communications Corporation, July 1984. 746 [5] Partridge, C. and Hinden, R., "Version 2 of the Reliable Data 747 Protocol", RFC 1151, BBN Corporation, April 1990. 749 [6] Braden, R., "Computing the Internet Checksum", RFC 1071, ISI, 750 September 1988 752 [7] V. Jacobson, "Congestion Avoidance and Control," Computer 753 Communication Review, Val. 18, no. 4, pp. 314-329, Aug. 1988. 755 [8] W. Stevens, RFC 2001 �TCP Slow Start, Congestion Avoidance, Fast 756 Retransmit, and Fast Recovery Algorithms�, January 1997 758 [9] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", April 759 30, 1990. 761 [10] Z. Wang, J. Crowcroft, A Dual-Window Model for Flow and Congestion 762 Control, The Distributed Computing Engineering Journal, Institute 763 of Physics/British Computer Society/IEEE, Vol 1, No 3, page 162-172, 764 May 1994. 766 [11] Romanow, Allyn, "TCP over ATM: Some Performance Results", 767 ATM Forum/93-784 769 4.0 Author's Addresses 771 Tom Bova Tel: +1-703-484-3331 772 Cisco Systems Email: tbova@cisco.com 773 13615 Dulles Technology Drive 774 Herndon, VA 20171 775 USA 777 Ted Krivoruchka Tel: +1-703-484-3325 778 Cisco Systems Email: tedk@cisco.com 779 13615 Dulles Technology Drive 780 Herndon, VA 20171 781 USA