HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:45:16 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 28 Nov 1996 00:17:00 GMT ETag: "361de6-bfd3-329cd9fc" Accept-Ranges: bytes Content-Length: 49107 Connection: close Content-Type: text/plain Internet Engineering Task Force Vincent P. Laviano INTERNET-DRAFT J. Mark. Pullen draft-laviano-srtp-00.txt George Mason U. November 26, 1996 Expires: May, 1997 Selectively Reliable Transport Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This memo describes a protocol for selectively reliable transport of Distributed Interactive Simulation (DIS) data in a wide-area multicast environment. The Selectively Reliable Transport Protocol (SRTP) operates in three distinct modes: best-effort multicast, reliable multicast using negative acknowledgements with a NAK suppression mechanism to avoid congestion at the sender, and reliable transaction-oriented unicast using positive acknowlegements to avoid unnecessary TCP connection overhead. SRTP is designed to run in user space and form a sublayer between applications and the kernel-level Internet protocol stack. Table of Contents 1. Introduction 2 2. Protocol Description 2 2.1. Definition of Terms 3 2.2. Packet Format 3 2.2.1. Protocol Version 4 2.2.2. Packet Type 4 2.2.3. Transmission Mode 4 2.2.4. Category Code 4 2.2.5. Sequence Number (SN) 4 2.2.6. Destination Address 5 2.2.7. Encapsulated User Data 5 3. Protocol Behavior 5 3.1. Mode 0 Operation 5 3.1.1. Nonzero Category Codes 5 3.1.2. Category Code 0 6 3.1.3. Sending Mode 0 Packets 6 3.1.4. Receiving Mode 0 Packets 7 3.2. Mode 1 Operation 7 3.2.1. Sending Mode 1 Data Packets 7 3.2.2. Receiving Mode 1 Data Packets 8 3.2.3. Sending a Negative Acknowledgement 9 3.2.4. Receiving a Negative Acknowledgement 10 3.3. Mode 2 Operation 10 3.3.1. Sending Mode 2 Data Packets 10 3.3.2. Receiving Mode 2 Data Packets 11 3.3.3. Sending a Positive Acknowledgement 12 3.3.4. Receiving a Positive Acknowledgement 12 4. Implementation Issues 12 4.1. Host Requirements 12 4.2. API Requirements 13 4.2.1. Creation and Deletion of Assocations 13 4.2.2. Registeration and Unregistration of Interest 13 4.3. An Example API 13 Future Work 14 References 15 Security Considerations 15 Authors' Addresses 16 1. Introduction Distributed Interactive Simulation (DIS) is a real-time multicast application that requires the reliable transport of a subset of its data [DIS94]. Applications such as DIS cannot take advantage of fully reliable transport for all data and still achieve real-time transmission. Since no suitable transport protocol exists today [Pull96], DIS applications must compromise and use the best-effort User Datagram Protocol (UDP) in order to achieve real-time transmission. However, the use of an unreliable transport protocol forces these applications to perform tasks such as the detection and recovery of lost packets, in order to ensure the reliable transmission of that subset of their data that requires it. These tasks would be performed by the transport protocol if transport protocols meeting the needs of DIS existed. This increases the complexity of DIS applications, making them more costly to design, implement and maintain. This document describes a Selectively Reliable Transport Protocol (SRTP) that operates in three distinct modes: best-effort multicast, reliable multicast using negative acknowledgements with a NAK suppression mechanism to avoid congestion at the sender, and reliable transaction-oriented unicast using positive acknowlegements to avoid unnecessary TCP connection overhead. We believe that such a standardized protocol would remove an undue burden from DIS application developers and increase interoperability among DIS applications. This document is based upon our prior work with the DIS Standards Community and our experience implementing an SRTP prototype in a UNIX environment [PuLa95] [PuLa96]. 2. Protocol Description SRTP operates in three distinct transmission modes in order to deliver varying levels of reliability that correspond to the needs of individual DIS protocol data units (PDUs): mode 0 for multicast data that does not require reliable transmission, mode 1 for data that must be received reliably by all members of a multicast group, and mode 2 for data that must be received reliably by a single dynamically-determined member of a multicast group. In order to run large DIS exercises with minimal distruption to real-time service, it has become necessary to employ a number of algorithms and techniques for managing network traffic between sites. Algorithms such as the Protocol Independent Compression Algorithm (PICA) [CSTVH95] reduce network traffic between sites by compressing entity state information using a reference/offset scheme. In such a scheme, reference PDUs containing infrequently changing entity state information are sent periodically, while smaller offset PDUs containing variations from the reference data are sent more frequently. SRTP supports such reference/offset schemes by providing category codes with which to label related PDUs and by providing semantics that expect a dependent relationship between mode 1 and mode 0 PDUs of the same category. See sections 2.2.4, 3.1.1 and 3.2 for further details. SRTP expects that only a small percentage of PDUs generated by DIS applications will require reliable transport. This is due to the fact that the vast majority of DIS traffic is composed of Entity State PDUs. See section 3.1. for more discussion on this topic. 2.1 Definition of Terms Locality Window Given an integral window size, S, in the range 0 to 32767, the locality window about a particular sequence number SN is defined as all sequence numbers SN' in the sixteen bit sequence number space that satisfy: abs((SN - SN') modulo 65536) <= S An implementation must allow itself to be configured with any window size in the range 0 to 32767. 2.2 Packet Format An SRTP packet consists of a protocol header followed by a variable amount of data. The protocol header, as shown in Figure 1, has a length of 10 bytes, and is part of every packet. The remainder of the packet is user data. The total length of the SRTP packet, including the header, may not exceed 1464 bytes. This value was selected to exceed 1280 bytes, the maximum size of a DIS Entity State PDU. It should also be noted that a 1464-byte SRTP packet (1492 bytes including UDP and IP headers) exceeds neither the IEEE 802.3/802.2 MTU of 1492 bytes nor the Ethernet MTU of 1500 bytes, and will therefore not be fragmented by IP in these local-area environments [Stev94]. 0 7 8 11 12 15 0 ------------------------------------------------------------- --- | protocol | packet | transmission | | | version | type | mode | | 16 ------------------------------------------------------------- | | category code | | | | | 32 ------------------------------------------------------------- | sequence number (SN) | packet | | header 48 ------------------------------------------------------------- | | | | | | 64 | destination address | | | | | | | | 80 ------------------------------------------------------------- --- | encapsulated user data (data packets only) | ... (variable length, not to exceed 1454 bytes) ... | | ------------------------------------------------------------- Figure 1. SRTP Packet Format 2.2.1 Protocol Version The first byte of the packet is the protocol version number. This document describes version 1 of the Selectively Reliable Transport Protocol and thus the version field has a value of 0x01. When any packet is received by SRTP, it is silently discarded if its first byte is not equal to 0x01. 2.2.2 Packet Type Bits 8, 9, 10 and 11 represent the packet type. In version 1 of SRTP, bits 8 and 9 must be set to zero. The following table lists the field values that satisfy this requirement and describes their meaning. bit 8 bit 9 bit 10 bit 11 description 0 0 0 0 data packet 0 0 0 1 negative acknowledgement (NAK) 0 0 1 0 positive acknowledgement (ACK) 0 0 1 1 reserved for future use 2.2.3 Transmission Mode Bits 12, 13, 14 and 15 represent the transmission mode for the packet. In version 1 of SRTP, bits 12 and 13 must be set to zero. The following table lists the field values that satisfy this requirement and describes their meaning. bit 12 bit 13 bit 14 bit 15 description 0 0 0 0 mode 0: best-effort multicast 0 0 0 1 mode 1: reliable multicast 0 0 1 0 mode 2: reliable unicast 0 0 1 1 reserved for future use Type 1 (NAK) packets are required to be mode 1, and type 2 (ACK) packets are required to be mode 2. The three transmission modes will be discussed in detail in section 3 of this document. 2.2.4 Category Code Bytes 3 and 4 of the header are the category code of the packet. A category code is an integer in the range 0 - 65535 that is used to associate related packets with each other. Category code 0 is assigned a special meaning as described below in section 3.1.1. In version 1 of SRTP, only a mode 0 packet may have a category code of 0. This mechanism allows up to 65534 separate packets flows or "streams" to be handled simultaneously. Packets in a single stream may use different transmission modes. 2.2.5 Sequence Number (SN) Bytes 5 and 6 of the header are the sequence number, or SN, of the packet. The SN is an integer in the range 0 - 65535 that is used to detect missing packets and to associate specific control packets with specific data packets. The precise use of the SN field varies based on the type and transmission mode of the packet. Specific details are given throughout section 3 of this document. 2.2.6 Destination Address The last four bytes of the header are the IP address to which the packet should be delivered. This is an IP multicast address (in the range 224.0.0.0 to 239.255.255.255) for mode 0 and mode 1 packets, and a unicast ("regular") IP address for mode 2 packets. This field is redundant with the destination IP address in the IP header, but serves to identify to which multicast group a received multicast packet was sent in the case where the packet is received from a communication endpoint (e.g., a UNIX socket) that has multiple multicast group memberships. The authors are not aware of any other way to obtain this information, and welcome suggestions from readers with experience in this area. 2.2.7 Encapsulated User Data Type 1 (NAK) and type 2 (ACK) packets consist solely of a 10-byte packet header and do not contain any user data. Type 0 (data) packets contain up to 1454 bytes of encapsulated user data following the packet header. An implementation of SRTP must not examine, use, or change this data. It is permissible for a data packet to contain 0 bytes of user data. 3. Protocol Behavior This section describes the behavior of each of the three transmission modes, both from the perspective of responding to application requests and from the perspective of responding to received SRTP packets. The various requests that can be made of an SRTP implementation by an application should be considered part of the protocol, but no particular API is mandated. A example API is described in section 4 of this document. 3.1 Mode 0 Operation Mode 0 is for multicast packets that do not require reliable transmission, because they are part of a real-time stream of data that is periodically updated with high frequency. It is usually pointless for a receiver to request retransmission of such packets when they are lost or corrupted, because any such packet is very likely to have been superceded by a more recent update by the time retransmission is complete. It is often more efficient for the receiver to simply wait for the next update to arrive. DIS Entity State PDUs are an example of data that should be transmitted using mode 0. Due to the constraints imposed in section 2.2.3, mode 0 packets are always data packets and never control packets. 3.1.1. Nonzero Category Codes Mode 0 packets with a nonzero category code are to be interpreted as frequent state updates (in offset form) to some (less frequently updated) reference state. Such offset packets will be expected to be part of a data stream that also contains reference packets (mode 1 packets of the same category). Applications may subscribe and unsubscribe to data streams, as described below. 3.1.2. Category Code 0 As noted above, only mode 0 packets may be of category 0. Category 0 packets are independent of all other data (i.e., not part of a stream), and they are automatically received by all members of the multicast group to which the packet is addressed. Applications are automatically considered to be subscribed to category 0 at all times. No application may unsubscribe from category 0. The use of category 0 when not strictly necessary is strongly discouraged. 3.1.3. Sending Mode 0 Packets When an application requests the transmission of mode 0 data, a category code and a destination multicast group must be provided to SRTP along with the data to be sent. The following steps must then be performed by SRTP: 1. The data must be verified to be between 0 and 1454 bytes in length. If more than 1454 bytes of data are provided, none of the data may be sent, and the error must be reported to the application. 2. The category code must be verified to be between 0 and 65535. If the category code is invalid, the data may not be sent and the error must be reported to the application. 3. The destination multicast address must be verified to be a valid multicast address in the range 224.0.0.0 to 239.255.255.255. If the multicast address is invalid, the data may not be sent and the error must be reported to the application. An implementation may further restrict the range of destination multicast addresses that it will send to and may refuse to send data if the application provides an out-of-range multicast address. In this case, an error must be reported to the application and the error message must differentiate this case from the case where a truly invalid multicast address was provided by the application. 4. If the category code is nonzero, at least one mode 1 packet of the same category must already have been sent to the destination multicast address by this instance of the SRTP implementation. If this is not the case, the data may not be sent and the error must be reported to the application. 5. If steps 1 through 4 were completed without error, an SRTP packet must be generated with the following characteristics: the version is set to 0x01, the packet type is set to 0x0, the transmission mode is set to 0x0, the category code is set to the application-provided value, and the destination address is set to the application-provided IP multicast address. If the category code is 0, the SN is set to 0x00. Otherwise, the SN is set equal to the SN of the most recently sent mode 1 packet of the same category. Finally, if there are more than 0 bytes of user data, the user data is included after the packet header. If the packet cannot be generated as described above, the user data is discarded and the error must be reported to the application. 6. If step 5 was completed without error, the newly generated packet must be sent to the IP multicast address contained in its destination address field, encapsulated within a UDP datagram. If the UDP interface on the sending system reports an error to SRTP when the attempt to send the SRTP packet is made, an implementation may attempt to resend the packet any finite number of times. However, every implementation must provide a mode in which no retries are attempted. Implementations should default to this latter mode of operation, but this is not required. The implementation must report to the application whether or not the packet was ultimately accepted by UDP. 3.1.4. Receiving Mode 0 Packets When a mode 0 packet is received by SRTP it should be processed as follows (assuming that the version field has already been verified to be 0x01): 1. Recall that all mode 0 packets are data packets. If a packet has a transmission mode of 0x0 and a packet type that is something other than 0x0, it must be silently discarded. 2. The destination address must be verified to be a valid IP multicast address. Furthermore, the destination address must be a multicast group of which the communication endpoint on which the packet was received is a member. If this is not the case, the packet must be silently discarded. 3. If the category code is 0, the SN must be verified to be 0x00. If this is not the case, the packet must be silently discarded. Once the sequence number has been verified to be 0x00, the user data must be delivered to all applications that have registered for the multicast group contained in the packet's destination address field. The delivery mechanism is left up to individual implementations. 4. If the category code is nonzero, the SN must be verified to be equal to the SN of the most recently received mode 1 packet of the same category sent to the same multicast address as that contained in the packet's destination address field. If this test is successful, the user data must be delivered to all applications that have registered for both the multicast group and category code of the packet. If the test is unsuccessful because no such mode 1 packet exists, SRTP must consider sending a NAK for the mode 1 packet in question. This process is described in detail below. If an appropriate mode 1 packet exists, the sequence number of the mode 0 packet is within the locality window about the SN of the mode 1 packet, and the SN of the mode 0 packet is less than that of the mode 1 packet with respect to the locality window (which is guaranteed to be smaller than the entire sequence number space), the packet must be silently discarded. Otherwise, SRTP must consider sending a NAK for a mode 1 packet with the same category and sequence number as the mode 0 packet to the multicast address in the destination address field of the mode 0 packet. 3.2. Mode 1 Operation Mode 1 is for multicast data that requires reliable transmission. A mode 1 packet can be either a data packet or a NAK. Mode 1 data packets may not be of category 0, and they are therefore expected to be part of a data stream. This data stream is likely to contain mode 0 packets as well (see section 3.1.1), but it is possible for a data stream to be comprised solely of mode 1 packets. 3.2.1. Sending Mode 1 Data Packets When an application requests the transmission of mode 1 data, a category code and a destination multicast group must be provided to SRTP along with the data to be sent. The following steps must then be performed by SRTP: 1. The data must be verified to be between 0 and 1454 bytes in length. If more than 1454 bytes of data are provided, none of the data may be sent, and the error must be reported to the application. 2. The category code must be verified to be between 1 and 65535. If the category code is invalid, the data may not be sent and the error must be reported to the application. 3. The destination multicast address must be verified to be a valid multicast address in the range 224.0.0.0 to 239.255.255.255. If the multicast address is invalid, the data may not be sent and the error must be reported to the application. An implementation may further restrict the range of destination multicast addresses that it will send to and may refuse to send data if the application provides an out-of-range multicast address. In this case, an error must be reported to the application, and the error message must differentiate this case from the case where a truly invalid multicast address was provided by the application. 4. If steps 1 through 3 were completed without error, an SRTP packet must be generated with the following characteristics: the version is set to 0x01, the packet type is set to 0x0, the transmission mode is set to 0x1, the category code is set to the application-provided value, and the destination address is set to the application-provided IP multicast address. The SN is set equal to the SN of the most recently sent mode 1 packet of the same category incremented by 1 modulo 65536. If no such mode 1 packet exists, a uniformly distributed random number in the interval 0 to 65535 is generated and assigned as the SN for the new packet. Finally, if there are more than 0 bytes of user data, the user data is included after the packet header. If the packet cannot be generated as described above, the user data is discarded and the error must be reported to the application. 5. The newly generated packet must then be buffered, replacing any formerly buffered mode 1 packet of the same category and destination multicast address. If the packet cannot be buffered, the user data is discarded and the error must be reported to the application. 5. If step 5 was completed without error, the newly generated packet must be sent to the IP multicast address contained in its destination address field, encapsulated within a UDP datagram. If the UDP interface on the sending system reports an error to SRTP when the attempt to send the SRTP packet is made, an implementation may attempt to resend the packet any finite number of times. However, every implementation must provide a mode in which no retries are attempted. Implementations should default to this latter mode of operation, but this is not required. The implementation must report to the application whether or not the packet was ultimately accepted by UDP. 3.2.2. Receiving Mode 1 Data Packets When a mode 1 data packet is received by SRTP it should be processed as follows(assuming that the version field has already been verified to be 0x01): 1. The category code must be verified to be nonzero. If the category code is 0, the packet must be silently discarded. 2. The destination address must be verified to be a valid IP multicast address. Furthermore, the destination address must be a multicast group of which the communication endpoint on which the packet was received is a member. If this is not the case, the packet must be silently discarded. 3. If no mode 1 packet of the same category has yet been received, the SN of the received packet must be buffered, and the encapsulated user data must then be delivered to all applications that have registered for the category and multicast group of the received packet. If a mode 1 packet of the same category has already been received, then the SN of the most recently received such packet will have been buffered. If the SN of the received packet is within the locality window about the buffered SN and the SN of the received packet is less than the buffered SN with respect to the locality window, the packet must be silently discarded. Otherwise, the SN of the received packet must be buffered, replacing the previously buffered SN for this category and destination multicast address, and the encapsulated user data must then be delivered to all applications that have registered for the category and multicast group of the received packet. 4. Additionally, when the new SN is buffered, NAK suppression information should be reset for the appropriate category and multicast address. See section 3.2.4. below. 3.2.3 Sending a Negative Acknowledgement Negative Acknowledgements (NAKs) are triggered by the receipt of a mode 0 packet of a nonzero category bearing a sequence number that indicates that a mode 1 packet of the same category has been missed. Negative acknowledgements are used by SRTP for multicast packets in order to avoid the congestion of an "ACK implosion" at the original sender that would likely occur if positive acknowledgements were used instead. However, with a large multicast group spread out over a congested wide- area network, there is the potential for enough members of the multicast group to fail to receive the message and generate NAKs to cause considerable congestion at the original sender despite the use of negative acknowledgements instead of positive acknowledgements. For this reason, SRTP uses a NAK suppression mechanism to reduce the number of NAKs generated in response to any single lost packet [VHCS95]. The NAK suppression mechanism is as follows: 1. When SRTP wants to send a NAK for a particular mode 1 packet, it must first check to see if any member of the packet's destination multicast group has sent a NAK for that packet within some user- configurable time interval that we will refer to as the "NAK threshold." If not, a NAK is generated with version set to 0x01, packet type set to 0x1, transmission mode set to 0x1. Category code, SN, and destination address are set to that of the mode 1 packet for which the NAK is being sent. As noted before, a NAK consists solely of a header and thus the user data field remains empty. If a NAK has been sent by any member of the destination multicast group for the mode 1 packet in question within the NAK threshold, no NAK is generated. 2. If a NAK is generated, it is sent at a randomly generated time in future. This is to avoid the situation in which several receivers all detect that a packet has been missed at roughly the same time, determine that no member of their multicast group has sent a NAK for the packet, and all send NAKs simultaneously -- thus creating the situation we hoped to avoid. The interval of time for which to wait before sending a NAK is an uniformly distributed random number in the range 0 to 2^N, where N is the number of the times a NAK has been sent for this particular mode 1 packet by any member of the destination multicast group. 3.2.4 Receiving a Negative Acknowledgement When a NAK is received by SRTP, it must processed as follows (assuming that the version has already been verified to be 0x01): 1. The transmission mode must be verified to be 0x1. If this is not the case, the packet must be silently discarded. 2. The category code must be verified to be nonzero. If the category code is 0, the packet must be silently discarded. 3. The destination address must be verified to be a valid IP multicast address. Furthermore, the destination address must be a multicast group of which the communication endpoint on which the packet was received is a member. If this is not the case, the packet must be silently discarded. 4. If this instance of SRTP has ever sent a mode 1 packet of the category indicated in the NAK to the multicast address indicated in the NAK, the most recent such packet (which is buffered) should be immediately retransmitted to the multicast address indicated in the received NAK. 5. Whether or not step 4 results in the retransmission of a packet, the event of receiving the NAK and the (local machine) time at which the NAK was received should be buffered. Each instance of SRTP should know how many NAKs have been received for each category-multicast address pair since the most recent mode 1 packet of the same pair was received and the time at which the most recent of these NAKs was received. This is the information that is reset in step 4 in section 3.2.2. above. 3.3. Mode 2 Operation Mode 2 is for infrequent reliable transaction-oriented communication between two dynamically determined members of a multicast group. TCP could be used for such communication, but there would be unnecessary overhead in establishing a stream-oriented connection for a single exchange of data, whereas there is already an ongoing stream of best-effort data between the hosts that require mode 2 transmission. A DIS collision PDU is an example of data that would benefit from using transmission mode 2. 3.3.1. Sending Mode 2 Data Packets 3. When an application requests the transmission of mode 2 data, a category code and a destination unicast IP address must be provided to SRTP along with the data to be sent. The following steps must then be performed by SRTP: 1. The data must be verified to be between 0 and 1454 bytes in length. If more than 1454 bytes of data are provided, none of the data may be sent, and the error must be reported to the application. 2. The category code must be verified to be between 1 and 65535. If the category code is invalid, the data may not be sent and the error must be reported to the application. 3. The destination address must be verified to be a valid unicast IP address. If the address is invalid, the data may not be sent and the error must be reported to the applicationr. 4. If steps 1 through 3 were completed without error, an SRTP packet must be generated with the following characteristics: the version is set to 0x01, the packet type is set to 0x0, the transmission mode is set to 0x2, the category code is set to the application-provided value, and the destination address is set to the application-provided IP address. The SN is set equal to the SN of the most recently sent mode 2 packet of the same category incremented by 1 modulo 65536. If no such mode 1 packet exists, a uniformly distributed random number in the interval 0 - 65535 is generated and assigned as the SN for the new packet. Finally, if there are more than 0 bytes of user data, the user data is included after the packet header. If the packet cannot be generated as described above, the user data is discarded and the error must be reported to the application. 5. The newly generated packet must then be buffered. This new packet does not replace any formerly buffered mode 2 packets. An implementation must provide a mode 2 packet buffer that can hold one or more mode 2 packets. Mode 2 packets are expected to be infrequent (less than 10 percent of total DIS traffic), but it is still strongly recommended that an implementation provide a buffer of user-configurable size that can hold more than a single mode 2 packet. If the packet cannot be buffered, the user data is discarded and the error must be reported to the application. 5. If step 5 was completed without error, the newly generated packet must be sent to the IP address contained in its destination address field, encapsulated within a UDP datagram. If the UDP interface on the sending system reports an error to SRTP when the attempt to send the SRTP packet is made, an implementation may attempt to resend the packet any finite number of times. However, every implementation must provide a mode in which no retries are attempted. Implementations should default to this latter mode of operation, but this is not required. The implementation must report to the application whether or not the packet was ultimately accepted by UDP. 6. If some user-configurable period of time (which should be greater than the worst-case round-trip time for the multicast group) which we will refer to as the "ACK threshold" elapses without receipt of an ACK for the mode 2 packet, it must be retransmitted. It is permissible for an implementation to define a maximum number of retransmissions that will be attempted before the mode 2 packet is removed from the buffer, provided that this number is greater than or equal to one. It is strongly recommended that this number be a parameter of the application request for mode 2 transmission. 3.3.2. Receiving Mode 2 Data Packets When a mode 2 data packet is received by SRTP it should be processed as follows (assuming that the version field has already been verified to be 0x01): 1. The category code must be verified to be nonzero. If the category code is 0, the packet must be silently discarded. 2. The destination address must be verified to be the IP address of one of the receiving host's interfaces. If this is not the case, the packet must be silently discarded. 3. For mode 2 packets, the sequence number field is actually used as a transaction id to associate the required positive acknowledgement with a specific mode 2 packet. For this reason, if steps 1 and 2 above are completed without error, the encapsulated user data is unconditionally delivered to all applications that have registered for the category and multicast group of the received packet, regardless of the value of the SN field. 4. Additionally, an ACK must be sent to the host from which the mode 2 data packet originated. See section 3.3.3. below for details. 3.3.3. Sending a Positive Acknowledgement A positive acknowledgement (ACK) is triggered by the receipt of a mode 2 data packet. Sending an ACK is straightforward: a new SRTP packet is generated with version set to 0x01, packet type set to 0x2, and transmission mode set to 0x2. Category and SN must reflect those of the mode 2 data packet being acknowledged. The destination address field must be set to the source IP address from which the data packet was received. Since mode 2 data packets are unicast, there is little concern about an ACK implosion causing excessive congestion at the original sender. Therefore, no suppression mechanism is necessary, and the ACK should be transmitted with no delay. 3.3.4. Receiving a Positive Acknowledgement When an ACK is received by SRTP, it must processed as follows (assuming that the version has already been verified to be 0x01): 1. The transmission mode must be verified to be 0x2. If this is not the case, the packet must be silently discarded. 2. The category code must be verified to be nonzero. If the category code is 0, the packet must be silently discarded. 3. The destination address must be verified to be the IP address of one of the receiving host's interfaces. If this is not the case, the packet must be silently discarded. 4. If a mode 2 packet with the same category, SN, and destination address as the received ACK resides in the receiving host's mode 2 packet buffer, it must be removed from the buffer. Otherwise, the ACK must be silently discarded. 4. Implementation Issues This section discusses implementation issues such as host requirements and API requirements, and gives an example of an API that satisfies these requirements. 4.1. Host Requirements SRTP has been designed to run in user space and form a sublayer between applications and the kernel-level UDP and IP protocols. Therefore, any host upon which SRTP is run must provide an Internet protocol stack with UDP, IP, and IGMP enabled. In addition, if SRTP is to be used beyond the confines of a local area network, some form of multicast routing must be available. A single instance of SRTP is intended to run on each SRTP-capable host. 4.2. API Requirements In addition to providing facilities to send and receive mode 0, 1 and 2 data, an implementation of SRTP must also provide a number of other facilities to applications: creation and deletion of an association with SRTP, registration and unregistration of interest in data based on categories and multicast groups, and the ability to set various user configurable parameters. Most of these facilities are described in more detail below. However, we will not discuss the setting of user configurable parameters in any more detail here. 4.2.1. Creation and Deletion of Associations An implementation of SRTP must allow applications to create and delete associations with SRTP. An association represents state about the application that is needed by SRTP in order to allow the application to send and receive data, and register and unregister interest in categories and multicast groups. Furthermore, an implementation must not allow an application to perform any of these actions when it does not have an association with SRTP. Associations between an application and an instance of SRTP exist until: the application deletes the association, the application terminates execution, or the instance of SRTP terminates execution. 4.2.2. Registration and Unregistration of Interest An implementation of SRTP must allow applications to register interest in any subset of the nonzero categories. The result of such a registration is that the application will receive all data (mode 0, 1 and 2) that is labelled with the registered category code. An implementation must also allow applications to unsubscribe from any currently registered nonzero categories. The result of unsubscription is that the application will receive no data of the category that was received after the unsubscription took place (until the application again registers interest in the category). All applications are automatically registered for category 0 at all times. An application may not unsubscribe from category 0. Registering an already registered category or unregistering a category that is not currently registered must result in an error report to the application. Similarly, an implementation must allow applications to register and unregister interest in data sent to any multicast group. An application may send SRTP data without being registered for any multicast group. An implementation must support at least 20 unique multicast group subscriptions at any one time. It is strongly recommended that at least an order of magnitude more be supported (this can be achieved in UNIX through the use of multiple sockets, the "select" system call, and some careful bookkeeping). Registering an already registered multicast group or unregistering a multicast group that is not currently registered must result in an error report to the application. 4.3. An Example API SRTP_INIT Purpose: Create an association between an application and SRTP. Calling Sequence: status = srtp_init(); Parameters: None. SRTP_TERM Purpose: Delete an association between an application and SRTP. Calling Sequence: status = srtp_term(); Parameters: None. SRTP_REG_CAT Purpose: Register interest in data labelled with a certain category code. After calling this function, a client will be able to receive all subsequent data of the registered category that is sent to any multicast groups to which the client is registered. Calling Sequence: status = srtp_reg_cat(category_code); Parameters: category_code: category code for which to register interest. SRTP_UNREG_CAT Purpose: Unregister interest in data labelled with a certain category code. After calling this function, a client will no longer receive new data of the registered category. Calling Sequence: status = srtp_unreg_cat(category_code); Parameters: category_code: category code for which to unregister interest. SRTP_REG_MCG Purpose: Register interest in data sent to a certain multicast group. After calling this function, a client will be able to receive all subsequent data that is sent to this multicast group, provided that it is labelled with a category that the client has registered an interest in. All clients are implicitly registered for category 0 at all times. Calling Sequence: status = srtp_reg_mcg(multicast_address); Parameters: multicast_address: multicast group for which to register interest. SRTP_UNREG_MCG Purpose: Unregister interest in data sent to a certain multicast group. After calling this function, a client will no longer receive new data that is sent to this multicast group. Calling Sequence: status = srtp_unreg_mcg(multicast address); Parameters: multicast_address: multicast group for which to unregister interest. SRTP_SEND Purpose: Provide data to SRTP for transmission. Calling Sequence: status = srtp_send(message, length, options); Parameters: message: user data to be sent. length: length of user data in bytes. options: a structure containing options such as transmission mode, category code, destination address, and multicast time-to-live. SRTP_RECV Purpose: Receive a message from SRTP into an application-provided buffer. This function is nonblocking. Calling Sequence: status = srtp_recv(buffer); Parameters: buffer: buffer for received message. Future Work The authors are considering the addition of a congestion control mechanism to SRTP that would favor mode 1 and 2 packets over mode 0 packets, discarding the latter when measured round-trip latency exceeds a specified threshold in order to ensure the timely transmission of the former. We are also considering the addition of a logging mechanism, as described in [HCS95], in which each site would elect one instance of SRTP to act as a logging server. The logging server would be responsible for buffering the most recent mode 1 packet of each category that it received. Whenever an instance of SRTP determined a packet to be lost or corrupted, it would identify its logging server and a NAK would be directed to this server. The logging server would then retransmit the buffered packet in question. Only if the packet was not available at the logging server would a NAK be sent over the wide-area network to the orignal source of the packet. This approach avoids unnecessary interaction over the wide-area network, reducing overall latency and congestion. When there are many sites, this architecture can be hierarchically extended, with primary logging servers each logging for a number of site-local secondary logging servers. We believe that these additions would contribute towards the scalability of SRTP in the wide-area environment. References [CSTVH95] Calvin, J. O., J. Seeger, G. D. Troxel and D. J. Van Hook, "STOW Realtime Information Transfer and Networking System Architecture", 12th DIS Workshop on Standards for the Interoperability of Distributed Simulations, March 1995. [DIS94] Dis Steering Committee, The DIS Vision: A Map to the Future of Distributed Simulation, May 1994. [HCS95] Holbrook, H. W., S. K. Singhal and D. R. Cheriton, "Log-Based Receiver-Reliable Multicast for Distributed Interactive Simulation", Proceedings of SIGCOMM '95, August 1995. [PMB96] Pullen, J. M., M. Myjak, and C. Bouwens, Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment, Work in Progress (Internet Draft), September 1996. [PuLa95] Pullen, J. M. and V. P. Laviano, "A Selectively Reliable Transport Protocol for Distributed Interactive Simulation", 13th DIS Workshop on Standards for the Interoperability of Distributed Simulations, September 1995. [PuLa96] Pullen, J. M. and V. P. Laviano, "Prototyping the Selectively Reliable Transport Protocol", 14th DIS Workshop on Standards for Distributed Interactive Simulation, March 1996. [Stev94] Stevens, W. R., TCP/IP Illustrated, Volume 1, Addison-Wesley, Reading, Mass., 1994. [VHCS95] Van Hook, D. J., J. O. Calvin, and J. E. Smith, "Data Consistency Mechanisms to Support Distributed Simulation", 13th DIS Workshop on Standards for Distributed Interactive Simulation, September 1995. Security Considerations Security issues are not discussed in this memo. Authors' Addresses Vincent P. Laviano George Mason University C3I Center Mail Stop 4B5 Fairfax, VA 22030 Phone: (703) 993-1705 E-mail: vlaviano@cne.gmu.edu J. Mark Pullen George Mason University C3I Center/Computer Science Mail Stop 4A5 Fairfax, VA 22030 Phone: (703) 993-1538 E-mail: mpullen@cne.gmu.edu