RFC 907
Host Access Protocol specification
RFC 907: Host Access Protocol Specification ✨
Hiii bestie 🎀 okay so this is RFC 907, the Host Access Protocol Specification, and it's dated July 1984 🦋 It was prepared for the Defense Advanced Research Projects Agency (DARPA), 1400 Wilson Boulevard, Arlington, Virginia 22209, and written by Bolt Beranek and Newman Laboratories (BBN), 10 Moulton Street, Cambridge, Massachusetts 02238. 💜
The title block doesn't list authors, category, obsoletes or updates in a column, so I'm sharing the vibe from the document itself: this is a specification for HAP, the Host Access Protocol, and the Preface says it's an experimental protocol 🧪 that will keep changing. It's a minor revision of, and supersedes, the specification in Chapter 4 of BBN Report No. 4469, the "PSAT Technical Report" 📋 So it's basically the newer, glow-up version of that spec. 💅
Preface (Status of this Memo) 🌸
Okay so the Preface is where the document tells you what it's about and where it's at. 🫶
HAP was first designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network 🛰️ but the plan is for it to grow into a standard interface between hosts and packet-switched satellite networks like SATNET and TACNET (aka MATNET), plus the Wideband Network. 🌈
The details in this spec still match the Wideband Satellite Network most closely. ✨ Compared to the "PSAT Technical Report," this version adds three new control message types (Loopback Request, Link Going Down, and NOP), a "Reason" field in Restart Request control messages, new Unnumbered Response codes, and new values for the setup codes used to manage streams and groups. 🍓
HAP is experimental! It will keep getting revised as new capabilities show up and as different satellite networks get supported. Anyone implementing it should coordinate with satellite network development and operations personnel. 💀
Table of Contents 📑
Here's how the document is laid out, so you can find your way around:
1 Introduction.......................................... 1
2 Overview.............................................. 3
3 Datagram Messages..................................... 8
4 Stream Messages...................................... 14
5 Flow Control Messages................................ 17
6 Setup Level Messages................................. 24
6.1 Stream Setup Messages.............................. 32
6.2 Group Setup Messages............................... 44
7 Link Monitoring...................................... 58
8 Initialization....................................... 62
9 Loopback Control..................................... 68
10 Other Control Messages.............................. 72The figures list is long, but it includes DATAGRAM MESSAGE, STREAM MESSAGE, ACCEPTANCE/REFUSAL WORD, SETUP MESSAGE HEADER, STREAM EXAMPLE, GROUP EXAMPLE, HAP LINK RESTART STATE DIAGRAM, LOOPBACK REQUEST, LINK GOING DOWN, and NO OPERATION (NOP) 🎀
1. Introduction 🦋
Okay so HAP is the thing that handles network-access level communication between a computer (called a host) and a packet-switched satellite network 🛰️ The network delivers messages between hosts that are far apart. A source host submits a message, and the network passes it through, untouched, to the destination host. 💖
To use this, a host hooks up over an access link to a dedicated packet-switching computer called a Satellite Interface Message Processor (Satellite IMP, or SIMP) 🖥️ HAP defines the control messages and the host-to-host data messages that can go over that access link between a host and a SIMP. It also sets the formats for those messages and explains when to send each type and what it means when one shows up. 🔥
"Interface Message Processor" comes from the ARPANET, where it means the packet-switching nodes. SIMPs and ARPANET IMPs are different because SIMPs connect to a shared multiaccess/broadcast satellite channel, while ARPANET IMPs are linked by dedicated point-to-point terrestrial lines. ✨ That big difference means satellite networks deliver messages and coordinate internally in different ways, and they also offer different kinds of service to hosts. HAP includes those service options. 🌈
Here's the SIMP family tree 🌳 The original SIMP ran on a Honeywell 316 minicomputer in the Atlantic Packet Satellite Network (SATNET). The 316 SIMPs were then replaced in SATNET by SIMPs built on BBN C/30 Communications Processor hardware, and C/30 SIMPs are also used in the Mobile Access Terminal Network (MATNET). SATNET and MATNET SIMPs speak a network-access protocol called Host/SATNET Protocol, which is the precursor to HAP and is documented in Internet Experiment Note (IEN) No. 192. 📋
The Wideband Satellite Network has also evolved its SIMP hardware and software, like SATNET did. Its original SIMP is the Pluribus Satellite IMP (PSAT), built on the BBN Pluribus Multiprocessor. Its successor, the BSAT, is based on the BBN Butterfly Multiprocessor. Both PSAT and BSAT talk to their connected hosts over HAP. 💜
Section 2 gives an overview of HAP. The formats and message exchange procedures are in Sections 3 through 10. More explanation of many topics can be found in BBN Report No. 4469, the "PSAT Technical Report." 🫶
The protocol that gives reliable enough message exchange over the host-SIMP link is assumed to be transparent to the network-access protocol defined here. Examples of link-level protocols include ARPANET 1822 local and distant host, ARPANET VDH protocol, and HDLC. 🌸
2. Overview 🌷
HAP is a full duplex, nonreliable protocol with an optional flow control mechanism 🦋 HAP messages flow both ways at once, between the SIMP and the host. 💅
"Nonreliable" means the protocol doesn't guarantee error-free, sequenced delivery. If the access link needs that (for example, when the SIMP and host aren't in the same place and talk over a communication circuit), the link-level protocol below HAP has to provide it. 🔥 The flow control mechanism works separately in each direction, but turning it on or off applies to both sides of the interface. ✨
HAP supports host-to-host communication in two modes, matching its two data message types: datagram messages and stream messages. Each can be up to approximately 16K bits long. 🌈 Datagram messages are the basic transmission service in the satellite network. A datagram sent by a host has a nominal two satellite hop end-to-end delay. (About 0.6 sec excluding access link delay, for datagrams between hosts on different SIMPs. Between hosts on the same SIMP the delay is much smaller, as long as the destination isn't a group address. See Section 3 and 6.2.) 💖 A datagram control header, which the host passes to the SIMP along with the message text, decides how the satellite network handles the message, and it doesn't depend on any earlier exchanges. 🍓
Stream messages give a one satellite hop delay (about 0.3 sec) for volatile traffic like speech, which can't handle datagram delay. 🎀 Hosts can also use streams for high duty cycle applications that need guaranteed channel bandwidth. 👑 A host stream is set up by a setup message exchange between host and network before any data flows. 🦋 You can change an established stream's characteristics with later setup messages while it's in use, but streams have fixed allocation properties (unlike datagrams), which puts pretty strict requirements on the traffic source. 😭
Quick note: this is only part 1 of 10, so more is coming. Keep your eyes peeled! 👀💜
Okay so stream traffic arrivals gotta line up with the stream allocation, both in interarrival time and in message size, if you want reasonable efficiency 💅 Datagrams and streams get the full breakdown in Sections 3 and 4 of this doc, so stay tuned 🦋
Both datagram and stream transmission in the satellite network use logical addressing 🌸 Every host gets a permanent 16-bit logical address that doesn't care which physical port on the SIMP it's plugged into. These 16-bit logical addresses show up in every Host-to-SIMP and SIMP-to-Host data message ✨
Hosts can also be members of groups 👑 Group addressing exists mainly to support the multi-destination delivery needed for conferencing apps, which is so iconic. Just like streams, group addresses get created and deleted on the fly using setup messages exchanged between a host and the network. Membership can be any arbitrary subset of the permanent network hosts, and a message addressed to a group address gets delivered to every host in that group 🫶
Now the error stuff, and yes it matters a lot 🥹 HAP does not guarantee error-free delivery, but error control is still a big deal in the protocol design. HAP error control covers both local transfers between a host and its local SIMP and transfers from SIMP-to-SIMP over the satellite channel. The SIMP gives users a choice of network error protection options, based on the network's ability to selectively send messages over the satellite channel at different coding rates. These forward error correction (FEC) options are called reliability levels 🎀 The host gets three of them: low, medium, and high.
On top of forward error correction, the satellite network uses a bunch of checksum mechanisms to add error detection 🔥 When a host sends a message, it gets a chance to say whether the message should be delivered to its destination or thrown away if the network detects a data error. Every message the network hands to a host comes with a flag saying whether an error was detected in that particular message. Basically the host gets to decide, per message, whether it wants to accept or discard anything containing data errors 💅
For a host and SIMP that are close together, error rates from external noise or hardware failures on the access circuit should be way smaller than the best satellite channel error rate, so it's giving "not worth it" for error detection and retransmission on the access circuit 🙈 There is still a 16-bit header checksum, though, to make sure SIMPs don't act on incorrect control information. For longer distances or noisy connections, retransmissions over the access circuit might be needed to optimize performance for both low and high reliability traffic 🌈 Link-level error control procedures, such as HDLC, are expected to be used for that job.
Sometimes a datagram or stream message being handed to the network gets turned away for a bunch of reasons: priority too low, destination dead, lack of buffers in the source SIMP, etc 💀 Hosts deal with the same thing when handling messages from the SIMP. So the receiver can tell the sender what happened to its message locally, there's an acceptance/refusal (A/R) mechanism ✨ It's basically the outside view of the SIMP's (or host's) internal flow and congestion control algorithm. If A/Rs are enabled, every message gets an explicit or implicit acceptance or refusal sent back to the host by the SIMP (and the other way around too) 🦋 That lets the host (or SIMP) retry refused messages whenever it wants, and if the refusal reason is included, it can also help optimize what gets sent next. The A/R mechanism can be turned off for a "pure discard" interface 🫠
Every message a host submits to the SIMP is marked with one of four priority classes, running from priority 3 (highest) down to priority 0 (lowest) 👑 The SIMP uses this class to decide who wins when scarce network resources are contested, like channel time. So if the network can't deliver everything offered, high priority messages get delivered before low priority ones 🔥 For datagrams, the priority level decides the order of satellite channel reservation requests at the source SIMP and of message delivery at the destination SIMP. For streams, priority is tied to whether one stream can preempt another lower priority stream at setup time 💜
A/R handles individual message transfers, but it doesn't really help with regulating whole priority flows 🌸 That job goes to advisory status info called GOPRI, which gets passed across the Host-SIMP interface and says which priorities are currently being accepted. As long as this info gets passed frequently enough, relative to changes in priority status, the sender can skip originating messages that are sure to get refused 🧚
HAP defines two kinds of messages: data messages (datagram and stream messages) and control messages 🎀 Data messages carry information between network hosts. Control messages go between a host and the network to manage the local access link. HAP can also be split into two protocol layers, the message layer and the setup layer 💖 The message layer handles transmission of individual datagram and stream messages. The setup layer handles establishing, modifying, and deleting streams and groups. Setup layer exchanges are actually implemented as datagrams sent between the user host and an internal SIMP "service host" 🫶
Every HAP message is made of an integral number of 16-bit words ✨ The first few words always hold control information, and they're called the message header. The first word of the header tells you what type of message is coming. The second word is a checksum covering all the header information 😭 Any message whose received header checksum doesn't match the checksum computed on the received header info must be discarded 💀 The rest of the header's format depends on the specific message type.
The individual message types and how they're used get detailed in the sections that follow, using one shared format description 🦋 Words in a message are numbered starting at zero, so zero is the first word of a message header. Bits inside a word are numbered from zero (least significant) up to fifteen (most significant) 🌈 The notation for pointing at a field location looks like this:
<WORD#>{-<WORD#>} [ <BIT#>{-<BIT#>} ] <description>Anything in {} is optional and is used to give the (inclusive) upper limit of a range 🍓 Use these field identifiers when you need exact field size specs. Fields shared by several message types get defined in the first section that uses them, and after that, descriptions usually just use the field name 💅
Link-level protocols under HAP can differ in the order they send the bits in a HAP message 🤓 For HDLC and ARPANET VDH, each word gets sent starting with the least significant bit (bit 0) and ending with the most significant bit (bit 15), and the words go from word 0 up to word N. For ARPANET 1822 local and distant host interfaces, the bit order inside each word is flipped, so it goes from bit 15 down to bit 0 🔥
3. Datagram Messages ✨
Datagram messages are one of the two types of message-level data messages used for host-to-host communication 💜 Each datagram can hold up to 16,384 bits of user data. Datagrams sent from a host to a host on a remote SIMP have a nominal end-to-end network delay of two satellite hops (about 0.6 sec), not counting delay on the access links 😭 That delay comes from the per-message reservation scheduling procedure for datagrams, which only allocates channel time for the actual duration of the transfer. Datagram transfers between permanent hosts on the same SIMP don't need satellite channel scheduling before data transmission, so the network delay there is way smaller and is determined strictly by SIMP processing time 🧚 Datagrams sent to group addresses are treated as if they were going to remote hosts, so they always go over the satellite channel. Datagram messages are expected to carry most computer-to-computer and terminal-to-computer traffic, which is bursty by nature 🌸
The format of datagram messages, and what each header control field does, is described in Figure 1 🎀
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| XXXX | F| MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 0|IL| D| E| TTL | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1 . DATAGRAM MESSAGE0[15]Message Class. This bit tells you whether the message is a data message or a control message 🩷
0 = Data Message
1 = Control Message4 Stream Messages ✨
Okay so stream messages are the second type of message-level data message 💅 As we covered in Section 2, streams exist mainly to give volatile traffic like speech a one satellite hop delay 🎀 Hosts can also use streams for high duty cycle apps that need guaranteed channel bandwidth 🔥
Streams must be created before stream messages can flow from host to host 🧚 The protocol for doing that is in Section 6.1. Once a stream is up, it gets tied to a recurring channel allocation in the satellite network 📡 That fixed allocation is pretty strict, so the host using the stream has to be on its game if it wants efficient channel utilization 😭 Stream messages must match the stream allocation in terms of both message size and message interarrival time. Literally a vibe check.
Within the bounds of its stream allocation, a host gets a lot of flexibility in how it uses the stream 🦋 The priority, reliability, and reliability length of each stream message are fixed at stream creation time, but the destination logical address can change from one stream message to the next 💜 So a host can multiplex a bunch of logical flows onto one host stream, which is giving main character energy ✨ The format of stream messages is shown in Figure 2 🌸
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| XXXX | MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 1|IL| D| E| TTL | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 2 . STREAM MESSAGE
Here's the breakdown for stream messages, bestie 🫶
0[15] is the Message Class, and it's set to 0 (Data Message) 🍓
0[14] is the Loopback Bit, same as in the datagram format 🔁
0[12-13] is the Go-Priority, also same as the datagram format 💅
0[8-11] is Reserved 🤫
0[0-7] is the Message Number. It does the same job as the message number field in a datagram message 🙌 The cool part is that one single message number sequence is shared by both datagram and stream messages, so see Section 5 for how that works 🔢
1[0-15] is the Header Checksum, and it covers Words 0-5 🧮
2[0-15] is the Piggybacked A/R 🔄
3[15] is the Data Message Type, and it's set to 1 (Stream) 🌊
3[14] is the Internet/Local Flag, same as before 🌐
3[13] is the Discard Flag, same as before 🗑️
3[12] is the Data Error Flag, same as before 🚩
3[10-11] is the Time-to-live Designator, and this one has its own little value list that's kinda different from the datagram one 👀
0 = Reserved
1 = 1 second
2 = Reserved
3 = Reserved3[0-9] is the Host Stream ID, and it's 10 bits of pure main character energy 🧚♀️ The service host uses it to identify the host stream the SIMP should send the message over 🛰️ Host stream IDs get set up when a stream is created, through host exchanges with their network service host (see Section 6.1) 🤝
4[0-15] is the Destination Host Address 📍
5[0-15] is the Source Host Address 📍
6-N is the Data field, and it holds up to 16,000 bits of user data, in multiples of 16 bits 💖
5 Flow Control Messages ✨
Okay so the A/R mechanism is basically the host and the SIMP politely telling each other "yep, got it" or "nope, not taking that" 💅 It runs in each direction on the host access link, and the host turns it on by setting a bit in the Restart Complete control message (see Section 8) 🎀. Every datagram and stream message carries an 8-bit message number for flow control, and both sides bump it modulo 256 with each message they send 🔢. Up to 127 messages can be outstanding in each direction at any time, which is a lot of messages in flight, bestie 🚀. If the receiver can't take a message, it sends a refusal with that message's number and the reason why 🙅♀️. The refusal can ride along on a data message going the other way, or come as its own control message if there's no reverse traffic 🦋
Acceptances work the same way, piggybacked on data or sent in a separate control message ✨ An acceptance just means "this message wasn't refused" 💖 But here's the tea: an acceptance from the SIMP does not guarantee delivery, and it doesn't even promise the network won't intentionally drop the message later on 😭 They're mainly there to help the host manage its buffers 🧚
To cut down on A/R chatter, one A/R indication can cover several earlier, still-unacknowledged messages 🌸 An explicit acceptance of message number N implicitly accepts outstanding messages N-1, N-2, and so on, following the acceptance definition above 🫶 (Quick reminder: explicit acceptance of N does not mean every unacknowledged message has been received 🙈) The same logic works for refusals, so a receiver can reject a whole group together if they're all being refused for the same reason 💜 And for extra efficiency, HAP lets a block of A/R indications get bundled into one A/R control message 🍓 For example, that could be used to reject a group of messages where each one has a different refusal code 👑
Sometimes the overhead of processing A/R messages just isn't worth it 💀 In that case, you can disable the A/R mechanism and run the HAP interface in a purely discard mode 🌈 You can turn this on per link, as mentioned earlier (see Sections 2 and 8) ✨ Also, messages with sequence number zero are treated as messages where A/R is selectively disabled 🦋 And even in discard mode, HAP still has an "Unnumbered Response" control message for critical feedback 🎀
The format in Figure 3 is used both for piggybacking A/R indications on data messages (word 2) and for A/R info in separate control messages 💅 When it's a separate control message, the Figure 4 format applies ✨ Flow control info, and anything else that can't be sent as an A/R indication, goes in an Unnumbered Response control message, which is shown in Figure 5 🫶
Figure 3 . ACCEPTANCE/REFUSAL WORD
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AR| REFUSAL CODE | A/R MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+[15]Acceptance/Refusal Type. This field tells you whether the A/R info is an acceptance or a refusal 💖
0 = Acceptance
1 = Refusal[8-14]Refusal Code. When the Acceptance/Refusal Type = 1, this field gives the Refusal Code 🙅♀️
0 = Priority not being accepted
1 = Source SIMP congestion
2 = Destination SIMP congestion
3 = Destination host dead
4 = Destination SIMP dead
5 = Illegal destination host address
6 = Destination host access not allowed
7 = Illegal source host address
8 = Message lost in access link
9 = Nonexistent stream ID
10 = Illegal source host for stream ID
11 = Message length too long
12 = Stream message too early
13 = Illegal control message type
14 = Illegal refusal code in A/R
15 = Illegal reliability value
16 = Destination host congestion[0-7]A/R Message Number. This field holds the number of the message this acceptance/refusal refers to 🔢 It also covers all outstanding messages with earlier numbers 🫶 Note that this field can never be zero, since a message number of zero means the A/R mechanism is disabled 🙈
Figure 4 . ACCEPTANCE/REFUSAL MESSAGE
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXX | LENGTH | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. . ... .
. . ... .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+0[15]Message Class = 1 (Control Message). 🎀0[14]Loopback Bit. 🔁0[12-13]Go-Priority. 🚦0[8-11]Reserved. 🤫0[4-7]Message Length. This field contains the total length of this message in words (N+1) 📏0[0-3]Control Message Type = 1 (Acceptance/Refusal). 💅1[0-15]Header Checksum. The checksum covers words 0-N 🧮2[0-15]Acceptance/Refusal Word. ✨3-NAdditional Acceptance/Refusal Words (optional). 🌈
Figure 5 . UNNUMBERED RESPONSE
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXX | RES-CODE | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+0[15]Message Class = 1 (Control Message). 🎀0[14]Loopback Bit. 🔁0[12-13]Go-Priority. 🚦0[8-11]Reserved. 🤫0[4-7]Response Code. Here are the options 👀
3 = Destination unreachable
5 = Illegal destination host address
7 = Illegal source host address
9 = Nonexistent stream ID
10 = Illegal stream ID
13 = Protocol violation
15 = Can't implement loop0[0-3]Control Message Type = 5 (Unnumbered Response). 💖1[0-15]Header Checksum. Covers words 0-3 🧮2[0-15]Response Information. If Response Code is:
3, Destination Host Address
5, Destination Host Address
7, Source Host Address
9, Stream ID (right justified)
10, Stream ID (right justified)
13, Word 0 of offending message
15, Word 0 of Loopback Request message3[0-15]Response Information. If Response Code is:
3,5,7, or 9. Undefined
10, Source Host Address
13, Word 3 of offending message, or zero if
no word 3
15, Word 2 of Loopback Request message6. Setup Level Messages 🧚♀️✨
Okay, setup level protocol is the part that handles creating, changing, and deleting groups and streams in the packet satellite network 🛰️ When a host wants to do any of these generic operations, it talks to the network service host, which has logical address zero 💜 The service host makes the requested action happen and acts as the middle person between the user and the rest of the network 🫶 While it's doing that, it updates the various network databases so they reflect the current state of the group or stream being referenced 📚
The host and the service host chat using special-purpose datagrams called setup messages 💌 Every interaction the host starts is a 3-way exchange 🤝 First, the user host sends a Request to the service host, then the service host sends back a Reply to the user host, and finally the user host sends a Reply Acknowledgment to the service host 🔥 This is how requests and replies get reliably transmitted 😭 So that a host can have more than one setup request outstanding at a time, each request gets its own unique Request ID 🦋 The matching Reply and the Reply Acknowledgment that follows are identified by the Request ID they carry 💅
Hosts should generally expect the Reply to take a minimum of about two satellite round-trip times, measured from when they send a setup Request to the SIMP until they receive the matching Reply ⏳ (Plot twist: the Join Group Request and the Leave Group Request only need local communication between a host and its SIMP 🙌 So the response time for those is based only on SIMP processing time, and it should be a lot shorter than two round-trip times ⚡) This delay sets the maximum rate at which the SIMP can process changes 🚦 The user should get a reply to a setup request that needs global communication within 2 seconds ⏰, and a reply to a setup request that needs local communication within 1 second 🍓 The host should answer a SIMP Reply with a Reply Acknowledgment within 1 second 💜
6. Setup Messages (continued) 🎀
Okay so SIMP-initiated setups are a thing too 💌 The SIMP uses them to tell a host when the status of an associated group or stream changes ✨ Each notification is a 2-way exchange: (1) the service host sends a Notification to the user host, and (2) the user host sends back a Notification Acknowledgment to the service host 🫶 So that more than one Notification can be outstanding at a time, every single one gets its own unique Notification ID 🔥 And the Notification Acknowledgment that goes back to the service host must contain the Notification ID, no exceptions 💅
The general format of every setup message is:
<DATAGRAM MESSAGE HEADER>
<OPTIONAL INTERNET HEADER>
<SETUP MESSAGE HEADER>
<SETUP MESSAGE BODY>The service host takes setup requests in either Internet or non-Internet format 🌈 Replies are always in the same form as the request, so Internet requests get Internet replies and non-Internet requests get non-Internet replies. It's giving consistency 💖
The combined datagram message header and setup message header is shown in Figure 6 ✨ The body depends on which setup message type you're dealing with. Stream request and reply messages are in Section 6.1, and group request and reply messages are in Section 6.2 🦋 To keep those two sections simple, the setup messages are treated as if they're exchanged between a local host and SIMP, even though Internet group and stream setups are supported (see Figure 6) 🧚 Notifications are just one extra word past the basic setup header, and they're shown in Figure 7 💜 The SIMP doesn't keep the optional Internet header info that can come along with setup requests, so Internet notifications are not supported 🙈 Acknowledgment messages for request/reply and notification setups are in Figure 8 🌸
[page 25]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | <OPTIONAL INTERNET HEADER> |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+1 | SETUP TYPE | SETUP CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+2 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+3 | SETUP ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 6 . SETUP MESSAGE HEADERHere's the breakdown of Figure 6 🔍
0-5 Datagram Message Header. Every setup message kicks off with the six word datagram message header (see Section 3) 🎀
6-N Internet Header (Optional). When these fields show up, they follow the DoD Standard Internet Protocol (IP). The Internet header is a minimum of 10 words, but it can be longer if optional IP facilities are being used 🌈 (Internet notification messages are not supported 🙈)
N+1[8-15] Setup Type. This one tells you what kind of setup message you've got 🔥
0 = Acknowledgment
1 = Request
2 = Reply
3 = NotificationN+1[0-7] Setup Code. For requests, this field tells you the Request Type 💅
1 = Create group address
2 = Delete group address
3 = Join group
4 = Leave group
5 = Create stream
6 = Delete stream
7 = Change stream parameters
8 = ReservedFor Replies, this field holds the Reply Code. Some Reply Codes can be sent back for any setup request, and others are specific to a certain request 👑
0 = Group or stream created
1 = Group or stream deleted
2 = Group joined
3 = Group left
4 = Stream changed
5 = Reserved
6 = Bad request type
7 = Reserved
8 = Network trouble
9 = Bad key
10 = Group address/stream ID nonexistent
11 = Not member of group/creator of stream
12 = Stream priority not being accepted
13 = Reserved
14 = Reserved
15 = Illegal interval
16 = Reserved
17 = Insufficient network resources
18 = Requested bandwidth too large
19 = Reserved
20 = Reserved
21 = Maximum messages per slot not consistent with
slot size
22 = Reply lost in network
23 = Illegal reliability value[page 26]
For Notifications, this field holds the Notification Type 🔔
0 = Stream suspended
1 = Stream resumed
2 = Stream deleted
3 = Group deleted by host
4 = Group deleted by SIMP
5 = All streams deleted
6 = All groups deletedFor Acknowledgments, this field holds the Acknowledgment Type 🫶
0 = Reply acknowledgment
1 = Notification acknowledgmentN+2[0-15] Setup Checksum. The checksum covers the three setup message header words and the setup message body data words. Setups that arrive with bad checksums must be discarded, so don't even try 🙅♀️
N+3[0-15] Setup ID. The host assigns this to uniquely identify outstanding requests (that's the Request ID). The service host uses it to uniquely identify outstanding notifications (that's the Notification ID) ✨
[page 28]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 3 | NOTIFICATION TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | NOTIFICATION ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | NOTIFICATION INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 7 . NOTIFICATION MESSAGENow the Figure 7 breakdown 🦋
0-5 Datagram Message Header (see Section 3).
6[8-15] Setup Type = 3 (Notification).
6[0-7] Notification Type.
0 = Stream suspended
1 = Stream resumed
2 = Stream deleted
3 = Group deleted by host
4 = Group deleted by SIMP
5 = All streams deleted
6 = All groups deleted7[0-15] Setup Checksum. This covers words 6-9.
8[0-15] Notification ID.
9[0-15] Notification Information. This field holds the 16-bit group address for a group notification (types 3 and 4), and it holds the 10-bit host stream ID (right justified) for a stream notification (types 0-2). It's zero for Notification Types 5 and 6, which apply to ALL streams and groups, respectively 🧚
[page 29]
[page 30]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 0 | ACK TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | SETUP ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 8 . SETUP ACKNOWLEDGMENTAnd the Figure 8 breakdown 🌷
0-5 Datagram Message Header.
6[8-15] Setup Type = 0 (Acknowledgment).
6[0-7] Acknowledgment Type.
0 = Reply acknowledgment
1 = Notification acknowledgment7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Setup ID. This is either a Request ID or a Notification ID.
[page 31]
6.1. Stream Setup Messages ✨
Okay so hosts use streams for high duty cycle applications, and for apps that need a one satellite hop network transmission delay 🛰️ Host streams must be set up before any stream data messages can flow 🚦 The stream setup messages HAP defines are Create Stream Request, Create Stream Reply, Delete Stream Request, Delete Stream Reply, Change Stream Parameters Request, and Change Stream Parameters Reply 💖 Figure 9 shows how they all fit together in a scenario between a host and its local SIMP: the host sets up a stream, sends some data, changes the stream characteristics, sends more data, and then finally closes the stream down 🎬
It's worth noting that the setup exchanges in Figure 9 happen entirely between the host that started the stream and its local SIMP 🫣 Other SIMPs and hosts basically have no idea the stream exists. Stream messages that reach a destination host get processed exactly like datagram messages 📬 (All SIMPs must, of course, know about the channel allocation tied to a host stream so they can do satellite channel scheduling 🛰️) Also implicit in this scenario, but not illustrated, are the optional A/R indications that go with each of the stream setup messages 🙌
[page 32]
Host SIMP Create Stream Request ------>
Create Stream Reply <------
Reply Acknowledgment ------>
Stream Message ------>
.
.
Stream Message ------>
Change Stream Parameters Request ------>
Change Stream Parameters Reply <------
Reply Acknowledgment ------>
Stream Message ------>
.
.
Stream Message ------>
Delete Stream Request ------>
Delete Stream Reply <------
Reply Acknowledgment ------>Figure 9 . STREAM EXAMPLE 🎀
Okay bestie, so every host stream has six characteristic properties 💅 that get locked in at stream setup time. These properties apply to every single message sent in the stream: (1) slot size, (2) interval, (3) reliability, (4) reliability length, (5) priority, and (6) maximum messages per slot. 🦋
To set up a stream, the host sends the Create Stream Request message shown in Figure 10 to the SIMP. Once the satellite network has processed that request, the SIMP replies to the host with a Create Stream Reply message formatted like Figure 11. If the reply code in that Create Stream Reply is zero, which means the stream was created successfully ✨, the host MAY proceed to transmit stream data messages, but only after it sends a Reply Acknowledgment.
Now, during the lifetime of a stream, the host that created it MAY decide that some of those six properties SHOULD be modified. 🌈 Everything except the stream interval can be changed with the Change Stream Parameters Request message, which is shown in Figure 12. After the network processes that request, the SIMP sends back a Change Stream Parameters Reply in the format of Figure 13. Here's the tea 🍓: if the host is asking for a reduced channel allocation, it SHOULD decrease its sending rate right away and not wait for the Change Stream Parameters Reply. But if it's asking for an increased allocation, it SHOULD NOT start sending with the new parameters until it has received a Reply Code of 4, which tells it the change has taken effect. Be patient, bestie 🫶
Finally, when the host that created the stream decides it's no longer needed and its satellite channel allocation can be freed up, it sends its local SIMP a Delete Stream Request formatted as shown in Figure 14. After the network processes that, the SIMP replies with a Delete Stream Reply in the format of Figure 15. Stream closed, era over 👑
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | MAX MES | INT | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | SLOT SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 10 . CREATE STREAM REQUEST 🌸
0-5Datagram Message Header.6[8-15]Setup Type =1(Request).6[0-7]Request Type =5(Create Stream).7[0-15]Setup Checksum. Covers words 6-10.8[0-15]Request ID.9[12-15]Maximum Messages Per Slot. This field specifies the maximum number of stream messages that will ever be delivered to the SIMP by the host for transmission in one stream slot.9[10-11]Interval. This field specifies the interval, in number of 21.2 ms frames, between stream slots.
0 = 1 frame
1 = 2 frames
2 = 4 frames
3 = 8 framesAs an example, an interval of 4 frames corresponds to an allocation of Slot Size words every 85 ms. 🧚
9[8-9]Priority. This field specifies the priority at which all messages in the host stream SHOULD be handled. 👑
0 = Low priority
1 = Medium Low Priority
2 = Medium High Priority
3 = High Priority9[6-7]Reliability. This field specifies the basic bit-error rate requirement for the data portion of all messages in the host stream.
0 = Low Reliability
1 = Medium Reliability
2 = High Reliability
3 = Reserved9[0-5]Reliability Length. This field specifies how many words beyond the stream message header SHOULD be transmitted at maximum reliability for all messages in the host stream. 💜10[0-15]Slot Size. This field specifies the slot size in 16-bit words of stream message text. Stream message header words are excluded from this count. The host can partition this allocation on a slot-by-slot basis among a variable number of messages, as long as the maximum number of messages per slot does not exceed MAX MES. 🍓
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 11 . CREATE STREAM REPLY 🦋
0-5Datagram Message Header.6[8-15]Setup Type =2(Reply).6[0-7]Reply Code.
0 = Stream created
8 = Network trouble
12 = Stream priority not being accepted
17 = Insufficient network resources
18 = Requested bandwidth too large
21 = Maximum messages per slot not consistent
with slot size
22 = Reply lost in network
23 = Illegal reliability value7[0-15]Setup Checksum. Covers words 6-9.8[0-15]Request ID.9[10-15]Reserved.9[0-9]Host Stream ID. This field contains a host stream ID assigned by the network. It MUST be included in all stream data messages sent by the host to allow the SIMP to associate the message with stored stream characteristics and the reserved satellite channel time. 🔥
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | MAX MES | INT | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | SLOT SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 12 . CHANGE STREAM PARAMETERS REQUEST ✨
0-5Datagram Message Header.6[8-15]Setup Type =1(Request).6[0-7]Request Type =7(Change Stream Parameters).7[0-15]Setup Checksum. Covers words 6-11.8[0-15]Request ID.9[10-15]Reserved.9[0-9]Host Stream ID.10[12-15]New Maximum Messages Per Slot.10[10-11]Interval. This field MUST specify the same interval as was specified in the Create Stream Request message for this stream. 🙈10[8-9]New Priority.10[6-7]New Reliability.10[0-5]New Reliability Length.11[0-15]New Slot Size.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 13 . CHANGE STREAM PARAMETERS REPLY 🌈
0-5Datagram Message Header.6[8-15]Setup Type =2(Reply).6[0-7]Reply Code.
4 = Stream changed
8 = Network trouble
10 = Stream ID nonexistent
11 = Not creator of stream
12 = Stream priority not being accepted
15 = Illegal interval
17 = Insufficient network resources
18 = Requested bandwidth too large
21 = Maximum messages per slot not consistent with
slot size
22 = Reply lost in network
23 = Illegal reliability value7[0-15]Setup Checksum. Covers words 6-8.8[0-15]Request ID.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+🎀 Figure 14 . DELETE STREAM REQUEST
Okay so here's how the Delete Stream Request is laid out, word by word 💅
0-5Datagram Message Header.6[8-15]Setup Type = 1 (Request). ✨6[0-7]Request Type = 6 (Delete Stream). 🦋7[0-15]Setup Checksum. Covers words 6-9. 🔒8[0-15]Request ID.9[10-15]Reserved.9[0-9]Host Stream ID.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+🎀 Figure 15 . DELETE STREAM REPLY
And this is the Delete Stream Reply 🌸
0-5Datagram Message Header.6[8-15]Setup Type = 2 (Reply). 💖6[0-7]Reply Code. The codes are:
1 = Stream deleted
8 = Network trouble
10 = Stream ID nonexistent
11 = Not creator of stream
17 = Insufficient network resources
22 = Reply lost in network7[0-15]Setup Checksum. Covers words 6-8.8[0-15]Request ID.
6.2. Group Setup Messages ✨
Okay bestie, this is where it gets spicy 🌈 Group addressing lets hosts use the broadcast power of the satellite network, and it's mainly there for multi-destination delivery, which conferencing apps are obsessed with 🫶 Group addresses get created and deleted on the fly through setup messages that hosts swap with the network. A group can have any arbitrary subset of the permanent network hosts as members 💜 And here's the iconic part: any datagram message or stream message sent to a group always goes over the satellite channel and gets delivered to every host in that group. No cap 🔥
The group setup messages are: Create Group Request, Create Group Reply, Delete Group Request, Delete Group Reply, Join Group Request, Join Group Reply, Leave Group Request, and Leave Group Reply. 🦋
Figure 16 shows how these play out between two hosts and their local SIMPs. In the scenario, Host A creates a group, and Host B joins it. After the two hosts send some data messages to the group, Host B decides to leave and Host A decides to delete the group 💅 Just like the scenario in Section 6.1, the A/R indications are left out here to keep things clean.
Part of creating a group means the service host hands back a 48-bit key along with a 16-bit group address to the host that made the group 🔑 The creating host has to pass that key along with the address to any other hosts it wants in the group. Those hosts then have to supply the key with the address in their Join Group Requests. The network uses the key to authenticate these operations, which keeps the odds low that unwanted hosts end up in the group on purpose or by accident 🙈 How a host gets the group address and key to other hosts isn't part of HAP, so that's a whole different adventure 🧚
Host SIMP SIMP Host
A A B B
Create Group Request ------>
Create Group Reply <------
Reply Acknowledgment ------>
.
.
>>Group Address,Key>>
.
.
Join Group Request <------
Join Group Reply ------>
Reply Acknowledgment <------
Data Message 1 ------>
Data Message 1 <------ ------>
Data Message 2 <------
Data Message 2 <------ ------>
Leave Group Request <------
Leave Group Reply ------>
Reply Acknowledgment <------
Delete Group Request ------>
Delete Group Reply <------
Reply Acknowledgment ------>🎀 Figure 16 . GROUP EXAMPLE
Any host that's done with a group can dip out 👋 There are two ways: a Leave or a Delete. Both of them are authenticated with the 48-bit key. A Leave is a local thing between a host and its SIMP. It removes the requesting host from the membership list but leaves the group itself alive everywhere else 💖 A Delete is the dramatic one 💀 It wipes all knowledge of the group from every SIMP in the network. HAP lets any member of a group delete it at any time, so a group can be deleted even if the host that created it has left or crashed 😭 Groups can also hang around with zero members, since every member might Leave while nobody ever sends a Delete. Keeping track of and managing groups is the hosts' job 📋
The Create Group Request that goes to the service host to set up a group address is shown in Figure 17. Once the network processes it, the service host replies with a Create Group Reply, as shown in Figure 18 ✨
A host can become a member of a group once it knows the group's address and key, by sending the service host the Join Group Request in Figure 19. The service host answers with a Join Group Reply in the format shown in Figure 20. The host that creates a group automatically becomes a member of it, so it doesn't need to send an explicit Join Group Request 🌸
At any point after joining, a host can leave the group by sending the service host a Leave Group Request, formatted as in Figure 21. The service host responds with a Leave Group Reply, formatted as in Figure 22 🦋
Any member of a group can ask the service host to delete the group with a Delete Group Request. That setup message is shown in Figure 23. After the network processes it, the service host sends a Delete Group Reply to the host, formatted as in Figure 24 🍓
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+🎀 Figure 17 . CREATE GROUP REQUEST
The Create Group Request breaks down like this 💅
0-5Datagram Message Header.6[8-15]Setup Type = 1 (Request).6[0-7]Request Type = 1 (Create Group).7[0-15]Setup Checksum. Covers words 6-8. 🔒8[0-15]Request ID.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+🎀 Figure 18 . CREATE GROUP REPLY
And the Create Group Reply 👑
0-5Datagram Message Header.6[8-15]Setup Type = 2 (Reply).6[0-7]Reply Code. The codes are:
0 = Group created
8 = Network trouble
17 = Insufficient network resources
22 = Reply lost in network7[0-15]Setup Checksum. Covers words 6-12. 🔒8[0-15]Request ID.9[0-15]Group Address. This field holds the 16-bit logical address the network assigns, which the host can use as the group address. 🌈10-12Key. This field holds the 48-bit key the network assigns, tied to the group address. It must be provided for subsequent Join, Leave, and Delete requests that reference the group address. 🗝️
Okay bestie, this is the group part, and it's giving very organized 💅 Every group message starts with the usual Datagram Message Header (0-5), then the setup words. Here's the JOIN GROUP request 🎀
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 19 . JOIN GROUP REQUESTSo, the breakdown ✨
0-5: the Datagram Message Header, same as always 🦋6[8-15]: Setup Type = 1 (Request) 💜6[0-7]: Request Type = 3 (Join Group) 🌸7[0-15]: Setup Checksum. It covers words 6-12 🧚8[0-15]: Request ID 🍓9[0-15]: Group Address. This is the logical address of the group that the host wants to join 👑10-12: Key. This is the key tied to that group address 🔥
Now the reply to a join, which is literally a whole vibe 💖
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 20 . JOIN GROUP REPLY0-5: Datagram Message Header 🎀6[8-15]: Setup Type = 2 (Reply) ✨6[0-7]: Reply Code. Here are the possible ones 👇
2 = Group joined
9 = Bad key
10 = Group address nonexistent
17 = Insufficient network resources7[0-15]: Setup Checksum. It covers words 6-8 🧚8[0-15]: Request ID. This matches the request it's answering 🍓
Next up is LEAVE GROUP, which is the opposite energy 🥀
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 21 . LEAVE GROUP REQUEST0-5: Datagram Message Header 🦋6[8-15]: Setup Type = 1 (Request) 💜6[0-7]: Request Type = 4 (Leave Group) 🌸7[0-15]: Setup Checksum. It covers words 6-12 🧚8[0-15]: Request ID 🍓9[0-15]: Group Address. This is the logical address of the group the host wants to leave 👋10-12: Key. This is the key tied to that group address 🔥
And the LEAVE GROUP reply 💅
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 22 . LEAVE GROUP REPLY0-5: Datagram Message Header 🎀6[8-15]: Setup Type = 2 (Reply) ✨6[0-7]: Reply Code. Options are below 👇
3 = Group left
9 = Bad key
10 = Group address nonexistent
11 = Not member of group
17 = Insufficient network resources7[0-15]: Setup Checksum. It covers words 6-8 🧚8[0-15]: Request ID 🍓
Now DELETE GROUP, which is giving dramatic finale 💀
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 23 . DELETE GROUP REQUEST0-5: Datagram Message Header 🦋6[8-15]: Setup Type = 1 (Request) 💜6[0-7]: Request Type = 2 (Delete Group) 🌸7[0-15]: Setup Checksum. It covers words 6-12 🧚8[0-15]: Request ID 🍓9[0-15]: Group Address 👑10-12: Key 🔥
And the reply, with the most reply codes of all 😭
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 24 . DELETE GROUP REPLY0-5: Datagram Message Header 🎀6[8-15]: Setup Type = 2 (Reply) ✨6[0-7]: Reply Code. Here are all of them 👇
1 = Group deleted
8 = Network trouble
9 = Bad key
10 = Group address nonexistent
11 = Not member of group
17 = Insufficient network resources
22 = Reply lost in network7[0-15]: Setup Checksum. It covers words 6-8 🧚8[0-15]: Request ID 🍓
7 Link Monitoring ✨
Okay, this section is about keeping an eye on the access link 👀 While the access link is running, the host and the SIMP keep stats on traffic load and error rate. The host and SIMP MUST exchange status messages once a second. Trading these messages lets both ends watch the flows in both directions, which is so smart 🧠 Status messages are REQUIRED to support monitoring by the Network Operations Center (NOC) 🛰️
The link restart procedure (see Section 8) sets all internal SIMP counts and statistics for that link back to zero 🔄 As data and control messages get processed, the counts go up to show the total number of messages sent, messages received correctly, and messages received with different classes of errors since the last link restart.
Whenever a status message shows up, the local SIMP counts get a snapshot taken 📸 The local receive counts, together with a sent count sitting in the received status message, let you work out traffic statistics in the one second update interval. This assumes the set of counts from the previous monitoring report was saved. Then, by putting the receive counts and the received sent count into the status message going back the other way, the transmitting end and the receiving end can both figure out the link performance from sender to receiver. Iconic, honestly 💖
The format of the Status control message is shown in Figure 25 🎀
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | MOST RECENT A/R SENT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | STREAM CAPACITY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | TIMESTAMP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SBU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | STU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | RNE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | RWE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | BHC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | HEI |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 25 . STATUS MESSAGEHere's the breakdown of word 0 🔍
0[15]: Message Class = 1 (Control Message) 💜0[14]: Loopback Bit 🔁0[12-13]: Go-Priority 🚦0[4-11]: Reserved 🫶
Okay so the status message has a whole crew of counters, and I am obsessed with how they keep each other honest 🧚💜
0[0-3]Control Message Type = 0 (Status). This is the message type, so the receiver knows it's a status report. 💅1[0-15]Header Checksum. Covers words 0-10. 🔥2[0-15]Most Recent A/R Sent. This is a copy of the most recent acceptance/refusal word 🦋. It's in the periodic status message just in case earlier messages carrying A/R info got lost. Iconic backup plan 🫶3[0-15]Stream Capacity. When the SIMP sends this, the field shows how much stream capacity is unused, in units of data bits per frame. Here's the tea: available capacity depends on a bunch of parameters the user can pick, so this value is the maximum capacity you could reach if the existing host streams were expanded at low reliability. ✨ This field is undefined in messages sent from the host to the SIMP. 🙈4[0-15]Timestamp. This tells you when the status message was generated. When a SIMP sends it, the time is in units of seconds since the last link restart ⏰. The host should also timestamp its messages in units of seconds 🌸5[0-15]Sent By Us. The count of messages we sent since the last link restart, not counting this one 💖6[0-15]Sent To Us. The count of messages sent to us since the last link restart. This is the count from word 5 of the last status message received 🎀7[0-15]Received, No Errors. The count of messages received without errors (since the last link restart) at the moment the last status message was received ✅8[0-15]Received With Errors. The count of messages received with errors (since the last link restart) at the moment the last status message was received. Mood 😭9[0-15]Bad Header Checksums. The count of messages received with bad header checksums (since the last link restart) at the moment the last status message was received 💀10[0-15]Hardware Error Indication. The count of messages received with hardware CRC errors or hardware interface error indications (since the last link restart) at the moment the last status message was received. Hardware drama, periodt 🌈
8 Initialization 💖
Okay bestie, so the Host Access Protocol has a bunch of state variables that must be initialized before it can work properly 🧚 These variables cover the send and receive message numbers used by the acceptance/refusal mechanism, plus the statistics kept for link monitoring 📊 Link initialization should be carried out when a machine is first powered up, when it does a system restart, when the ON state (see below) times out, when a loopback condition times out (see Section 9), or whenever the link goes from non-operational to operational status. Main character reset energy 💅
Initialization happens through an exchange of Restart Request (RR) and Restart Complete (RC) messages between a host and a SIMP 🦋 Figure 26 shows the sequence of events during initialization, and honestly it's giving flowchart realness 🌸 Both the SIMP and the host must implement this state diagram, or you'll get deadlocks and oscillations, and nobody wants that 🙈 This particular sequence makes both sides send and receive the Restart Complete message. Because RC is a reply (to an RR or another RC), getting one back guarantees that the physical link is working in both directions 🔥 There are five states in the diagram:
OFFEntered once a device realizes it needs to restart. The device can notice this itself, or it can be forced to restart when it gets an RR message from the other end while it's in the ON state 💜INITLocal state variables are initialized and local counters are zeroed, but no restart control messages have been sent or received yet 🧚RR-SNTA request to reinitialize (RR) has been sent to the other end, but no restart control messages have been received yet 💌RC-SNTA reply (RC) has been sent to the other end in response to a received reinitialization request (RR). The device is now waiting for a reply (RC) 🎀ONReply (RC) messages have been both sent and received. Data and control messages can now be exchanged between the SIMP and the host. We made it, bestie 🥹✨
All states have 10-second timeouts (not illustrated) that send the protocol back to the OFF state. Any events other than the ones shown in the diagram get ignored, so no drama there 🙈
The Restart Request control message shown in Figure 27 is sent by either a host or a SIMP when it wants to restart a link 🔄 The Restart Request resets all the monitoring statistics to zero and stops all traffic on the link in both directions, so it's a full reset moment 🛑 The Restart Complete message, shown in Figure 28, is sent in response to a received Restart Request or Restart Complete to finish off link initialization 🏁 The Restart Complete also carries a field the host uses to enable or disable the acceptance/refusal mechanism for the link being restarted (see Section 5) 🦋 Once the Restart Complete is processed, traffic can flow on the link 🌈
-------
Any Timeout or ----->| OFF |<-----------------------------
Device Down ------- |
| |
| Device Up |
| Initialize Variables |
| |
V |
--------- |
| INIT | |
--------- |
| | |
Rcv RR | | Snd RR |
Snd RC | | |
| | |
-------------- -------------- |
| | |
| | |
V Rcv RR V |
---------- Snd RC ---------- |
| RC-SNT |<--------------------| RR-SNT | |
---------- ---------- |
| | |
Rcv RC | | Rcv RC |
| | Snd RC |
V V |
------------------------------- |
| |
| |
V |
------- |
Rcv Any ------>| ON |------------------------------
Other | ------- Rcv RR
----------|Figure 26 . HAP LINK RESTART STATE DIAGRAM 🗺️
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXXXX | REASON | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS / SITE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 27 . RESTART REQUEST 📦
Here's how the RESTART REQUEST packet breaks down, bestie 👑
0[15]Message Type = 1 (Control Message). 🎀0[14]Loopback Bit. 🔁0[8-13]Reserved. 🤫0[4-7]Reason. This field tells the SIMP or the host why the restart is happening, using these values:
0 = power up
1 = system restart
2 = link restart
3 = link timeout
4 = loopback timeout0[0-3]Control Message Type = 3 (Restart Request). 💅1[0-15]Header Checksum. Covers words 0-3. 🔥2[0-15]Host Address / Site Number. The host puts its satellite network address in this field. The SIMP checks that the host address is correct for the port being used 🛰️ When the SIMP sends it, this field contains the SIMP site number 🌸3[0-15]Link Number. This field holds the sender's identification of the physical link being used. It's how errors get reported to the Network Operations Center (NOC) when something goes sideways 🚨
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXXX |AR| 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS / SITE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+Figure 28 . RESTART COMPLETE 🎉
And now the RESTART COMPLETE packet, which is the big "we're live" message 🥳
0[15]Message Type = 1 (Control Message). 🎀0[14]Loopback Bit. 🔁0[5-13]Reserved. 🤫0[4]Acceptance/Refusal Control. The host uses this bit to enable or disable the acceptance/refusal mechanism for all traffic on the link 🚦 Here are the values:
0 = Disable acceptance/refusal
1 = Enable acceptance/refusal0[0-3]Control Message Type = 4 (Restart Complete). 🏁1[0-15]Header Checksum. Covers words 0-3. 🔥2[0-15]Host Address / Site Number. 🛰️3[0-15]Link Number. 🔗
9 Loopback Control 🔁
Okay bestie, we're deep in the loopback era now 🎀 Let's go.
The Host Access Protocol gives us a Loopback Request control message 💅 A SIMP or a host can use it to ask the other side to loop back its HAP messages. This usually happens because an operator is doing system fault diagnosis 🔧 To keep things clear, the unit asking for the remote loop is the "transmitter" ✨ and the unit that implements (or rejects) the loop is the "receiver" 🦋 The format of a Loopback Request control message is shown in Figure 29.
When a transmitter is remotely looped, the receiver sends back all of its HAP messages, unmodified, over the access link 🔁 The receiver won't send any of its own messages to the transmitter while it's running the loop 🙈 SIMP-generated messages are told apart from host-generated ones by the Loopback Bit, which is in every HAP message header 🏷️
Two types of remote loopback can be requested: a loop at the receiver's interface hardware, and a loop at the receiver's I/O driver software 🌈 HAP doesn't specify how the receiver should set these up. Some receivers have interface hardware that can't loop the transmitter's messages, so they can only do software loops 💀 A receiver also might not be able to interpret the transmitter's messages while looping them back. If it can interpret them, though, it won't act on any of them except requests to reinitialize the SIMP-host link, which are Restart Request (RR) control messages (see Section 8) 🫶
When a receiver starts a loopback in response to a loopback request, it makes an implicit promise to keep the loop going for the duration given in the Loopback Request message 🤝 But if something unexpected happens, like a system restart in either the transmitter or the receiver, the affected unit will try to reinitialize the SIMP-host link by sending an RR message to the other unit ⚡ If the other unit recognizes that RR message, a link initialization sequence can be completed ✨ That brings the link back to an unlooped condition even if the loop duration hasn't run out yet 🌸 If a receiver can't interpret a transmitter's RR messages, and there's no operator intervention at the receiver, the loop just stays in place for its full duration 😭
HAP doesn't specify the characteristics of any loopback conditions a unit might set up locally 🧚 One example is a SIMP telling its host interface to loop back its own messages. If those local loops also reflect messages received from the remote unit, the remote unit will spot the condition through the HAP header Loopback Bit 👀
Now here's the exact setup sequence for a remote loopback 📋 It starts after the HAP link has been initialized and someone decides to request a remote loop. The transmitter sends a Loopback Request message to the receiver, then waits for one of three things: (1) a 10-second timer to expire, (2) a "Can't implement loop" Unnumbered Response message from the receiver, or (3) one of its own reflected messages 🍓 If (1) or (2) happens, the request has failed, and the transmitter may, at its option, try again with a new Loopback Request message 🔄 If (3) happens, the remote loopback condition has been established 🎉 While it's waiting for one of these events, messages from the receiver get processed normally 👍 Just note that RR messages arriving from the receiver during this time will terminate the loopback request 🛑
When a receiver gets a Loopback Request message, it either implements the requested loop for the specified duration, or returns a "Can't implement loop" response without changing the state of the link 💅 That second option would come back, for example, if a receiver can't implement a requested hardware loop 🔧 A receiver should start reinitializing the link with RR message(s) whenever a loopback condition times out ⏰
There's one asymmetry that is required in the sequence above, to sort out the (unlikely) case where a SIMP and a host both request a remote loopback at the same time 👑 If a SIMP gets a Loopback Request message from a host while it's still waiting for one of events (1)-(3), it returns a "Can't implement loop" response to the host and keeps on waiting 🙅♀️ A host in the opposite situation, though, aborts its own loopback request and acts on the SIMP's loopback request instead 💜
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | LOOP TYPE | 8 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | LOOP DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 29 . LOOPBACK REQUEST0[15]: Message Type = 1 (Control Message).0[14]: Loopback Bit.0[12-13]: Go-Priority.0[8-11]: Reserved.0[4-7]: Loop Type. This field indicates the type of loop that is being requested, as follows:0 = Undefined1 = Loop at interface (hardware loop)2 = Loop at driver (software loop)3-15 = Undefined
0[0-3]: Control Message Type = 8 (Loopback Request).1[0-15]: Header Checksum. Covers words 0-2.2[0-15]: Loop Duration. The transmitter of a Loopback Request message uses this field to specify the number of seconds that the loop is to be maintained by the receiver ⏱️
10. Other Control Messages ✨
Before a SIMP or a host voluntarily disables a SIMP-host link, it should send at least one Link Going Down control message over that link 📣 The format of that message is shown in Figure 30. HAP doesn't define what a SIMP or a host should do when it gets one of these 🤷♀️ Telling the Network Operations Center (NOC) and/or the network users about the upcoming event is a typical move 📨 Also, each Link Going Down message only applies to the SIMP-host link it's sent over. If a host and a SIMP are connected by multiple links, those links can be disabled selectively 🎛️
A No Operation (NOP) control message can be sent at any time by a SIMP or a host 🧘♀️ The format is shown in Figure 31. A NOP message holds up to 32 words of arbitrary data, which HAP leaves undefined 🌷 NOP messages may be required in some cases to clear the state of the SIMP-host link hardware 🧹
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | REASON | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | TIME UNTIL DOWN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | DOWN DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 30 . LINK GOING DOWN0[15]: Message Type = 1 (Control Message).0[14]: Loopback Bit.0[12-13]: Go-Priority.0[8-11]: Reserved.0[4-7]: Reason. This field is used by the SIMP or the host to indicate the reason for disabling this SIMP-host link, as follows:0 = NOT going down: Cancel previous Link Going Down message1 = Unspecified reason2 = Scheduled PM3 = Scheduled hardware work4 = Scheduled software work5 = Emergency restart6 = Power outage7 = Software breakpoint8 = Hardware failure9 = Not scheduled up10 = Last warning: The SIMP or host is disabling the link in 10 seconds11-15 = Undefined
0[0-3]: Control Message Type = 7 (Link Going Down).1[0-15]: Header Checksum. Covers words 0-3.2[0-15]: Time Until Down. This field specifies the amount of time remaining until the SIMP or host disables the link (in minutes). An entry of zero indicates that there is less than a minute remaining ⏳3[0-15]: Down Duration. This field specifies the amount of time that the SIMP-host link will be down (in minutes). An entry of zero indicates that the down duration will be less than a minute. An entry of -1 (all bits set) indicates an indefinite down duration 🌙
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXX | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2-N | ARBITRARY DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 31 . NO OPERATION (NOP)0[15]: Message Type = 1 (Control Message).0[14]: Loopback Bit.0[4-13]: Reserved.0[0-3]: Control Message Type = 6 (NOP).1[0-15]: Header Checksum. Covers words 0-N.2-N: Arbitrary Data. Up to 32 words of data may be sent. The data are undefined by HAP 🫧
📦 where this page comes from
- ietf: rfc907 1984-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms