Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ien / ien-192 < prev next >

Wrap

Text File | 1988-12-02 | 84.7 KB | 3,392 lines

IEN 192 HOST/SATNET PROTOCOL Bolt Beranek and Newman Inc. July 1981 Host/SATNET Protocol IEN 192 TABLE OF CONTENTS 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Satellite IMP Implementation Details . . . . . . . . . . . 4 2.1 Initialization . . . . . . . . . . . . . . . . . . . . 5 2.2 Host-to-Satellite IMP Input . . . . . . . . . . . . . . 6 2.3 Satellite IMP-to-Host Output . . . . . . . . . . . . . 8 3. DATAGRAM ACCESS PROTOCOL . . . . . . . . . . . . . . . . . 10 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Types of Service . . . . . . . . . . . . . . . . . . . 11 3.3 Addressing . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Message Length . . . . . . . . . . . . . . . . . . . . 12 3.5 Host/SATNET Flow Control . . . . . . . . . . . . . . . 13 3.6 Status Messages . . . . . . . . . . . . . . . . . . . . 14 3.7 Hello Messages . . . . . . . . . . . . . . . . . . . . 14 3.8 Message Reference Numbers . . . . . . . . . . . . . . . 15 3.9 Initialization . . . . . . . . . . . . . . . . . . . . 15 3.10 Format Errors . . . . . . . . . . . . . . . . . . . . 16 3.11 Loop Detection . . . . . . . . . . . . . . . . . . . . 16 3.12 Piggybacked Control Messages . . . . . . . . . . . . . 17 3.13 Formats . . . . . . . . . . . . . . . . . . . . . . . 17 3.13.1 Control Codes . . . . . . . . . . . . . . . . . . 17 3.13.2 Data Messages . . . . . . . . . . . . . . . . . . 18 3.13.2.1 Type of Service Word . . . . . . . . . . . . . 19 3.13.2.2 Acceptance Status Word . . . . . . . . . . . . 20 3.13.3 ACCEPTED Messages . . . . . . . . . . . . . . . . 21 3.13.4 REFUSED Messages . . . . . . . . . . . . . . . . . 21 3.13.5 STATUS REQUEST Messages . . . . . . . . . . . . . 22 3.13.6 STATUS MESSAGES . . . . . . . . . . . . . . . . . 23 3.13.7 HELLO Message . . . . . . . . . . . . . . . . . . 23 3.13.8 FORMAT ERROR Message . . . . . . . . . . . . . . . 23 3.13.9 RESTART REQUEST Message . . . . . . . . . . . . . 24 3.13.10 RESTART COMPLETE Message . . . . . . . . . . . . 25 4. STREAM ACCESS PROTOCOLS . . . . . . . . . . . . . . . . . 26 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 Stream Data Messages . . . . . . . . . . . . . . . . . 27 4.3 Stream Request Replies and Notifications . . . . . . . 28 4.3.1 CREATE . . . . . . . . . . . . . . . . . . . . . . 31 4.3.2 DELETE . . . . . . . . . . . . . . . . . . . . . . 32 4.3.3 JOIN . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.4 LEAVE . . . . . . . . . . . . . . . . . . . . . . . 34 4.3.5 CHANGE . . . . . . . . . . . . . . . . . . . . . . 34 4.4 SATNET Termination and Suspension of Streams . . . . . 35 - i - Host/SATNET Protocol IEN 192 5. Land Modem Interface . . . . . . . . . . . . . . . . . . . 37 6. Local Host Interface . . . . . . . . . . . . . . . . . . . 37 APPENDIX A. . . . . . . . . . . . . . . . . . . . . . . . . 38 A.1 Table 1 -- Request Codes . . . . . . . . . . . . . . . 38 A.2 Table 2 -- Reply Codes . . . . . . . . . . . . . . . . 38 A.3 Table 3 -- Error Codes in D3 . . . . . . . . . . . . . 39 A.4 Table 4 -- Notification Codes . . . . . . . . . . . . 39 A.5 Table 5 -- SATNET Data Message Types . . . . . . . . . 39 A.6 Table 6 -- SATNET Logical Address Map . . . . . . . . 40 APPENDIX B. . . . . . . . . . . . . . . . . . . . . . . . . 43 B.1 Figure 1. Restart State Diagram . . . . . . . . . . . 43 B.2 Figure 2. General Message Format . . . . . . . . . . 44 B.3 Figure 3. Block DATA Message . . . . . . . . . . . . 45 B.4 Figure 4. Type of Service Word . . . . . . . . . . . 46 B.5 Figure 5. Acceptance Status Word . . . . . . . . . . 46 B.6 Figure 6. ACCEPTED Message . . . . . . . . . . . . . 46 B.7 Figure 7. REFUSED Message . . . . . . . . . . . . . . 46 B.8 Figure 8. STATUS REQUEST Message . . . . . . . . . . 47 B.9 Figure 9. STATUS Message . . . . . . . . . . . . . . 47 B.10 Figure 10. HELLO Message . . . . . . . . . . . . . . 48 B.11 Figure 11. FORMAT ERROR Message . . . . . . . . . . 48 B.12 Figure 12. RESTART REQUEST Message . . . . . . . . . 48 B.13 Figure 13. RESTART COMPLETE Message . . . . . . . . 48 B.14 Figure 14. Stream Data Format . . . . . . . . . . . 49 B.15 Figure 15. Request Message Format . . . . . . . . . 50 B.16 Figure 16. Reply Message Format . . . . . . . . . . 51 B.17 Figure 17. Notification Message Format . . . . . . . 52 B.18 Figure 18. Create Request Words . . . . . . . . . . 53 B.19 Figure 19. Delete, Join, Leave Request Words . . . . 54 - ii - Host/SATNET Protocol IEN 192 PREFACE This document describes the current SATNET Host Access protocol. This supersedes PSPWN #100 (SATNET Host Access protocol) and PSPWN #104 (Host/SATNET Stream Access protocol). The differences are: (1) The initialization state diagram has been changed so that neither side will enter the ON state unless both sides of the connecting transmission line are working. (2) A "Host type" field was added to the Restart Request and Restart Complete messages. (3) The numeric values of some error codes have been changed, as have the detailed meanings of some of those codes. (4) Some Stream Reply Codes have been changed. (5) Some significant changes have been made to the information supplied by hosts in Stream Create and Change request messages. (6) Hosts must use the acceptance/refusal flow control strategy in response to data messages from Satellite IMPs (i.e., this is no longer an option). - iii - Host/SATNET Protocol IEN 192 1. Overview In determining an appropriate host access protocol, several factors must be considered. One set of factors concerns regulation of transfers in either direction across the host-network interface. A second set of factors concerns actions associated with the transmission of messages across the network. While there are several different protocols in existence which deal with link and network access (e.g., SDLC and X.25), none satisfies the totality of user services and other factors unique to SATNET. Thus to allow flexible exploration of access issues, a special protocol was developed for the network transmission level. (For implementation convenience, however, an existing ARPANET link error control protocol was used to provide reliable interface transfers.) The network-level access factors include the passing of type-of-service information such as priority and delay class, the passing of flow and congestion control information, coordination of stream data messages with their scheduled times, and mechanisms for dynamic stream and addressing setups. The type-of-service information is dealt with by defining an appropriate field in the message headers. This field currently consists of eight bits in SATNET: Two bits for message type (datagram/stream and internet designations), two bits to specify - 1 - Host/SATNET Protocol IEN 192 one of four priorities, two bits to specify one of four delay classes, one bit to specify a holding time choice, and one bit to specify reliability. The delay class choices presently consist of one second, five seconds, twenty seconds, and two minutes. The holding time choice consists of either twice the specified delay class or two minutes. The reliability choice consists of "high", which causes channel retransmissions to be used, or "standard", which inhibits the use of retransmissions and allows messages with bad data checksums (but good checksums on their control information) to be delivered to users. Standard reliability is designed for applications which can tolerate occasional bit errors, but cannot tolerate lost or out-of-order packets (e.g. packet speech). Flow and congestion control information is passed by the use of two distinct mechanisms. First, status information reflecting current congestion control is sent in all data and related control messages; in the absence of other traffic, a special status message is sent periodically. This information indicates which priority and delay classes are currently being accepted by the network. The second mechanism consists of specific information concerning the disposition of each data message passed to the network. Each data message is numbered (modulo 128) by the - 2 - Host/SATNET Protocol IEN 192 sending host for identification purposes. Upon receipt, the network returns an "acceptance" or "refusal" indication to the host. An acceptance implies the network believes it can deliver the message to its destination and is proceeding to do so; delivery, however, is not guaranteed. A refusal means the network has discarded the message; in this case a refusal subcode is included to indicate the reason. Messages may be refused because, for example, the destination is down or does not exist, because its priority or delay class is not being accepted, or because of temporary flow control reasons associated with source or destination buffering. In the latter case the message is assigned to one of several categories used for subsequent notification purposes. A bit representing each category is passed along with the priority-delay class status information in all messages. When the message is refused the number of the assigned category is returned to the sender, with the values of subsequent category status bits indicating when messages of that category will again be accepted. In order to minimize message delays and to schedule stream slots efficiently, the coordination of stream data messages involves establishment of the correct time window in which the host should pass each message to the network. The present system uses explicit accept/refuse messages to accomplish this. Stream and addressing setups are accomplished by using datagram messages between the hosts and the network. - 3 - Host/SATNET Protocol IEN 192 2. Satellite IMP Implementation Details For each physical host port the software uses the following data structures: Protocol state word, Category queues, Host output queue, Accept/refuse queue (HAQ), Interface property table, Last-heard word (LSTHRD). The protocol state word indicates whether the protocol is in initialization or running state. If in initialization state, no messages will be accepted or delivered until the necessary handshaking procedure, as described below, is completed. The four category queues are used to store messages that have been refused by a host. If a host refuses a message and provides an appropriate category indication, the message will be stored on the specified category queue until the host indicates it is willing to accept messages of that category. If a message reaches its maximum holding time before the host will accept it, it will be dropped from the queue. The host output queue is a queue of data messages waiting to be delivered to the appropriate host. Ordered by urgency, all messages remain on this queue until they are transferred into the HAQ just prior to being sent to the host or until their holding time expires. - 4 - Host/SATNET Protocol IEN 192 The HAQ is a storage location for a message that has been sent to the host and is awaiting an accept or refuse response. If a response is received, the message is removed from the queue. If no response is received, the message will be removed when its maximum holding time has expired. The interface property table (IPT) is used to indicate any of the various protocol options selected by a host. One such option is whether to allow piggybacking of Host/SATNET control messages. Another option is that the host may decline to do accept/reject decisions on traffic that it receives from SATNET. The last-heard word indicates when the host was last heard from. The host is declared down if it has not been heard from in a specified time, currently about thirty seconds. The host will remain down until the necessary handshaking is completed. 2.1 Initialization Whenever a host or Satellite IMP is restarted, it sends a RESTART-REQUEST control message to the other party. This message will be repeated periodically until a RESTART-COMPLETE message is received from the other party. When the RESTART-COMPLETE message is received by the first party, it will then also send a RESTART-COMPLETE message. - 5 - Host/SATNET Protocol IEN 192 2.2 Host-to-Satellite IMP Input For datagram traffic, SATNET accepts variable-length messages of up to a fixed maximum length (currently 128 16-bit words). The host prefixes each message with a header which provides addressing and control information. The control information specifies priority, desired delivery delay, maximum holding time, and selection of message control options such as reliability. Each datagram message from a host is accepted or rejected by the Satellite IMP according to the current network loading and other factors. The Satellite IMP always returns a control message indicating acceptance or refusal. The message control parameters have the following possible values: Priority is an integer from zero to three, with three being the lowest priority and zero the highest. There are four possible delay classes: 1 second, 5 seconds, 20 seconds, and 120 seconds. There are two possible choices for maximum holding time: twice the delay class or the maximum system holding time. Reliability may be either normal or high reliability (zero or one). Initially, when a message is offered by a host, a minimal amount of buffer is requested at high priority, and the header of the message is copied into this buffer in SATNET internal format. The information in the header is then presented to the - 6 - Host/SATNET Protocol IEN 192 Accept/Reject module. If the message is accepted the additional buffer needed is obtained, the rest of the message is copied into the buffer, and an accept message is placed on the accept/reject notification list (ARN). If the message is rejected, the appropriate rejection code is placed on the ARN and the buffer space is freed. It is left for the host to decide whether to resubmit the message at a later time. The rejection code will also inform the host of which priority and delay classes are currently being accepted, to assist the host in making message offering decisions. The accept/reject decision is performed as follows: The first checks are made to ensure a valid source ID, adequate buffer in the Satellite IMP, and a message size not exceeding the maximum allowed size. The Satellite IMP must also be in the In-Sync state to be able to accept the message. For any message passing these tests, its TTG and priority are calculated, and used to form its urgency value. Next a check is made to see if the message can be delivered to the destination, which involves checking a table of destination parameters. The Satellite IMP verifies that the destination Satellite IMP and host are up and are receiving messages of the same category as the offered message. - 7 - Host/SATNET Protocol IEN 192 Although not implemented, the following checks are considered useful. If the reservation-making queue contains too much traffic of higher urgency or if the number of free buffers is below a fixed threshold, the message will be refused. Also, a maximum buffer usage may be assigned to each host for messages of each category; messages will be refused if the threshold is exceeded for messages of the same category. A stream packet undergoes a different set of checks before it is accepted by the Satellite IMP. The stream must exist, the length of the message must not exceed the maximum allowable for that stream, and there must be room available on the stream queue for another packet. Also, the offering host must be designated as a member of that stream. 2.3 Satellite IMP-to-Host Output Whenever there is an opportunity to send a message to a host, the Satellite IMP will examine every eligible queue to determine which message should be sent first. This includes the host output queue, the four category queues, and the control message waiting queue (ARN). If ARN is longer than a specified threshold, sending of control messages will take precedence over sending of data messages, until the ARN length falls below the threshold. Otherwise, if piggybacking is allowed, a data message will be sent to the host with a control message piggybacked. If - 8 - Host/SATNET Protocol IEN 192 no piggybacking is allowed, then control messages and data messages will compete. Competition is always on the basis of urgency (priority and TTG). A category queue may be ineligible if the host is not accepting messages of that category. In the absence of other traffic, a Satellite IMP will send a 'HELLO' message every second. Once a data message has been selected it is queued in HAQ and transmitted to the host. If the host fails to respond in time, the message will be deleted from HAQ when its holding time expires. If the host accepts, the message will be removed from HAQ and discarded. If the host refuses and specifies a category, the message will be removed from HAQ and placed on the specified category queue. If the message is refused for urgency reasons, the message will be requeued on the host output queue. HAQ, the category queues, the host output queues, and ARN are all kept ordered by urgency, so that testing for the most urgent message consists of testing only the first message on each queue. - 9 - Host/SATNET Protocol IEN 192 3. DATAGRAM ACCESS PROTOCOL 3.1 Overview For datagram traffic, SATNET accepts variable-length messages of up to 128 words of data. The source host prefixes each message with a leader which provides addressing and control information. The control information specifies message priority, desired delivery delay, delay at which the message should be discarded if not yet delivered ("maximum holding time"), and selection of one or more message control options. Each datagram message from a source host is accepted or refused by the source Satellite IMP according to current network loading and other factors, with a control message always returned by the source Satellite IMP indicating the acceptance or refusal. Upon acceptance, SATNET then attempts to deliver the message within its specified delay. However, it will continue trying to deliver if late, until its maximum holding time is exceeded. Datagram messages always have at least a two-hop delay (about 0.6 seconds) within SATNET. A lower-level protocol is assumed to provide reliable exchanges of data and control messages on the link connecting a host and Satellite IMP, and is assumed transparent to the protocol defined in this document. The Honeywell 316 Satellite IMPs use the ARPANET VDH protocol for this purpose. The new BBN - 10 - Host/SATNET Protocol IEN 192 C/30 Satellite IMPs support in addition ARPANET 1822 local host and distant host protocol. 3.2 Types of Service The type-of-service fields in the SATNET leader of each datagram message allows the following choices to be specified to SATNET for each message: Priority: 4 choices. This is used in conjunction with the acceptable delivery delay to arbitrate for SATNET resources. Acceptable Delivery Delay: 1 second, 5 seconds, 20 seconds, and 120 seconds. Holding Time: This is the maximum time an undelivered message should be held within SATNET before discarding. There are two choices: (1) twice the specified delivery delay, or (2) the maximum system holding time (currently about two minutes). Reliability: There are two choices, "standard" and "high". If standard is specified, a satellite channel acknowledgment is not used for the message, and it is not retransmitted by the source Satellite IMP in case of errors; if the packet is received at the destination Satellite IMP with a good message leader but errors in - 11 - Host/SATNET Protocol IEN 192 the data portion of the message, it is marked as such and delivered to its destination. If "high" is specified, the message is retransmitted as many times as necessary until a positive acknowledgment is received by the source Satellite IMP, up to the specified message holding time (duplicate copies may be delivered to the destination host in this case). 3.3 Addressing SATNET uses logical addressing, with each host assigned a 16-bit permanent address. Each data message sent to SATNET must contain both a source and destination logical address, and is delivered to the specified destination(s) with these addresses unchanged. Table 6 in Appendix A contains the current list of addresses. 3.4 Message Length Datagrams may have variable lengths, where these lengths are integer multiples of 16-bit words. Maximum length of the data portion of a datagram message is 128 words. The "data portion" excludes the SATNET leader but includes an internet header if present. - 12 - Host/SATNET Protocol IEN 192 3.5 Host/SATNET Flow Control Each message sent by a host is accepted or refused by the Satellite IMP based upon various network and local congestion and status factors. If accepted, an ACCEPTED control message is returned to the host containing the message ID assigned by the host in the data message leader. If refused, a REFUSED control message is returned containing the message ID and a refusal code C. If the message itself is bad, a FORMAT ERROR control message is returned containing the message ID. The value of C is used to indicate to the host when it should subsequently retry the message. This is accomplished by also sending the host an "acceptance status" word at frequent intervals to inform it of the categories currently being accepted. The host may ignore the category information if it chooses, or map the categories into a smaller subset if convenient. The use of the categories allows the host to retry those messages first which are most likely to be accepted by the Satellite IMP. The "acceptance status" word also contains information indicating which message priorities and delivery delay classes are currently being accepted, allowing the host to also avoid unnecessarily sending new messages which will be refused. The acceptance status word is sent to the host in every data and - 13 - Host/SATNET Protocol IEN 192 control message from the Satellite IMP; in the absence of regular traffic, a "Hello" message containing the acceptance status word is sent once per second. Hosts must return an explicit acceptance or refusal for each message received from the Satellite IMP. Note that a "refusal" by the host is a request to the Satellite IMP to requeue the message in question and submit it again later. Currently, refused messages are immediately discarded, so as to eliminate a line congestion problem seen with the catenet. 3.6 Status Messages A host can request current status information from SATNET by sending a "Status Request" control message. The Satellite IMP will return a status message containing the acceptance status word, SATNET global time, and an indicator of the current delay expected for each delivery delay class. (Inclusion of host status information is still under study.) 3.7 Hello Messages When it is not sending data or control messages, the Satellite IMP or host must send a "Hello" control message once every second. In addition to providing frequent updating of acceptance status, the hello message allows the receiver to maintain the up/down status of the sender. The Satellite IMP - 14 - Host/SATNET Protocol IEN 192 will do this by resetting a timeout counter whenever anything is received from the host; if the timeout expires, the host will be declared down and the Satellite IMP will begin sending restart messages as described in the next section. The timeout value used by the Satellite IMP is thirty seconds. 3.8 Message Reference Numbers To support message-by-message acknowledgements, each data message is assigned a 7-bit "message reference number" by its sender. Its purpose is to allow referencing of the message in a subsequent acknowledgement (ACCEPTED, REFUSED, or FORMAT ERROR) message. Reference numbers may be assigned in any order, except that a particular number may not be reused until the message it refers to has been acknowledged. All reference numbers are automatically released whenever the Host/SATNET interface is reinitialized. 3.9 Initialization Since the Host/SATNET protocol requires an explicit acknowledgement for each message, the initialization procedure ensures that full two-way communication is possible before allowing either side to begin transmitting data. Whenever a host or a Satellite IMP is restarted, it sends a RESTART REQUEST control message to the other party once every ten seconds until a RESTART COMPLETE is received, at which time it sends a RESTART - 15 - Host/SATNET Protocol IEN 192 COMPLETE. The procedure in initializing the interface is shown in Figure 1 in Appendix B. The initialization action indicated in Figure 1 consists of flushing all queued control messages waiting to be sent, and of flushing all received data messages for which an ACCEPTED or REFUSED message has not already been sent. Note that data messages waiting to be sent need not be flushed; they can continue to be queued during the 'waiting' state and their transmission begun once the 'on' state is entered. 3.10 Format Errors Whenever an invalid leader field value or message length is detected in a received message a FORMAT ERROR control message is returned to the sending host or Satellite IMP. An error code is returned in this message to indicate the detected condition (these codes are defined in the Formats section of this document, section 3.13). 3.11 Loop Detection To allow a Satellite IMP or host to detect situations in which the interface may be externally looped (crosspatched), a Host/Satellite IMP address bit is included in all data and control messages, identifying the sender of each message. - 16 - Host/SATNET Protocol IEN 192 3.12 Piggybacked Control Messages Control messages of the ACCEPT, REFUSE, FORMAT ERROR, and RESTART COMPLETE types may be piggybacked onto data messages by including the control message in the 16-bit "piggyback" field of the data message header. The Satellite Imp interprets all piggybacked control information before examining the rest of the data message, so, for example, a piggybacked RESTART COMPLETE takes effect immediately. 3.13 Formats The general format used for Host/SATNET interface exchanges is shown in Figure 2 (all figures are in Appendix B). The control code always defines the message format; for all except data messages, it also implicitly defines the message length. Exact data message length is assumed to be derived from the host or Satellite IMP interface transfer, and is always an integer multiple of 16-bit words. 3.13.1 Control Codes Each distinct message type is identified by a unique 4-bit control code. Codes currently defined are: - 17 - Host/SATNET Protocol IEN 192 1 = DATA 2 = ACCEPTED 3 = REFUSED 4 = STATUS REQUEST 5 = STATUS 6 = HELLO 7 = DATA WITH ERRORS 13 = FORMAT ERROR 14 = RESTART REQUEST 15 = RESTART COMPLETE 3.13.2 Data Messages Figure 3 shows the format for datagram DATA messages (the width of each word in this and subsequent figures is 16 bits). Words 1, 2, and 3 are defined by the interface sender (host or Satellite IMP); words 4, 5, and 6 are defined by the source host. Word 1, datagram message control word: - H/S, bit 1: 0 = from Satellite IMP, 1 = from host - message ID, bits 2-8: defined in Section 3.6 - block length, bits 9-12: the number of 64-word blocks of data words following the message leader: a block length of 1 means the message contains between 1 and 64 data words; a length of 2 means 65 and 128 data words, etc. The maximum datagram length is defined by Section 3.2. A length of 0 means a null DATA message. - Control Code, bits 13-16: 1 = DATA (no detected errors) - 18 - Host/SATNET Protocol IEN 192 7 = DATA WITH ERRORS -- used only if "standard reliability" service is designated and one or more data errors were detected by SATNET in the data portion of the message. Applies only to packets delivered by SATNET to hosts. Word 2, acceptance status: (defined below). Word 3, piggyback field: This word may contain any of the one-word control messages defined by codes 2, 3, 13, and 15. A value of zero means the word is not used. Word 4, Type of Service Word: (defined below). Word 5, destination host: a 16-bit SATNET logical address. Word 6, source host: a 16-bit SATNET logical address. 3.13.2.1 Type of Service Word Figure 4 shows the details of word 4 of datagram DATA message leaders. M, bits 1-2: DATA message type; 0 = datagram, internet format 1 = stream, internet format 2 = datagram, local format 3 = stream, local format - 19 - Host/SATNET Protocol IEN 192 P, bits 3-4: priority; 0 = highest priority, 3 = lowest. D, bits 5-6: acceptable delivery delay ("delay class"); delay class value ----------- ----- 0 1 second 1 5 seconds 2 20 seconds 3 120 seconds H, bit 7: holding time; 0 = maximum (120 seconds*), 1 = twice the specified delay class. R, bit 8: reliability; 0 = high, 1 = standard 3.13.2.2 Acceptance Status Word Figure 5 shows the details for this word. If the entire word equals 0, everything is being accepted. Category bits, bits 1-4: each bit defines the current acceptance/refusal status for the category corresponding to the bit number (e.g., bit 3 represents category 3). 0 = accepting for this category 1 = refusing Delay Class Priority, bits 5-16 (not currently implemented): each delay class is identified by its position within the acceptance status word; e.g., bits 14-16 contain information for delay class 3. The content of each three-bit field is a binary number defining the current priorities being accepted for that delay class, interpreted as follows: - 20 - Host/SATNET Protocol IEN 192 0 = all priorities accepted 1 = lowest priority (3) not accepted 2 = lowest two priorities (2,3) not accepted 3 = lowest three priorities (1,2,3) not accepted 7 = none accepted 3.13.3 ACCEPTED Messages Figure 6 shows the format of ACCEPTED messages. (An acceptance status word, as defined in Figure 5, is always the second word of this and all other messages.) H/S, bit 1: same as for Data messages. Data message ID, bits 2-8: The message ID of the DATA message being accepted. Control Code, bits 13-16: ACCEPTED = 2. 3.13.4 REFUSED Messages Figure 7 shows the format of REFUSED messages. H/S, bit 1: same as for DATA messages. Data message ID, bits 2-8: The message ID of the DATA message being refused. C, bits 9-12: refusal category. A value of 0 to 4 means a refusal due to temporarily unavailable resources. Messages refused with category values 1 to 4 will not be accepted until the corresponding category - 21 - Host/SATNET Protocol IEN 192 bit in the acceptance status word becomes 0. A category value of 0 means the refusal is because of the message priority and/or delay class; acceptance information for this case is given by the delay class priority bits in the acceptance status word. Values of C have the following meanings (acceptance status word information does not apply to values 8 to 15): 0 = refused for priority/delay class 1 = category 1 refusal 2 = category 2 refusal 3 = category 3 refusal 4 = category 4 refusal 5 = undefined 6 = undefined 7 = undefined *8 = data length greater than stream length 9 = destination host has been declared in a "refusing" state 10 = destination host is not reachable 11 = destination host's Satellite IMP is not reachable 12 = unrecognized destination address 13 = destination host access not allowed 14 = illegal source host *15 = no active stream with that stream ID *(See Section 4 on stream access) Control Code, bits 13-16: REFUSED = 3. 3.13.5 STATUS REQUEST Messages Figure 8 shows the format of STATUS REQUEST messages. H/S bit 1: same as DATA messages. Control code, bits 13-16: STATUS REPORT = 4. - 22 - Host/SATNET Protocol IEN 192 3.13.6 STATUS MESSAGES Figure 9 shows the format of STATUS messages. Word 1: H/S bit, bit 1 = same as DATA messages. Control Code, bits 13-16: STATUS = 5. Word 2: ACCEPTANCE STATUS Word 3, SATNET global time: current internally synchronized clock time used by Satellite IMPs; unit of time = 10.24 milliseconds, maximum value equals 2{16} -1 units. Words 4-7: current expected delay for the indicated delay class (values to be defined). 3.13.7 HELLO Message Figure 10 shows the status of Hello messages. H/S bit 1: same as DATA messages. Control Code, bits 13-16: HELLO = 6. 3.13.8 FORMAT ERROR Message Figure 11 shows the format of FORMAT ERROR messages. - 23 - Host/SATNET Protocol IEN 192 H/S bit 1: same as DATA messages. Error Message ID, bits 2-8: ID of DATA message with format error (if applicable, otherwise = 0). Error Code, bits 9-12: 0 = undefined error 1 = data message length exceeds SATNET maximum size 2 = illegal control code 3 = block length disagrees with message length. 4 = illegal control code in piggyback word of data message. 5 = undefined category value (5-7) in REFUSED message. Control Code, bits 13-16: FORMAT ERROR = 13. Note: Implementation of error codes 2 to 5 is optional; however, a FORMAT ERROR message should be returned with (at least) error codes 0 and 1 for illegal conditions. 3.13.9 RESTART REQUEST Message Figure 12 shows the format of RESTART REQUEST message. H/S bit 1: same as DATA messages. Host Type, bits 9-12: presently undefined. Control Code, bits 13-16: RESTART REQUEST = 14. - 24 - Host/SATNET Protocol IEN 192 3.13.10 RESTART COMPLETE Message Figure 13 shows the format of RESTART COMPLETE messages. H/S bit 1: same as DATA messages. Host Type, bits 9-12: presently undefined. Control Code, bits 13-16: RESTART COMPLETE = 15. Note: All Restart Request and Complete messages sent by the Satellite IMP have bits 9 to 12 set to zero. - 25 - Host/SATNET Protocol IEN 192 4. STREAM ACCESS PROTOCOLS 4.1 Overview In addition to datagram message service, SATNET provides a service called 'stream'. A stream is a sort of virtual circuit in which information must be established within Satellite IMP tables for the duration of the stream use. This information maintains an outstanding reservation for the stream, causing channel time to be scheduled at more or less regular intervals specified in the stream setup. This mechanism provides one of the important performance properties of a stream which motivates its use: one-hop for each stream data packet (as opposed to at least two hops for datagrams). Any number of hosts can use the same stream; host membership is accomplished by special Host/SATNET messages. Each stream is identified by a SATNET-assigned Stream ID, which has two distinct functions. The first is to allow Satellite IMPs to identify the transmission properties being used for each stream data message including verification that the sending host is a stream member. The second Stream ID function is its optional use as a destination address in a stream or datagram data message, causing delivery to the Stream ID members. (Its use in datagram messages allows "out of band" signaling messages to be sent while the stream data messages are also being sent.) - 26 - Host/SATNET Protocol IEN 192 The destination address in a stream data message is not limited to the Stream ID, however; any SATNET address may be used. Thus, a host can set up a simplex stream in which it is the only member, and therefore the only sender, and send messages to different hosts using the single stream. Or, a set of hosts can use a single stream in an arbitrarily shared manner (determined by the hosts) to send to arbitrary destinations. More typically, a stream would be used by a set of hosts for voice conferencing, in which the Stream ID would be used as the destination address. Note that, in all cases of shared use, hosts must provide a protocol to determine how the stream is shared. If every member host presented a stream data packet to its Satellite IMP at the same time, they would all be sent simultaneously in the satellite channel with resultant destructive interference. (Note: the addressing use of a Stream ID is not presently implemented -- only permanent SATNET addresses, either point or group, are allowed.) 4.2 Stream Data Messages Stream data messages have the format shown in Figure 14. The message type (bits 1 and 2 of word H4) may be either 1 (stream data, internet format) or 3 (stream data, local format).(1) Bits 3 to 16 of word H4 contain a Stream ID, _________________________________________________________________ (1) Table 5 in Appendix A defines all SATNET message types. - 27 - Host/SATNET Protocol IEN 192 assigned by SATNET as described in the next section. The destination address in word H5 can be any SATNET address. The source host address in word H6 must be assigned to the Satellite IMP port used to send the message into SATNET, and must be a member of the Stream ID. An ACCEPTED or REFUSED message will be returned by the Satellite IMP for each stream data message, the same as for datagrams. Stream data messages will normally always be accepted unless they are greater than (to be determined) seconds early relative to the next stream slot time, or the stream is being preempted by higher priority traffic. Internal SATNET channel acknowledgments are not used for stream data messages. 4.3 Stream Request Replies and Notifications Streams can be used by a Host only by first establishing certain information within SATNET. The following requests are used: CREATE DELETE JOIN LEAVE CHANGE Each request is sent by the host, along with supplemental information, in the data portion of a datagram message to the - 28 - Host/SATNET Protocol IEN 192 SATNET Service Host. A Request message is accepted or refused by the local Satellite IMP the same as any other datagram message; if accepted it is delivered to an internal host within the local Satellite IMP which acts on the request, returning a datagram message reply to the source host indicating its disposition. The reply always contains a Request ID supplied by the host in its Request message, allowing the host to relate the response to its earlier request (more than one Request message may be outstanding from a host; the maximum number outstanding will be limited implicitly by the datagram message refusal mechanism). Figure 15 shows the format used for Request messages, which are always local datagram (type 2). The Request message priority PR in header word H4 may be assigned the same as for other datagram traffic. The source host address must be assigned to the Satellite IMP port used for the message. The first data word D1 contains one of the Request Codes defined in Table 1. The Request ID in word D2 is chosen by the host, and should not be re-used until a Reply message is received with the same ID to avoid ambiguity. Figure 16 shows the format used for Reply messages, which are always local datagram (type 2). The values of PR and the Request ID are those used by the host in the Request messages; the source host address of the Request message is used as the destination host address. Word D1 contains a Reply Code in bits - 29 - Host/SATNET Protocol IEN 192 2 to 16 indicating the action taken on the request; bit 1 is always zero. The contents of words D3-D6 depends on the Reply Code; whether used or not, all Reply messages will contain six data words. Table 2 lists the possible Reply Codes. In addition to Reply messages, a Notification message may be sent to a host by SATNET concerning streams for which the host has previously established membership. The Notification message format is shown in Figure 17, and is also a local datagram type message. The notification message priority PS in word H4 is that assigned to the stream; the Stream ID involved in the notification is contained in data word D2. A Notification Code is contained in bits 2 to 16 of word D1; bit 1 of this word is always set to 1 to distinguish Notification messages from Reply messages. As in the case of Reply messages a Notification message always contains words D3 to D6, whose contents depend on the Notification Code. Table 4 lists the Notification Codes. (Notifications not implemented.) Except when a request is refused as a result of information local to the source Satellite IMP, Notification messages have a delay of at least one satellite hop (about 0.25 seconds) relative to the request message, and are initiated at approximately the same global SATNET time by Satellite IMPs to their involved hosts. A Reply indicating successful completion of a stream request requires at least five seconds' delay after receipt of the request. - 30 - Host/SATNET Protocol IEN 192 4.3.1 CREATE The words used in the data portion of a CREATE request are shown in Figure 18. Word D3 contains a zero if a new stream is being requested (the use of non-zero values will be defined in a later version of the Host/SATNET access protocol). Words D4-D6 contain a Key which is used to authenticate subsequent requests from any host concerning the stream. Any 48-bit value may be used, including zero; however, all subsequent Request message Keys for this stream must equal this Key to be honored. Words D7-D9 define the parameters to be used for the stream by SATNET. Ps is the priority to be used for the stream data messages. Bits 7 to 16 of word D7 indicate the maximum number L of 16-bit data words which will be sent in any data message using the stream. The queue length, bits 1-4 of D8, is the maximum number of messages that may be queued at once awaiting transmission using the stream. The stream interval is a 24-bit quantity indicating the time (in ten microsecond units) between stream messages. The high order eight bits are in D8, bits 9-16, and the low 16 bits are in D9. A suitable time for messages in this stream will be computed using the stream interval given. If the CREATE is honored, Stream Started Reply message will be returned with the Stream ID assigned by SATNET in word D3 (words D4-D6 are not used). The first stream channel allocation - 31 - Host/SATNET Protocol IEN 192 is begun approximately one stream interval I following generation of the Reply message. If refused, a Stream Creation Refused will be returned with a reason code in Word D3. Each CREATE message received with word D3 set to zero will cause the creation of a new stream (resources permitting), independently of the Key or other field values contained in the CREATE message. Note that different streams may use the same Key; the SATNET-assigned Stream ID supplied by hosts in subsequent Request messages provides unique referencing to the stream in question. 4.3.2 DELETE Figure 19 shows the data words sent in a DELETE Request. Word D1 contains the DELETE STREAM Request Code; word D2 contains the host's Request ID (this ID need not relate to any previous Request message); word D3 contains the Stream ID; words D4-D6 contain the Key. If the DELETE STREAM request is honored, the stream channel allocations will be terminated and a Stream Deleted Reply message will be returned with the Stream ID in word D3; words D4-D6 are not used. In addition, a Notification message ("Stream Deleted by Host X") will be sent to all other member hosts, with the address of the requesting host in D3 (not implemented yet); words D4-D6 are not used. All Satellite IMP table entries concerning - 32 - Host/SATNET Protocol IEN 192 the stream will be cleared and the Stream ID released for re-use. If the DELETE STREAM request is not honored, a Stream Deletion Refused Reply will be returned. Word D3 will indicate why the request was refused. Table 3 indicates the refusal reasons that can appear in D3. 4.3.3 JOIN A JOIN Request (not implemented yet) is used by a host to establish membership in a stream previously created by another host. (It is the responsibility of the creating host to distribute the assigned Stream ID and Key to those hosts it wishes to have participate in the use of the stream.) The format shown in Figure 19 is used for a JOIN, with the JOIN STREAM Request Code in word D1. If the stream exists and the correct Key is supplied, a Stream Joined Reply message is returned approximately one stream interval prior to the next scheduled channel allocation for the stream. Word D3 of the reply message contains the Stream ID; words D4-D6 contain the parameters currently used for the stream, formatted according to words D7 to D9 of Figure 5. Also, a Notification Code 3 Message ("Stream Joined by Host X") is sent to all other member hosts--word D3 contains the address of the newly joined host; words D4-D6 are not used. - 33 - Host/SATNET Protocol IEN 192 If the JOIN is not honored, a Join Refused Reply message will be returned with a Table error code as appropriate. 4.3.4 LEAVE A host may leave a stream of which it is a member by use of a LEAVE Request (not implemented yet). The format of Figure 19 is again used, with the Request Code = 4. If the stream exists and the host is entered as a member in Satellite IMP tables, a Stream Left Reply message will be returned. Note that the Key is not used for this request. Also, a Notification Code 4 message ("Stream Left by Host X") is sent to all member hosts; word D3 contains the address of the departed host; words D4-D6 are not used. A Leave request will always succeed. However, in some cases it may be impossible to notify other stream members of the event. If so, a Leave Without Notification Reply message will be returned. Word D3 will indicate why notification could not be made. 4.3.5 CHANGE A host can request changes to the parameters defining a stream by use of a CHANGE request (not implemented yet). This message is identical to the CREATE message format of Figure 18, except that the Request code is set to 5 in word D1 and word D3 - 34 - Host/SATNET Protocol IEN 192 contains the Stream ID. All parameters of words D7-D9 must be defined, whether or not their values are being changed -- if allowed, the parameters will be used to re-define the stream characteristics just as if they were being supplied in a CREATE request. If the changes can be honored, a Stream Changed Reply message will be returned with the Stream ID in word D3; words D4-D6 are not used. Also, a Notification code 5 message ("Stream Changed by Host X") is sent to the other member hosts; word D3 contains the address of the requesting host; words D4-D6 contain the new parameters. If the changes cannot be made, a Stream Changes Refused Reply message is returned to the requesting host, with a reason code in word D3 (see Table 3). 4.4 SATNET Termination and Suspension of Streams A stream termination will be initiated by SATNET if (1) a data message is not sent in the stream by any of the member hosts for sixty seconds, or (2) if the stream's channel allocation cannot be honored for N (to be determined) consecutive stream intervals I due to higher priority traffic (not implemented yet). If either of these occurs, a Notification code 1 message ("Stream Deleted by SATNET") will be sent to all member hosts with an appropriate reason code in word D3; words D4-D6 are not used. - 35 - Host/SATNET Protocol IEN 192 All Satellite IMP table entries concerning the stream will be deleted and the Stream ID released for re-use. Whenever a stream's channel allocation has not been honored by SATNET for M (to be determined) consecutive stream intervals I following the last allocation, a Notification Code 6 message ("Stream Suspended") is sent to all member hosts (M will be much smaller than N). If the allocations are resumed before N consecutive non-allocations, a Notification Code 7 message ("Stream Resumed") is sent to all member hosts. (These are not implemented yet.) - 36 - Host/SATNET Protocol IEN 192 5. Land Modem Interface A Satellite IMP communicates with other IMPs and with Very Distant Hosts via communication circuits, such as those provided by the various common carriers (Bell, Western Electric, etc.) The exact nature of the synchronous modems and dedicated full duplex lines varies from site to site. The hardware interface to the modem is the standard BBN IMP-modem interface which is logically identical to the Bell 303 interface with the exception that the mark and space convention is inverted for characters sent to the modem (i.e., binary "one" equals high current). The control lines, however, are not inverted. 6. Local Host Interface Local Host computers interface to the Satellite IMP via a hardware interface which is electrically equivalent to that used in the ARPANET between hosts and IMPs. The electrical specification for this interface appears in BBN Report No. 1822 entitled "Specifications for the Interconnection of a host and an IMP". - 37 - Host/SATNET Protocol IEN 192 APPENDIX A. A.1 Table 1 -- Request Codes 1 -- Create Stream 2 -- Delete Stream 3 -- Join Stream 4 -- Leave Stream 5 -- Change Stream Parameters A.2 Table 2 -- Reply Codes 1 -- Stream Started 2 -- Stream Deleted 3 -- Stream Joined 4 -- Stream Left 5 -- Stream Changed 6 -- Stream Creation Refused 7 -- Stream Deletion Refused 8 -- Join Refused 9 -- Leave without Notification 10 -- Stream Changes Refused 11 -- Illegal Request Code - 38 - Host/SATNET Protocol IEN 192 A.3 Table 3 -- Error Codes in D3 0 -- System busy; unable to handle request 1 -- Unimplemented function 2 -- Invalid protection Key 3 -- Not member of stream 4 -- Stream does not exist 5 -- Net trouble 6 -- Insufficient resources to handle request 7 -- Improper format for request 8 -- Channel protocol does not support streams 9 -- Illegal argument in stream request 10 -- Channel access not allowed A.4 Table 4 -- Notification Codes 1 -- Stream Deleted by SATNET 2 -- Stream Deleted by Host X 3 -- Stream Joined by Host X 4 -- Stream Left by Host X 5 -- Stream Changed by Host X 6 -- Stream Suspended 7 -- Stream Resumed A.5 Table 5 -- SATNET Data Message Types 0 -- Datagram, internet format 1 -- Stream data, internet format 2 -- Datagram, local format 3 -- Stream data, local format - 39 - Host/SATNET Protocol IEN 192 A.6 Table 6 -- SATNET Logical Address Map 0 -- 0 SATNET Service Host 1 -- Etam EXPAK fake host 2 -- Goonhilly EXPAK fake host 3 -- Tanum EXPAK fake host 4 -- Clarksburg EXPAK fake host 5 -- Etam Message Generator/Sink #0 6 -- Etam Message Generator/Sink #1 7 -- Etam Message Generator/Sink #2 8 -- Etam Message Generator/Sink #3 9 -- Goonhilly Message Generator/Sink #0 10 -- Goonhilly Message Generator/Sink #1 11 -- Goonhilly Message Generator/Sink #2 12 -- Goonhilly Message Generator/Sink #3 13 -- Tanum Message Generator/Sink #0 14 -- Tanum Message Generator/Sink #1 15 -- Tanum Message Generator/Sink #2 16 -- Tanum Message Generator/Sink #3 17 -- Clarksburg Message Generator/Sink #0 18 -- Clarksburg Message Generator/Sink #1 19 -- Clarksburg Message Generator/Sink #2 20 -- Clarksburg Message Generator/Sink #3 21 -- Etam Internal Gateway 22 -- Goonhilly Internal Gateway 23 -- Tanum Internal Gateway 24 -- unused 25 -- unused 26 -- unused 27 -- unused 28 -- unused 29 -- unused 30 -- Clarksburg Internal Gateway 31 -- unused 32 -- unused 33 -- unused 34 -- unused 35 -- unused 36 -- unused 37 -- Universal Message Sink (equivalent name) 38 -- Tanum NDRE Gateway 39 -- Clarksburg COMSAT Gateway 40 -- Universal Satellite Echo (equivalent name) 41 -- Etam Monitor Fake Host 42 -- Goonhilly Monitor Fake Host 43 -- Tanum Monitor Fake Host 44 -- Clarksburg Monitor Fake Host 45 -- Etam Packet Core Fake Host 46 -- Goonhilly Packet Core Fake Host - 40 - Host/SATNET Protocol IEN 192 47 -- Tanum Packet Core Fake Host 48 -- Clarksburg Packet Core Fake Host 49 -- Etam TTY Fake Host 50 -- Goonhilly TTY Fake Host 51 -- Tanum TTY Fake Host 52 -- Clarksburg TTY Fake Host 53 -- Etam DDT Fake Host 54 -- Goonhilly DDT Fake Host 55 -- Tanum DDT Fake Host 56 -- Clarksburg DDT Fake Host 57 -- unused 58 -- unused 59 -- unused 60 -- Goonhilly UCL Gateway 61 -- Etam BBN Gateway 62 -- Etam Echo Fake Host 63 -- Goonhilly Echo Fake Host 64 -- Tanum Echo Fake Host 65 -- Clarksburg Echo Fake Host 66 -- unused 67 -- unused 68 -- unused 69 -- unused 70 -- unused 71 -- unused 72 -- Raisting External Gateway 73 -- unused 74 -- unused 75 -- unused 76 -- Raisting Internal Gateway 77 -- Raisting Echo Fake Host 78 -- Raisting Monitor Fake Host 79 -- Raisting EXPAK Fake Host 80 -- Raisting Packet Core Fake Host 81 -- Raisting DDT Fake Host 82 -- Raisting TTY Fake Host 83 -- Raisting Message Generator/Sink #0 84 -- Raisting Message Generator/Sink #1 85 -- Raisting Message Generator/Sink #2 86 -- Raisting Message Generator/Sink #3 87 -- unused 88 -- Fucino External Gateway 89 -- unused 90 -- unused 91 -- unused 92 -- Fucino Internal Gateway 93 -- Fucino Echo Fake Host - 41 - Host/SATNET Protocol IEN 192 94 -- Fucino Monitor Fake Host 95 -- Fucino EXPAK Fake Host 96 -- Fucino Packet Core Fake Host 97 -- Fucino DDT Fake Host 98 -- Fucino TTY Fake Host 99 -- Fucino Message Generator/Sink #0 100 -- Fucino Message Generator/Sink #1 101 -- Fucino Message Generator/Sink #2 102 -- Fucino Message Generator/Sink #3 103 -- unused - 42 - Host/SATNET Protocol IEN 192 +-------+ | | | OFF | | | TO = TIMEOUT +-------+ RR = RESTART REQUEST | RC = RESTART COMPLETE |INIT & SEND RR | V +-------+ --->| |--------------- / | | \ | | | \ | | INIT | | | | |<--- | \ | | \ | ----| | | | 10 SEC TO +-------+ | | ------- | | | SEND RR |RCVD RR | | | ----- | | |SEND RC | | V | | +-------+ | | -------------->| | | | / | | / | / --->| |---- | | / |WAITING| 100 SEC TO | | | | | -------- | | \ | | SEND RR | | ----| | | | 10 SEC TO +-------+ | | ------- | | | SEND RC | | | |RCVD RC | | | | \ V / \ +-------+ / ---------------| |<-------------- RCVD RR | ON | RCVD RC ------------ | | ----- INIT & SEND RC +-------+ SEND RC B.1 Figure 1. Restart State Diagram - 43 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| | CONTROL CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.2 Figure 2. General Message Format - 44 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H3 | PIGGYBACK WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H4 | TYPE OF SERVICE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H5 | DESTINATION HOST(S) ADDRESS | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H6 | SOURCE HOST ADDRESS | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D1 | | | | | DATA | | | DN | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.3 Figure 3. Block DATA Message - 45 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H4 | M | P | D | H | R | (unused) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.4 Figure 4. Type of Service Word 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | C | D0 | D1 | D2 | D3 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.5 Figure 5. Acceptance Status Word 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| DATA MESSAGE ID | (unused) | CODE = 2 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.6 Figure 6. ACCEPTED Message 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| DATA MESSAGE ID | C | CODE = 3 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.7 Figure 7. REFUSED Message - 46 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| (unused) | CODE = 4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.8 Figure 8. STATUS REQUEST Message MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| (unused) | CODE = 5 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H3 | SATNET GLOBAL TIME | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H4 | CURRENT DELAY FOR CLASS 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H5 | CURRENT DELAY FOR CLASS 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H6 | CURRENT DELAY FOR CLASS 2 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H7 | CURRENT DELAY FOR CLASS 3 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.9 Figure 9. STATUS Message - 47 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| (unused) | CODE = 6 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.10 Figure 10. HELLO Message 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| ERROR MESSAGE ID | ERROR CODE | CODE = 13 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.11 Figure 11. FORMAT ERROR Message 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| (unused) | HOST TYPE | CODE = 14 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.12 Figure 12. RESTART REQUEST Message 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| (unused) | HOST TYPE | CODE = 15 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.13 Figure 13. RESTART COMPLETE Message - 48 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H3 | PIGGYBACK WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H4 | 1 or 3| STREAM ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H5 | DESTINATION HOST(S) ADDRESS | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H6 | SOURCE HOST ADDRESS | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | (INTERNET HEADER IF TYPE=1) | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D1 | | | | | STREAM DATA | | | DN | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.14 Figure 14. Stream Data Format - 49 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H3 | PIGGYBACK WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H4 |0 or 2 | PR | 0 | 0 | 0 | (unused) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H5 | SATNET SERVICE HOST (CURRENT ADDRESS = 0) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H6 | SOURCE HOST ADDRESS | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | (INTERNET HEADER IF TYPE=0) | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D1 | REQUEST CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D2 | REQUEST ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D3 | | | | | REQUEST INFORMATION | | | DN | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.15 Figure 15. Request Message Format - 50 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H3 | PIGGYBACK WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H4 |0 or 2 | PR | 0 | 0 | 0 | (unused) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H5 | REQUESTING HOST | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H6 | SATNET SERVICE HOST (CURRENT ADDRESS = 0) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | (INTERNET HEADER IF TYPE=0) | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D1 | 0 | REPLY CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D2 | REQUEST ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D3 | | | | | REPLY INFORMATION | | | D6 | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.16 Figure 16. Reply Message Format - 51 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H1 |H/S| MESSAGE ID | BLOCK LENGTH | CODE = 1 or 7 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H2 | ACCEPTANCE STATUS WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H3 | PIGGYBACK WORD | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H4 |0 or 2 | PS | 0 | 0 | 0 | (unused) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H5 | MEMBER HOST | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ H6 | SATNET SERVICE HOST (CURRENT ADDRESS = 0) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | (INTERNET HEADER IF TYPE=0) | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D1 | 1 | NOTIFICATION CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D2 | STREAM ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D3 | | | | | NOTIFICATION INFORMATION | | | D6 | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.17 Figure 17. Notification Message Format - 52 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D1 | REQUEST CODE = 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D2 | REQUEST ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D3 | STREAM ID = 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D4 | | | | D5 | KEY | | | D6 | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D7 | (unused) | PS | MAXIMUM DATA LENGTH (L) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D8 | QUEUE LENGTH | (unused) | STREAM INTERVAL (HIGH BITS) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D9 | STREAM INTERVAL (LOW BITS) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.18 Figure 18. Create Request Words - 53 - Host/SATNET Protocol IEN 192 MSB LSB 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | = 2: DELETE | D1 | REQUEST CODE = 3: JOIN | | = 4: LEAVE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D2 | REQUEST ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D3 | STREAM ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ D4 | | | | D5 | KEY | | | D6 | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ B.19 Figure 19. Delete, Join, Leave Request Words - 54 -