Internet Engineering Task Force Vincent P. Laviano INTERNET-DRAFT J. Mark. Pullen draft-laviano-srtp-02.txt George Mason U. July 25, 1997 Expires: Jan 1998 Selectively Reliable Transmission 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 transmission of Distributed Interactive Simulation (DIS) data in a wide-area multicast environment. The Selectively Reliable Transmission 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 lightweight reliable transaction-oriented unicast. 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. DIS Communication Requirements 2 2.1. Scaling DIS 2 2.2. DIS and Multicasting 3 2.3. Reliability vs. Latency 3 2.4. Reliable Multicast and the HLA 4 3. Protocol Description 5 3.1. Definition of Terms 5 3.2. Message Format 6 4. Protocol Behavior 8 4.1. Steps for Sending Data 9 4.2. Steps for Receiving Data 11 4.3. Negative Acknowledgements (NAKs) 12 4.4. Positive Acknowledgements (ACKs) 13 5. Implementation Issues 14 5.1. Host Requirements 14 5.2. API Requirements 14 5.3. An Example API 15 Future Work 16 References 17 Security Considerations 18 Authors' Addresses 18 1. Introduction Distributed Interactive Simulation (DIS) is a real-time multicast application that requires reliable transmission of a subset of its data [DIS94]. Large-group multicast 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 [PMB97], DIS applications must use the best-effort User Datagram Protocol (UDP) in order to achieve real-time transmission. However, in some cases, the use of an unreliable transport protocol forces these applications to perform tasks such as the detection and recovery of lost messages, 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 Transmission 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 lightweight reliable transaction-oriented unicast 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]. Such as protocol can also serve as a significant component of the Runtime Infrastructure (RTI) required by the new DoD High-Level Architecture (HLA). 2. DIS Communication Requirements 2.1 Scaling DIS One of the largest challenges being faced by the DIS community is scaling DIS simulations over a wide-area with thousands to hundreds of thousands of simulated entities. Using the default DIS communication paradigm in which entity state information is exchanged among all participating simulators, the amount of data that must be transmitted over the network and processed by each simulatior grows on the order n^2 as the number of simulated entities increases. This is because each of the n participating entities must exchange state information with the other n-1 entities. This amount of traffic makes it difficult for large-scale DIS applications to maintain low enough latencies to support real-time interactions among participants in the distributed virtual environment. In addition to the requirement for low latencies, DIS applications require reliable exchange of entity state information and entity interaction information among the participating simulators in order to maintain the consistency of the virtual environment across all of the simulators. The original solution to these problems was to broadcast the complete state of each simulated entity to all others at rates from 2 to 15 entity- state PDUs per second. This does not scale to large configurations, therefore an alternate approach to reliable transmission is needed, in a form that is well adapted to both the multicast environment and the nature of DIS. Also, certain interactions among DIS entities require reliable unicast transactions. These transactions can occur among any two members of a large multicast group and must take place with low latency. 2.2 DIS and Multicasting A goal of the DIS community that is met by some current DIS applications is to take advantage of the multicast addressing and routing capabilities of the underlying network in order to reduce wide-area network traffic and to reduce the amount of data that must be processed at each receiver. Multicast addressing can be used to filter the data at each receiver by associating multicast groups with spatial, temporal, or functionally related classes of entities [MZPBB95]. Also, it has been noted that frequent transmission of full entity state information as a "heartbeat" for loss detection and for the benefit of late joiners is wasteful because much of this information, such as the country of origin of a vehicle, changes infrequently or not at all. Several algorithms and techniques have been proposed to reduce network traffic between sites by extending the heartbeat interval or eliminating the heartbeat altogether while still dealing with loss detection and late joiners and by compressing entity state information, using a reference/offset scheme [CSTVH95] [HSC95] [VHCS95]. The particular approach proposed for SRTP was inspired by D. Cohen [Cohen94a] [Cohen94b]. 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. This idea of sending only state data that has changed has become one of the design principles of the DoD High Level Architecture (HLA) for modeling and simulation. 2.3 Reliability vs. Latency The classic tradeoff between the fundamentally conflicting requirements for reliability and low latency becomes particularly problematic in the DIS multicast environment. By "reliable" we mean that intact delivery is confirmed automatically with a defined margin of error for confirmation. The Transmission Control Protocol (TCP) is usually used for reliable unicast communication over a wide-area network, but its use of positive acknowledgements to provide reliability makes it impractical in a large-scale multicast environment due to "ACK implosion". Further, to avoid the latency of TCP connection establishment in the middle of a real-time interaction between two entities, connections would have to be established and maintained between all pairs of entities that could possibly interact during the course of the simulation, another arrangement that does not scale. The unsuitability of TCP in a large-scale multicast environment has prompted most DIS application developers to use the User Datagram Protocol (UDP). UDP creates minimal overhead, meeting the latency requirements for DIS, but it provides no reliability. In many real- time applications, the loss or corruption of some small portion of an uncompressed data stream is tolerated, because each new PDU supersedes all others, eliminating the value of retransmitting lost or corrupted data. This is the case with uncompressed DIS entity state information, but not with the reference data when a reference/ offset scheme is used to compress DIS entity state information. Also, specific interactions in DIS still require reliable communication. Using UDP, each application is forced to make its own provisions for reliable transmission of interaction and reference entity state data. This creates an unnecessary burden for application developers, and it violates the widely-accepted layering principles used to ease the design, implementation and maintenance of communication software. Therefore, we contend that a protocol for selectively reliable transmission should be developed for use in the DIS multicast environment. In the area of reliable multicast protocols, we doubt that a generic solution is practical. We believe the protocol needed to support distributed simulation is likely to be different from other reliable multicast protocols that have been put forward for multimedia or file delivery. We characterize the DIS requirements as a selectively reliable transmission protocol with lowest possible latency in a large multicast environment under the circumstances that: 1. Some data is multicast reliably, 2. Most data is multicast best-effort, and 3. Occasional, short, reliable point-to-point transmissions are required among arbitrary members of a large multicast group. 2.4 Reliable Multicast and the HLA Such a protocol will also find direct application within the Run-Time Infrastructure (RTI) that supports DoD's new High Level Architecture, because the RTI is responsible to provide efficient real-time networking for distributed simulation in a manner similar to that required for DIS, but more general. The RTI interface specification [DMSO97] describes four types of transport services: best effort, minimum rate, state consistent and reliable. SRTP provides two of these service types. The best effort transport service is provided by SRTP mode 0, best effort multicast. The mode 0/1 data stream service that is provided by SRTP for the transmission of entity state data provides state consistent service. SRTP can be extended to provide minimum rate service by the addition of a heartbeat (mode 0). The fourth transport service, reliable service, guarantees globally-ordered delivery of all data to all subscribed receivers. SRTP does not provide such a service because we do not know of any way to provide it in real time across a large multicast group. 3. 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. Mode 0 operates as a pure best-effort service for offset data, but with reference to associated mode 1 transmissions for loss detection. Mode 1 operates with negative acknowledgements only, triggered principally by mode 0 arrivals following loss of a mode 1 message. Mode 2 uses a positive acknowledgement for each message to provide reliability and low latency by avoiding the requirement to open a TCP connection. SRTP supports reference/offset schemes for transmitting entity state information by providing an entity ID field that can be used to associate related reference and offset PDUs and by providing semantics that expect a dependent relationship between mode 1 and mode 0 PDUs with the same entity ID. SRTP expects that only a small fraction of PDUs generated by DIS applications will require reliable multicast, and an even smaller fraction will require reliable unicast. This is due to the fact that the vast majority of DIS traffic is composed of Entity State PDUs, as described in section 2 above. 3.1 Definition of Terms Locality Window Let the window size, S, be an integer in the range [0, 2^15 - 1]. Then the locality window about a particular sequence number, SN, is defined as the set of sequence numbers, SN', in [0, 2^16] such that SN' is in [SN -' S, SN +' S]. With +' and -' being defined as addition and subtraction with respect to the "wraparound" 16-bit sequence number space. a +' b = (a + b) mod 2^16 a -' b = (a - b) if (a - b) >= 0 2^16 + (a - b) if (a - b) < 0 An implementation must allow itself to be configured with any window size in the range [0, 2^15 - 1]. 3.2 Message Format An SRTP message consists of a protocol header followed by a variable amount of data. The protocol header, as shown in Figure 1, has a length of 12 bytes, and is part of every message. The remainder of the message is user data. The total length of the SRTP message, 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. Because a 1464-byte SRTP message (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, it will not be fragmented by IP in these local-area environments [Stev94]. 0 7 8 11 12 15 0 --------------------------------------------------------- --- | protocol | message | transmission | | | version | type | mode | | 16 --------------------------------------------------------- | | entity ID | | 32 --------------------------------------------------------- | | category code | msg 48 --------------------------------------------------------- header | sequence number (SN) | | 64 --------------------------------------------------------- | | | | 80 | destination group address | | | | | 96 --------------------------------------------------------- --- | payload user data (data messages only) | ... (variable length, not to exceed 1452 bytes) ... | | --------------------------------------------------------- Figure 1. SRTP Message Format Protocol Version The first byte of the message is the protocol version number. In the current version 0x01, if a received message does not have a version field with a value of 0x01 it is to be silently discarded. Message Type Bits 8, 9, 10 and 11 represent the message type. The following table lists the possible field values and describes their meaning. bit 8 bit 9 bit 10 bit 11 description 0 0 0 0 data message 0 0 0 1 negative acknowledgement (NAK) 0 0 1 0 positive acknowledgement (ACK) all other bit patterns reserved for future use Transmission Mode Bits 12, 13, 14 and 15 represent the transmission mode for the message. The following table lists the possible field values 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 all other bit patterns reserved for future use Type 1 (NAK) messages are required to be mode 1, and type 2 (ACK) messages are required to be mode 2. The three transmission modes will be discussed in detail in section 4 of this document. Entity ID Bytes 3 and 4 of the header are the entity ID of the message. An entity ID is an integer in the range 0 - 65535 that is used to associate related messages with each other. The intent of the entity ID field is to support reference/offset entity state compression, but the field can be used by an application to support any data stream in which the mode 0 messages are dependent on mode 1 messages transmitted earlier. To create globally unique entity IDs, the value of the entity ID field will be logically appended to the IP address of the sending host (available from the IP header) when a unique entity ID is required. This mechanism allows each host to generate 65536 different data streams. Category Code Bytes 5 and 6 of the header are the category code of the message. A category code is an integer in the range 0 - 65535 that is used to label messages of different application-defined classes for relevance filtering purposes. A message that is labeled with category code 0 cannot be filtered and is received by all members of the multicast group to which it is sent. The use of category 0 when not strictly necessary is strongly discouraged. This mechanism allows the set of messages to be partitioned into up to 65535 different classes. Messages labeled with the same category code may use different transmission modes. Sequence Number (SN) Bytes 7 and 8 of the header are the sequence number, or SN, of the message. The SN is an integer in the range 0 - 65535 that is used to detect missing messages and to associate specific control messages with specific data messages. The precise use of the SN field varies based on the type and transmission mode of the message. Specific details are given throughout section 4 of this document. Destination Group Address The last four bytes of the header are the IP address to which the message should be delivered. This is an IP multicast address for mode 0 and mode 1 messages and a unicast IP address for mode 2 messages. This field is redundant with the destination IP address in the IP header, but serves to identify to which multicast group a received multicast message was sent in the case where the message 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. Payload User Data Type 1 (NAK) and type 2 (ACK) messages consist solely of a 12-byte message header and do not contain any user data. Type 0 (data) messages contain up to 1452 bytes of payload user data following the message header. An implementation of SRTP must not examine, use, or change this data. It is permissible for a data message to contain 0 bytes of user data. 4. 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 messages. 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 5 of this document. Mode 0 Operation Mode 0 is for multicast messages 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 assumed to be pointless for a receiver to request retransmission of such messages when they are lost or corrupted, because any such message is very likely to have been superseded by a more recent update by the time retransmission is complete. It is generally more efficient for the receiver to simply wait for the next update to arrive. Mode 0 messages are intended to be used as frequent state updates (in offset form) to some (less frequently updated) reference state. Such offset messages will be expected to be part of a data stream that also contains reference messages (mode 1 messages with the same entity ID). Mode 0 messages are always data messages and never control messages, because no control traffic is required to support best effort service. Location fields of DIS Entity State PDUs are an example of data that should be transmitted using mode 0. Mode 1 Operation Mode 1 is used to provide reliable transmission for multicast data. A mode 1 message can be either a data message or a NAK. Mode 1 data messages are expected to be part of a data stream that is likely to contain mode 0 messages as well, but it is possible for a data stream to be comprised solely of mode 1 messages. Slowly varying or unchanging aspects (such as country of manufacture) of DIS ESPDUs are an example of data that should be transmitted using mode 1. 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 with SRTP 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. 4.1 Steps for Sending Data ================================================================================ Sending Mode 0 Data ================================================================================ 1. Validate Parameters entity ID, category, destination mc address, length of user data if category != 0, has a similar mode 1 already been sent? 2. Generate Message Version 0x01 Message Type 0x00 Transmission Mode 0x00 Entity ID user-provided Category Code user-provided Destination user-provided IPmc addr Sequence Number if category == 0, set SN to 0x00 if category != 0, set SN to SN of most recently sent mode 1 with same entity ID User Data user-provided 3. Buffer Message do not buffer 4. Send Message UDP/IPmc to dest addr ================================================================================ ================================================================================ Sending Mode 1 Data ================================================================================ 1. Validate Parameters entity ID, category, destination mc addr, length of user data 2. Generate Message Version 0x01 Message Type 0x00 Transmission Mode 0x01 Entity ID user-provided Category Code user-provided Destination user-provided IPmc addr Sequence Number set to SN of most recently sent mode 1 with entity ID incremented by 1 mod 2^16 User Data user-provided 3. Buffer Message buffer message, replacing old mode 1 with same entity ID and dest mc addr if it exists 4. Send Message UDP/IPmc to dest addr ================================================================================ ================================================================================ Sending Mode 2 Data ================================================================================ 1. Validate Parameters entity ID, category, destination unicast addr, length of user data 2. Generate Message Version 0x01 Message Type 0x00 Transmission Mode 0x02 Entity ID user-provided Category Code user-provided Destination user-provided unicast IP addr Sequence Number set to SN of most recently sent mode 2 with same entity ID incremented by 1 mod 2^16 User Data user-provided 3. Buffer Message buffer message, do not replace old mode 2 messages 4. Send Message UDP/IP to dest addr 5. Retransmit Message if no ACK is received for some period of time ================================================================================ 4.2 Steps for Receiving Data ================================================================================ Receiving Mode 0 Data ================================================================================ 1. Validate Header Data version, message type, destination group addr 2. Special Constraints if category == 0, discard if SN != 0 if category != 0, SN must equal buffered SN for most recent mode 1 with same entity ID sent to same multicast group. If this is not the case, begin NAK generation (see section 4.3) 3. Buffering do not buffer 4. Data Distribution if category == 0, distribute data to all clients registered for destination group if category != 0, distribute data to all clients registered for both category and destination group ================================================================================ ================================================================================ Receiving Mode 1 Data ================================================================================ 1. Validate Header Data version, message type, destination group addr 2. Special Constraints none 3. Buffering if no mode 1 with same entity ID has been received, SN of current msg must be buffered otherwise, if new SN is within window and <= old SN with respect to the window, discard msg otherwise, buffer new SN, replacing old SN if new SN was buffered, reset NAK suppression state 4. Data Distribution distribute data to all clients registered for both category and destination group ================================================================================ ================================================================================ Receiving Mode 2 Data ================================================================================ 1. Validate Header Data version, message type, destination addr 2. Special Constraints none 3. Buffering do not buffer 4. Data Distribution distribute to all clients registered for both category and destination group 5. Generate ACK Send ACK to sending host (see section 4.4) ================================================================================ 4.3 Negative Acknowledgements (NAKs) Sending a Negative Acknowledgement Negative Acknowledgements (NAKs) are triggered by the receipt of a mode 0 message of a nonzero category bearing a sequence number that indicates that a mode 1 message with the same entity ID has been lost. NAKs are used by SRTP for reliable multicast messages in order to avoid an "ACK implosion" at the original sender. However, with a large multicast group spread out over a congested wide-area network, there is the potential for enough group members to fail to receive the message and generate NAKs to cause considerable congestion at the original sender despite the use of NAKs instead of ACKs. For this reason, SRTP uses a NAK suppression mechanism to reduce the number of NAKs generated in response to any single lost message [VHCS95]. If a NAK is generated, it is sent at a randomly generated time in the near future. This is to avoid the situation in which several receivers all detect that a message has been missed at roughly the same time, determine that no member of their multicast group has sent a NAK for the message, 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 times a NAK has been sent for this particular mode 1 message by any member of the destination multicast group. ================================================================================ Sending NAKs ================================================================================ 1. Other NAK? Check to see if any other member of the destination group has sent a NAK for this message with some user-configurable time interval that we will refer to as the "NAK threshold". If so, no NAK is generated. 2. Generate NAK Version 0x01 Message Type 0x01 Transmission Mode 0x01 Entity ID same as message being NAKed Sequence Number same as message being NAKed Destination Addr same as message being NAKed User Data none 3. Wait for Random Interval 4. Send NAK UDP/IPmc to destination group ================================================================================ ================================================================================ Receiving NAKs ================================================================================ 1. Validate Header Fields version, transmission mode, category code, destination address 2. If this instance of SRTP has ever sent a mode 1 message with the entity ID indicated in the NAK to the multicast address indicated in the NAK, the most recent such message (which is buffered) should be immediately retransmitted to the multicast address indicated in the received NAK. 3. Whether or not step 2 results in the retransmission of a message, 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 entity ID-multicast address pair since the most recent mode 1 message 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 3 of the Receiving Mode 1 Data table above. ================================================================================ 4.4 Positive Acknowledgements (ACKs) An ACK is triggered by the receipt of a mode 2 data message. Since mode 2 data is unicast, no suppression mechanism is required for ACKs. The ACK should be transmitted with no delay. ================================================================================ Sending ACKs ================================================================================ 1. Generate ACK Version 0x01 Message Type 0x02 Transmission Mode 0x02 Entity ID same as message being ACKed Category same as message being ACKed Destination Address same as message being ACKed User Data none 2. Send ACK UDP/IP to destination address ================================================================================ ================================================================================ Receiving ACKs ================================================================================ 1. Validate Header Fields version, transmission mode, destination address 2. Remove ACKed msg from buffer (match using entity ID, SN and destination addr) 3. Stop retransmission of mode 2 message ================================================================================ 5. 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. 5.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. 5.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. Creation and Deletion of Associations An implementation of SRTP must allow applications to create and delete associations with SRTP. State is maintained for all clients having an association with SRTP. This state is required by SRTP in order to allow the application to send and receive data and to register and unregister interest in categories and multicast groups. 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 labeled 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. 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 (that is, a sender to a group need not be a receiver). 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 and the "select" system call). 5.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 labeled 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 labeled 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 labeled 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, entity ID, category code, destination group address, and multicast TTL. 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 impact of reliable multicast traffic on other Internet traffic in times of congestion is a particular concern for the IETF at this time [MaRo96]. While it is unlikely that most DIS applications, which are primarily military simulations, will be run across the global Internet, it is still valuable to examine the behavior of SRTP in times of congestion. The authors believe that the NAK-suppression used during mode 1 (reliable multicast) transmission will help reduce congestion on the wide-area network, but specific experiments need to be conducted and measurements taken in the future in order to confirm this hypothesis. 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 mode 1 messages. Whenever such a message was determined to have been lost, SRTP would identify its logging server and a NAK would be directed to this server instead of the original sender. If possible, the logger would retransmit the buffered message. Only if the message was not available at the logger would a NAK be sent over the wide-area network to the orignal source of the message. This approach avoids unnecessary interaction over the wide-area network, reducing overall latency and congestion. 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. [Coh94a] Cohen, Danny, "NG-DIS-PDU: The Next Generation of DIS-PDU (IEEE-P1278)", 10th DIS Workshop on Standards for the Interoperability of Distributed Simulations, March 1994. [Coh94b] Cohen, Danny, "DIS -- Back to Basics", 11th DIS Workshop on Standards for the Interoperability of Distributed Simulations, September 1994. [DIS94] DIS Steering Committee, The DIS Vision: A Map to the Future of Distributed Simulation, May 1994. [DMSO97] Defense Modeling and Simulation Office, High Level Architecture Interface Specification Version 1.1 Final Draft, U.S. Department of Defense, February 1997. [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. [MZPBB95] Macedonia, Michael R., Zyda, Michael J., Pratt, David R., Brutzman, Donald P., Barham, Paul T. "Exploiting Reality with Multicast Groups: A Network Architecture for Large- Scale Virtual Environments", IEEE Computer Graphics and Applications, September 1995 pp. 38-45. [MaRo96] Mankin, A. and A. Romanow, IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols, Work in Progress (Internet Draft), November 1996. [PMB97] 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), March 1997. [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 the Interoperability of Distributed Simulations, 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 the Interoperability of Distributed Simulations, September 1995. Security Considerations DIS applications are primarily military simulations and are therefore likely to be run across private networks instead of the global Internet. The use of encryption and authentication mechanisms (e.g., IPSEC) should provide sufficient security for this environment. Hosts are considered secure, and each instance of SRTP trusts its own clients that reside on the same host. Authors' Addresses Vincent P. Laviano George Mason University C3I Center Mail Stop 4B5 Fairfax, VA 22030 Phone: (703) 993-1705 E-mail: vlaviano@bacon.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@gmu.edu