RFC 1190
Experimental Internet Stream Protocol: Version 2 (ST-II)
Experimental Internet Stream Protocol, Version 2 (ST-II) 🎀
okay bestie, let's get into RFC 1190 🦋 It's part of the Network Working Group series, it was written by the CIP Working Group with C. Topolcic as Editor, and it's dated October 1990 📅. It's a Limited-Use Experimental Protocol, so it's experimental, not a standard yet 👀. The header says it obsoletes IEN-119, and no Updates field is listed. Main character energy from the very first line 💅
Status of this Memo 🌸
so this memo is a revised version of the Internet Stream Protocol, which was first defined in IEN-119 [8]. The revision is based on what people learned from experiments with the original version, plus requests, discussion, and suggestions for improvements 🧚 It's a Limited-Use Experimental Protocol. If you want to know where it stands in the standardization process, check the current edition of the "IAB Official Protocol Standards" 📚 Distribution of this memo is unlimited ✨
1. Abstract ✨
okay this is the big-picture bit 💖 This memo defines the Internet Stream Protocol, Version 2 (ST-II). It's an IP-layer protocol that gives you end-to-end guaranteed service across an internet 🔥 It obsoletes IEN 119 "ST - A Proposed Internet Stream Protocol," which Jim Forgie wrote in 1979. That was the previous specification of ST 🕰️
ST-II is not compatible with Version 1 of the protocol, but it keeps a lot of the same architecture and philosophy 🦋 The goal is to fill in some of the areas that version left unaddressed, make it easier to implement, and support a wider range of applications 🌈 Iconic glow-up behavior, honestly 😭
1.1. Table of Contents 💅
Status of this Memo . . . . . . . . . . . . 1
1. Abstract . . . . . . . . . . . . . . . 1
1.1. Table of Contents . . . . . . . . . . . 2
1.2. List of Figures . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . 7
2.1. Major Differences Between ST and ST-II . . . . 8
2.2. Concepts and Terminology . . . . . . . . . 9
2.3. Relationship Between Applications and ST . . . . 11
2.4. ST Control Message Protocol . . . . . . . . 12
2.5. Flow Specifications . . . . . . . . . . . 14
3. ST Control Message Protocol Functional Description . 17
3.1. Stream Setup . . . . . . . . . . . . . 18
3.1.1. Initial Setup at the Origin . . . . . . . 18
3.1.2. Invoking the Routing Function . . . . . . 19
3.1.3. Reserving Resources . . . . . . . . . . 19
3.1.4. Sending CONNECT Messages . . . . . . . . 20
3.1.5. CONNECT Processing by an Intermediate Agent . . 22
3.1.6. Setup at the Targets . . . . . . . . . 23
3.1.7. ACCEPT Processing by an Intermediate Agent . . 24
3.1.8. ACCEPT Processing by the Origin . . . . . . 26
3.1.9. Processing a REFUSE Message . . . . . . . 27
3.2. Data Transfer . . . . . . . . . . . . . 30
3.3. Modifying an Existing Stream . . . . . . . . 31
3.3.1. Adding a Target . . . . . . . . . . . 31
3.3.2. The Origin Removing a Target . . . . . . . 33
3.3.3. A Target Deleting Itself . . . . . . . . 35
3.3.4. Changing the FlowSpec . . . . . . . . . 36
3.4. Stream Tear Down . . . . . . . . . . . . 36
3.5. Exceptional Cases . . . . . . . . . . . 37
3.5.1. Setup Failure due to CONNECT Timeout . . . . 37
3.5.2. Problems due to Routing Inconsistency . . . . 38
3.5.3. Setup Failure due to a Routing Failure . . . 39
3.5.4. Problems in Reserving Resources . . . . . . 41
3.5.5. Setup Failure due to ACCEPT Timeout . . . . 41
3.5.6. Problems Caused by CHANGE Messages . . . . . 42
3.5.7. Notification of Changes Forced by Failures . . 42
3.6. Options . . . . . . . . . . . . . . . 44
3.6.1. HID Field Option . . . . . . . . . . . 44
3.6.2. PTP Option . . . . . . . . . . . . . 44
3.6.3. FDx Option . . . . . . . . . . . . . 45
3.6.4. NoRecovery Option . . . . . . . . . . 46
3.6.5. RevChrg Option . . . . . . . . . . . 46
3.6.6. Source Route Option . . . . . . . . . . 46
3.7. Ancillary Functions . . . . . . . . . . . 48
3.7.1. Failure Detection . . . . . . . . . . 48
3.7.1.1. Network Failures . . . . . . . . . . 48
3.7.1.2. Detecting ST Stream Failures . . . . . . 49
3.7.1.3. Subset . . . . . . . . . . . . . 51
3.7.2. Failure Recovery . . . . . . . . . . . 51
3.7.2.1. Subset . . . . . . . . . . . . . 55
3.7.3. A Group of Streams . . . . . . . . . . 56
3.7.3.1. Group Name Generator . . . . . . . . 57
3.7.3.2. Subset . . . . . . . . . . . . . 57
3.7.4. HID Negotiation . . . . . . . . . . . 58
3.7.4.1. Subset . . . . . . . . . . . . . 64
3.7.5. IP Encapsulation of ST . . . . . . . . . 64
3.7.5.1. IP Multicasting . . . . . . . . . . 65
3.7.6. Retransmission . . . . . . . . . . . 66
3.7.7. Routing . . . . . . . . . . . . . . 67
3.7.8. Security . . . . . . . . . . . . . 67
3.8. ST Service Interfaces . . . . . . . . . . 68
3.8.1. Access to Routing Information . . . . . . 69
3.8.2. Access to Network Layer Resource Reservation . 70
3.8.3. Network Layer Services Utilized . . . . . . 71
3.8.4. IP Services Utilized . . . . . . . . . 71
3.8.5. ST Layer Services Provided . . . . . . . 72
4. ST Protocol Data Unit Descriptions . . . . . . . 75
4.1. Data Packets . . . . . . . . . . . . . 76
4.2. ST Control Message Protocol Descriptions . . . . 77
4.2.1. ST Control Messages . . . . . . . . . . 79
4.2.2. Common SCMP Elements . . . . . . . . . 80
4.2.2.1. DetectorIPAddress . . . . . . . . . 80
4.2.2.2. ErroredPDU . . . . . . . . . . . . 80
4.2.2.3. FlowSpec & RFlowSpec . . . . . . . . 81
4.2.2.4. FreeHIDs . . . . . . . . . . . . 84
4.2.2.5. Group & RGroup . . . . . . . . . . 85
4.2.2.6. HID & RHID . . . . . . . . . . . . 86
4.2.2.7. MulticastAddress . . . . . . . . . . 86
4.2.2.8. Name & RName . . . . . . . . . . . 87
4.2.2.9. NextHopIPAddress . . . . . . . . . . 88
4.2.2.10. Origin . . . . . . . . . . . . . 88
4.2.2.11. OriginTimestamp . . . . . . . . . . 89
4.2.2.12. ReasonCode . . . . . . . . . . . . 89
4.2.2.13. RecordRoute . . . . . . . . . . . 94
4.2.2.14. SrcRoute . . . . . . . . . . . . 95
4.2.2.15. Target and TargetList . . . . . . . . 96
4.2.2.16. UserData . . . . . . . . . . . . 98
4.2.3. ST Control Message PDUs . . . . . . . . 99
4.2.3.1. ACCEPT . . . . . . . . . . . . . 100
4.2.3.2. ACK . . . . . . . . . . . . . . 102
4.2.3.3. CHANGE-REQUEST . . . . . . . . . . 103
4.2.3.4. CHANGE . . . . . . . . . . . . . 104
4.2.3.5. CONNECT . . . . . . . . . . . . . 105
4.2.3.6. DISCONNECT . . . . . . . . . . . . 110
4.2.3.7. ERROR-IN-REQUEST . . . . . . . . . . 111
4.2.3.8. ERROR-IN-RESPONSE . . . . . . . . . 112
4.2.3.9. HELLO . . . . . . . . . . . . . 113
4.2.3.10. HID-APPROVE . . . . . . . . . . . 114
4.2.3.11. HID-CHANGE-REQUEST . . . . . . . . . 115
4.2.3.12. HID-CHANGE . . . . . . . . . . . . 116
4.2.3.13. HID-REJECT . . . . . . . . . . . . 118
4.2.3.14. NOTIFY . . . . . . . . . . . . . 120
4.2.3.15. REFUSE . . . . . . . . . . . . . 122
4.2.3.16. STATUS . . . . . . . . . . . . . 124
4.2.3.17. STATUS-RESPONSE . . . . . . . . . . 126
4.3. Suggested Protocol Constants . . . . . . . . 127
5. Areas Not Addressed . . . . . . . . . . . . 131
6. Glossary . . . . . . . . . . . . . . . 135
7. References . . . . . . . . . . . . . . . 143
8. Security Considerations. . . . . . . . . . . 144
9. Authors' Addresses . . . . . . . . . . . . 145
Appendix 1. Data Notations . . . . . . . . . . 1471.2. List of Figures 📜
this section is where the list of figures goes, and in this copy it's empty 🌙
Figure 1. Protocol Relationships . . . . . . . . . 6
Figure 2. Topology Used in Protocol Exchange Diagrams . . 16
Figure 3. Virtual Link Identifiers for SCMP Messages . . 16
Figure 4. HIDs Assigned for ST User Packets . . . . . 18
Figure 5. Origin Sending CONNECT Message . . . . . . 21
Figure 6. CONNECT Processing by an Intermediate Agent . . 22
Figure 7. CONNECT Processing by the Target . . . . . . 24
Figure 8. ACCEPT Processing by an Intermediate Agent . . 25
Figure 9. ACCEPT Processing by the Origin . . . . . . 26
Figure 10. Sending REFUSE Message . . . . . . . . . 28
Figure 11. Routing Around a Failure . . . . . . . . 29
Figure 12. Addition of Another Target . . . . . . . . 32
Figure 13. Origin Removing a Target . . . . . . . . 34
Figure 14. Target Deleting Itself . . . . . . . . . 35
Figure 15. CONNECT Retransmission after a Timeout . . . . 38
Figure 16. Processing NOTIFY Messages . . . . . . . . 43
Figure 17. Source Routing Option . . . . . . . . . 47
Figure 18. Typical HID Negotiation (No Multicasting) . . . 60
Figure 19. Multicast HID Negotiation . . . . . . . . 61
Figure 20. Multicast HID Re-Negotiation . . . . 62
Figure 21. ST Header . . . . . . . . . . . . . 75
Figure 22. ST Control Message Format . . . . . . . . 77
Figure 23. ErroredPDU . . . . . . . . . . . . . 80
Figure 24. FlowSpec & RFlowSpec . . . . . . . . . . 81
Figure 25. FreeHIDs . . . . . . . . . . . . . . 85
Figure 26. Group & RGroup . . . . . . . . . . . . 85
Figure 27. HID & RHID . . . . . . . . . . . . . 86
Figure 28. MulticastAddress . . . . . . . . . . . 86
Figure 29. Name & RName . . . . . . . . . . . . 87
Figure 30. NextHopIPAddress . . . . . . . . . . . 88
Figure 31. Origin . . . . . . . . . . . . . . 88
Figure 32. OriginTimestamp . . . . . . . . . . . 89
Figure 33. ReasonCode . . . . . . . . . . . . . 89
Figure 34. RecordRoute . . . . . . . . . . . . . 94
Figure 35. SrcRoute . . . . . . . . . . . . . . 95
Figure 36. Target . . . . . . . . . . . . . . 97
Figure 37. TargetList . . . . . . . . . . . . . 97
Figure 38. UserData . . . . . . . . . . . . . . 98
Figure 39. ACCEPT Control Message . . . . . . . . . 101
Figure 40. ACK Control Message . . . . . . . . . . 102
Figure 41. CHANGE-REQUEST Control Message . . . . . . 103
Figure 42. CHANGE Control Message . . . . . . . . . 105
Figure 43. CONNECT Control Message . . . . . . . . . 109
Figure 44. DISCONNECT Control Message . . . . . . . . 110
Figure 45. ERROR-IN-REQUEST Control Message . . . . . . 111
Figure 46. ERROR-IN-RESPONSE Control Message . . . . . 112
Figure 47. HELLO Control Message . . . . . . . . . 113
Figure 48. HID-APPROVE Control Message . . . . . . . 114
Figure 49. HID-CHANGE-REQUEST Control Message . . . . . 115
Figure 50. HID-CHANGE Control Message . . . . . . . . 117
Figure 51. HID-REJECT Control Message . . . . . . . . 119
Figure 52. NOTIFY Control Message . . . . . . . . . 121
Figure 53. REFUSE Control Message . . . . . . . . . 123
Figure 54. STATUS Control Message . . . . . . . . . 125
Figure 55. STATUS-RESPONSE Control Message . . . . . . 126
Figure 56. Transmission Order of Bytes . . . . . . . 147
Figure 57. Significance of Bits . . . . . . . . . . 147 +--------------------+
| Conference Control |
+--------------------+
|
+-------+ +-------+ |
| Video | | Voice | | +-----+ +------+ +-----+ +-----+ Application
| Appl | | Appl | | | SNMP| |Telnet| | FTP | ... | | Layer
+-------+ +-------+ | +-----+ +------+ +-----+ +-----+
| | | | | | |
V V | | | | | ------------
+-----+ +-----+ | | | | |
| PVP | | NVP | | | | | |
+-----+ +-----+ + | | | |
| \ | \ \ | | | |
| +-----|--+-----+ | | | |
| Appl.|control V V V V V
| ST data | +-----+ +-------+ +-----+
| & control| | UDP | | TCP | ... | | Transport
| | +-----+ +-------+ +-----+ Layer
| /| / | \ / / | / /|
|\ / | +------+--|--\-----+-/--|--- ... -+ / |
| \ / | | | \ / | / |
| \ / | | | \ +----|--- ... -+ | -----------
| \ / | | | \ / | |
| V | | | V | |
| +------+ | | | +------+ | +------+ |
| | SCMP | | | | | ICMP | | | IGMP | | Internet
| +------+ | | | +------+ | +------+ | Layer
| | | | | | | | |
V V V V V V V V V
+-----------------+ +-----------------------------------+
| STream protocol |->| Internet Protocol |
+-----------------+ +-----------------------------------+
| \ / |
| \ / |
| X | ------------
| / \ |
| / \ |
VV VV
+----------------+ +----------------+
| (Sub-) Network |...| (Sub-) Network | (Sub-)Network
| Protocol | | Protocol | Layer
+----------------+ +----------------+
Figure 1. Protocol Relationships2. Introduction ✨
ST has been developed to support efficient delivery of streams of packets to either single or multiple destinations in applications requiring guaranteed data rates and controlled delay characteristics 🎀 The motivation for the original protocol was that IP [2] [15] did not provide the delay and data rate characteristics necessary to support voice applications. Like, it literally couldn't do voice properly 💀
ST is an internet protocol at the same layer as IP, see Figure 1. ST differs from IP in that IP, as originally envisioned, did not require routers (or intermediate systems) to maintain state information describing the streams of packets flowing through them. ST incorporates the concept of streams across an internet. Every intervening ST entity maintains state information for each stream that passes through it. The stream state includes forwarding information, including multicast support for efficiency, and resource information, which allows network or link bandwidth and queues to be assigned to a specific stream. This pre-allocation of resources allows data packets to be forwarded with low delay, low overhead, and a low probability of loss due to congestion. The characteristics of a stream, such as the number and location of the endpoints, and the bandwidth required, may be modified during the lifetime of the stream. This allows ST to give a real time application the guaranteed and predictable communication characteristics it requires, and is a good vehicle to support an application whose communications requirements are relatively predictable. It's giving reserved lanes for your data 🦋
ST proved quite useful in several early experiments that involved voice conferences in the Internet. Since that time, ST has also been used to support point-to-point streams that include both video and voice. Recently, multimedia conferencing applications have been developed that need to exchange real-time voice, video, and pointer data in a multi-site conferencing environment. Multimedia conferencing across an internet is an application for which ST provides ideal support. Simulation and wargaming applications [14] also place similar requirements on the communication system. Other applications may include scientific visualization between a number of workstations and one or more remote supercomputers, and the collection and distribution of real-time sensor data from remote sensor platforms. ST may also be useful to support activities that are currently supported by IP, such as bulk file transfer using TCP. so many use cases, bestie 🌈
Transport protocols above ST include the Packet Video Protocol (PVP) [5] and the Network Voice Protocol (NVP) [4], which are end-to-end protocols used directly by applications. Other transport layer protocols that may be used over ST include TCP [16], VMTP [3], etc. They provide the user interface, flow control, and packet ordering. This specification does not describe these higher layer protocols. Those are someone else's job, not ours 💅
2.1. Major Differences Between ST and ST-II 👑
ST-II supports a wider variety of applications than did the original ST. The differences between ST and ST-II are fairly straight forward yet provide great improvements. Four of the more notable differences are:
- ST-II is decoupled from the Access Controller (AC). The AC, as well as providing a rudimentary access control function, also served as a centralized repository and distributor of the conference information. If an AC is necessary, it should be an entity in a higher layer protocol. A large variety of applications such as conferencing, distributed simulations, and wargaming can be run without an explicit AC.
- The basic stream construct of ST-II is a directed tree carrying traffic away from a source to all the destinations, rather than the original ST's omniplex structure. For example, a conference is composed of a number of such trees, one for traffic from each participant. Although there are more (simplex) streams in ST-II, each is much simpler to manage, so the aggregate is much simpler. This change has a minimal impact on the application. Okay the tree thing is so clean 🌸
- ST-II defines a number of the robustness and recovery mechanisms that were left undefined in the original ST specification. In case of a network or ST Agent failure, a stream may optionally be repaired automatically (i.e., without intervention from the user or the application) using a pruned depth first search starting at the ST Agent immediately preceding the failure.
- ST-II does not make an inherent distinction between streams connecting only two communicants and streams among an arbitrary number of communicants. no more "is this a call or a conference" drama 🙈
This memo is the specification for the ST-II Protocol. Since there should be no ambiguity between the original ST specification and the specification herein, the protocol is simply called ST hereafter. ST-II is ST now, periodt 💖
okay so ST is literally the protocol that ST entities use to talk to each other 💅 and it's the same one whether they're chatting with a higher layer protocol or just forwarding ST packets between attached networks. no split personality, iconic 🎀
the rest of this section is a quick tour of the ST Protocol 🧚 Section 3 (page 17) is where the operations the protocol requires get the full breakdown. Section 4 (page 75) describes the ST Protocol Data Units that ST entities swap. the stuff that's still unresolved lives in Section 5 (page 131). the glossary is Section 6 (page 135) and the references are Section 7 (page 143) 📚
also, this memo defines "subsets" of ST that you can implement. a subsetted implementation doesn't have full ST functionality, but it can still interoperate with other similarly subsetted implementations, or with a full one, in a predictable and consistent way ✨ it's giving "start small, grow later" energy. you get a service running with minimum effort and a well defined growth path. lowkey the best plan 🌸
2.2. Concepts and Terminology 🦋
okay the ST packet header doesn't have to be compatible with the IP packet header 💖 the one exception is the IP Version Number (the first four bits), which is how you tell ST packets (IP Version 5) apart from IP packets (IP Version 4). ST packets, aka protocol data units (PDUs), can get encapsulated in IP for two reasons: to get connectivity (maybe with degraded service) across parts of an internet that don't support ST, or to access things like security that ST doesn't provide directly 🔐
an internet entity that implements the ST Protocol is called an "ST Agent" 👑 there are two kinds we talk about: "host ST agents", also called "host agents", and "intermediate ST agents", also called "intermediate agents". host agents are the ones sourcing or sinking data for a higher layer protocol or application, and intermediate agents are the ones forwarding data between directly attached networks. this split isn't part of the protocol, it's just a conceptual thing ✨ a single ST agent can totally be doing both roles at once. every ST agent should be able to deliver packets to a higher layer protocol. every ST agent can replicate ST data packets when it needs multi-destination delivery, and it can send packets whether they came in from a network interface or from a higher layer protocol. and that's it, there are no other kinds of ST agents 🫶
ST gives applications an end-to-end, flow oriented service across an internet 🌈 this service runs on objects called "streams". ST data packets aren't totally independent like IP data packets are 🙈 they only get sent as part of a point-to-point or point-to-multi- point stream. ST creates a stream during a setup phase before any data goes out. during setup, routes get selected and internetwork resources get reserved. unless the stream gets explicitly changed, those routes stay in effect until the stream is explicitly torn down 💜
an ST stream is:
- the set of paths that data generated by an application entity traverses on its way to its peer application entity(s) that receive it,
- the resources allocated to support that transmission of data, and
- the state information that is maintained describing that transmission of data.
each stream is identified by a globally unique "Name" 🏷️ see Section 4.2.2.8 (page 87). the Name shows up in ST control operations but isn't used in ST data packets. a bunch of streams can be related as members of a bigger aggregate called a "group", and a group is identified by a "Group Name", see Section 3.7.3 (page 56) 🍓
the end-users of a stream are called the "participants" in the stream 🧁 data only travels one direction through any given stream. the host agent that puts data into the stream is the "origin", and the host agents that receive it are the "targets". so for any stream, one participant is the origin and everyone else is a target 💅
a stream is "multi-destination simplex" because data only goes one way: from origin to targets 🌸 you can picture a stream as a directed tree where the origin is the root, all the branches point away from the root toward the targets (the leaves), and a "hop" is one edge of that tree 🌳 the ST agent on the end of an edge in the direction toward the origin is the "previous-hop ST agent", or just the "previous-hop". the ST agents one hop away from a previous-hop, in the direction toward the targets, are the "next-hop ST agents", or the "next-hops". it's possible that several edges between a previous-hop and several next-hops are actually implemented by a network level multicast group 📡
packets cross a hop for one of two purposes: data or control 🎀 for ST data packet handling, hops are marked by "Hop IDentifiers" (HIDs), which are used for efficient forwarding instead of the stream's Name. a HID gets negotiated among several agents so data forwarding can happen efficiently on both a point-to-point and a multicast basis 🧚 all control message exchange happens point-to-point between a pair of agents. for control message handling, Virtual Link Identifiers are used to quickly dispatch control messages to the right stream's state machine 🚀
ST needs routing decisions at several points in the stream setup and management process 🗺️ ST assumes there's an appropriate routing algorithm it can access; see Section 3.8.1 (page 69). but routing is treated as a separate issue, so neither the routing algorithm nor its implementation is specified here 🙃 a routing algorithm might try to minimize the number of hops to the target(s), or it could be more intelligent and try to minimize the total internet resources consumed. ST works equally well with any reasonable routing algorithm 💖 and having a source routing option doesn't get rid of the need for an appropriate routing algorithm in ST agents, periodt 💅
2.3. Relationship Between Applications and ST 💌
it's the job of an ST application entity to swap information with its peers, usually over IP, as needed to figure out the structure of the communication before the ST stream gets set up 📨 that includes:
- identifying the participants,
- determining which are targets for which origins,
- selecting the characteristics of the data flow between any origin and its target(s),
- specifying the protocol that resides above ST,
- identifying the Service Access Point (SAP), port, or socket relevant to that protocol at every participant, and
- ensuring security, if necessary.
the protocol layer above ST has to pass that info down to the ST protocol layer when it creates a stream 🫶
ST uses a flow specification, shortened to "FlowSpec", to describe the characteristics a stream needs 📊 that includes bandwidth, delay, and reliability parameters. more parameters might get added later in an extensible way ✨ the FlowSpec describes both the desired values and their minimal allowable values, so the ST agents get some freedom in allocating their resources 🦋 the ST agents also collect info about the characteristics of the path they chose, and pass that along to the origin and the targets of the stream 💜
ST stream setup control messages carry some stuff that isn't specifically ST's business, but it gets passed through the interface to the protocol above ST 🌈 the "next protocol identifier" ("NextPcol") lets ST demultiplex streams to a bunch of possible higher layer protocols 🎀 the SAP for each participant lets the higher layer protocol demultiplex further to a specific application entity 🍓 there's also a UserData parameter, see Section 4.2.2.16 (page 98) 🧁
2.4. ST Control Message Protocol 👑
ST agents create and manage a stream using the ST Control Message Protocol (SCMP) 🛠️ conceptually, SCMP sits right above ST (the same way ICMP sits above IP), but it's an integral part of ST, not a separate thing 🫶 control messages are used to:
- create streams,
- refuse creation of a stream,
- delete a stream in whole or in part,
- negotiate or change a stream's parameters,
- tear down parts of streams as a result of router or network failures, or transient routing inconsistencies, and
- reroute around network or component failures.
SCMP follows a request-response model 🔁 SCMP reliability is ensured through retransmission after timeout; see Section 3.7.6 (page 66) ⏱️
an ST application that's going to transmit data asks its local ST agent, the origin, to create a stream 📣 only the origin requests creation of a stream, but all the ST agents from the origin to the targets take part in creating and managing it 🤝 since a stream is simplex, each participant that wants to transmit data has to request that a stream be created 💅
an ST agent that gets an indication that a stream is being created must:
- negotiate a HID with the previous-hop identifying the stream,
- map the list of targets onto a set of next-hop ST agents through the routing function,
- reserve the local and network resources required to support the stream,
- update the FlowSpec, and
- propagate the setup information and partitioned target list to the next-hop ST agents.
when a target gets the setup message, it must ask the specified application process whether it's willing to accept the stream, and tell the origin accordingly 🙋
once a stream is established, the origin can safely send data ✨ ST and its implementations are optimized for fast, efficient forwarding of data packets by the ST agents using the HIDs, even though that adds overhead to stream creation and management 🚀 specifically, the forwarding decisions (figuring out the set of next-hop ST agents that a data packet for a particular stream gets sent to) are made during the stream setup phase 🗂️ the shorthand HIDs are negotiated at that time, not only to shrink the data packet header, but also to access the stream's forwarding information efficiently 🧚 when possible, network-layer multicast is used to forward a data packet to multiple next-hop ST agents across a network 📡 note that when network-layer multicast is used, all members of the multicast group must participate in negotiating a common HID 🫶
An established stream can be changed at any time, bestie 💅. You can add or remove targets, or change the network resources it's using. ✨ Either the origin or a target can tear the stream down 🙈. A target can leave on its own and the others won't even notice 🦋. The origin can remove any group of targets it wants, and the rest stay put 🌸. If the origin removes every target, the whole stream is gone 💀.
The ST agents watch over the stream while it's running 👀. If they spot a failure, they can try to fix it 🔧. Usually that means tearing down the broken part and rebuilding it around the bad component(s) 🧩. The rebuild always starts from the origin's side of the failure, no exceptions 👑. The origin gets to choose whether intermediate ST agents should try to repair things automatically, or whether the failure should be reported straight back to the origin 🎀. If automatic recovery is picked but an intermediate agent can't fix it, that agent passes the failure info backward until it reaches an agent that can 🫶. If the info makes it all the way back to the origin, the application decides whether to abort or try the recovery again 🍓.
ST can handle any connection shape you like, but some shapes are super common, so they get special features and options for extra speed 🚀. These are:
- streams with only a single target (see Section 3.6.2 (page 44)), and
- pairs of streams that give full duplex communication between two points (see Section 3.6.3 (page 45)) 💜.
These features mean the most popular setups need less setup time, fewer control messages, and less overhead than the general case ⭐.
2.5. Flow Specifications 🎀
Real-time data like voice and video is super predictable 🔮. It might come in packets of one fixed size, sent at one fixed rate 🎶. Or the bandwidth can change, because the packet size or rate changes, as long as there's a set maximum and maybe a non-zero minimum 🌈. That variation can even be predictable if you have a model of how the data gets made 📈. Depending on the equipment, the packet size and rate might be negotiable 🛠️. Some apps, like voice, only send packets at that rate some of the time 🗣️. Networks carrying real-time data need to add as little delay and delay variance as they can, but they're expected to add some, not zero 💫.
The FlowSpec has three jobs 💅. First, it goes in the setup message and says the packet size and rate the origin wants, plus the smallest it can live with 🍓. ST agents use this to try to reserve resources on the networks in between 🌐. Second, when the setup message gets to the target, the FlowSpec shows what packet size and rate actually made it along the path, plus the accumulated mean delay and delay variance expected for data packets on that path 📊. The target uses that to decide if it wants the connection 🤔. It can shrink the reserved resources if it wants to, as long as that's still possible 🪄. Third, if the target says yes, it sends the updated FlowSpec back to the origin, so the origin can decide if it still wants to be in the stream with what it actually got 💖.
When the data from stream users comes in at changing rates, including bursts of different rates and lengths, there's a chance to serve more subscribers ✨. The trick is to guarantee service for each stream's average rate, then keep some extra network capacity shared by all the streams for the bursts 🧁. Analog voice networks figured this out already and call it time assigned speech interpolation (TASI) 📞. Only the talkspurts of a conversation get sent, and during the silences the circuit can carry other people's talkspurts instead 🤫. The FlowSpec is meant to help algorithms that do similar things 🧠. This document doesn't propose any such algorithms, though; the hope is that folks will experiment with them 🧪. To leave room for experiments and different ways of describing app traffic, the FlowSpec includes a "DutyFactor", and we expect a "burst descriptor" will be needed too 🌸.
The FlowSpec will probably need revising as people gain experience with connections that have lots of participants, use many media types, and cross all sorts of mixed internetworks 🌍. A change to the FlowSpec doesn't automatically mean a new ST version 🙌. It only means the FlowSpec version number gets bumped and software that handles the new FlowSpec gets distributed 📦. We also suggest that if a change adds extra info for better operation, like a burst descriptor, it goes at the end of the FlowSpec 🔚. The current parameters should stay where they are, so older software can still process them with minimal changes 🫶.
**** ****
* * ST Agent 1 * * +---+
* *------- o ---------* *-------+ B |
* * * * +---+
* * ****
+---+ * * |
| | * * |
| A +---------* * o ST Agent 3
| | * * |
+---+ * * |
* * ***
* * * * +---+
* * ST Agent 2 * *-------+ C |
* *------- o --------* * +---+
* * * *
**** * *
* *
+---+ * * +---+
| E +--------* *-------+ D |
+---+ * * +---+
***Figure 2. Topology Used in Protocol Exchange Diagrams 🗺️
**** ST Agent 1 ****
* +--+---14--- o -----15--+----+--44---+---+
* | +-+--11--- -----16--+-+ * | B |
* | | * * |+-+--45---+---+
* | | * *++*
+---+ * | | * 34 ||32
| +----4----+--+ | * ||
| A +----6----+----+ * o ST Agent 3
| +----5----+---+ * |
+---+ * | * | 33
* | * ST *+*
* | * Agent * | *
* | * 2 -----24-+--+ * +---+
* +--+--23--- o -----25-+-----+--54---+ C |
* * -----26-+---+ * +---+
**** -----27-+-+ | *
* | | *
+---+ * | | * +---+
| E +---74---+-+ +-+--64---+ D |
+---+ * * +---+
***Figure 3. Virtual Link Identifiers for SCMP Messages 🦋
3. ST Control Message Protocol Functional Description 💫
This section is the functional tour of the ST Control Message Protocol (SCMP) 🗺️. Section 4 (page 75) has the actual formats for the control message PDUs 📄. We start with stream setup 🚪. Then we cover the exceptional cases 🧯. After that, the options an application or ST agent can pick and the complications they bring 🎛️. Once a stream is up, it moves into the data transfer phase, which gets described too 📡. When data transfer is done, the stream has to be torn down and its resources released, and we go over the control messages for that 🧹. Streams can change resources or participants during their lifetime, so those procedures are covered as well 🔄. The section wraps up with some extra stuff like failure detection and recovery, HID negotiation, routing, security, and so on 🌈.
To make the SCMP exchanges for setting up and maintaining ST streams easier to follow, there are a bunch of figures in this section 🖼️. The protocol interactions in the figures all use the topology from Figure 2 🗺️. Taken together, the figures:
- create a stream from an application at A to three peers at B, C and D,
- add a peer at E,
- disconnect peers B and C, and
- have D drop out of the stream 👋.
Other figures show exchanges for failure recovery 🛠️.
To make dispatching inside SCMP more uniform and efficient, each end of a hop gets a Virtual Link Identifier from the agent at that end 🏷️. That identifier uniquely identifies the hop within that agent, and ties it to a particular stream's state machine(s) 🔗. The identifier on the end that's sending a message is the Sender Virtual Link Identifier (SVLId) 📤. The one on the receiving end is the Receiver Virtual Link Identifier (RVLId) 📥. Whenever one agent sends a control message for the other to receive, the sender puts the receiver's identifier in the RVLId field and its own in the SVLId field 💌. When a reply goes out, the SVLId and RVLId values get swapped, since the sender and receiver roles have swapped too 🔁. VLIds with values zero through three are received and should not be assigned in response to CONNECT messages 🙅. Figure 3 shows the hops used in the examples and sums up the VLIds assigned to them 🧁.
Figure 4 similarly sums up the HIDs that get negotiated as the stream is created 🌸.
Okay so the diagrams in this bit form a little progression, which is lowkey genius 🧚 Each step of connection setup is spread across a bunch of figures, so you have to follow the arrows like a plot twist 🎀
**** ST Agent 1 ****
* +>+--1200-> o -------->+--->+-3600->+---+
* ^ * * * | B |
* | * * +->+-6000->+---+
* | * *+**
+---+ * | * ^
| +-------->+-->+ * |
| A | * * o St Agent 3
| +-------->+-->+ * ^
+---+ * | * | 4801
* | * *+*
* V * ST Agent 2 * ^ * +---+
* +>+--2400-> o ------->+->+->+-4800->+ C |
**** * | * 4801 +---+
* | *
+---+ * V * +---+
| E +<-4800--+<-+->+-4800->+ D |
+---+ * * 4801 +---+
***Figure 4. HIDs Assigned for ST User Packets
Some of the diagrams that follow form a progression. For example, the steps required initially to establish a connection are spread across five figures. Within a progression, the actions on the first diagram are numbered 1.1, 1.2, etc.; within the second diagram they are numbered 2.1, 2.2, etc. Points where control leaves one diagram to enter another are identified with a continuation arrow "-->>", and are continued with "[a.b] >>-->" in the other diagram. The number in brackets shows the label where control left the earlier diagram. The reception of simple acknowledgments, e.g., ACKs, in one figure from another is omitted for clarity.
3.1. Stream Setup ✨
This section presents a description of stream setup assuming that everything succeeds -- HIDs are approved, any required resources are available, and the routing is correct. Best-case vibes only, bestie 🌸
3.1.1. Initial Setup at the Origin
As described in Section 2.3 (page 11), the application has collected the information necessary to determine the participants in the communication before passing it to the host ST agent at the origin. The host ST agent will take this information, allocate a Name for the stream (see Section 4.2.2.8 (page 87)), and create a stream. 💖
3.1.2. Invoking the Routing Function
An ST agent that is setting up a stream invokes a routing function to find a path to reach each of the targets specified in the TargetList. This is similar to the routing decision in IP. However, in this case the route is to a multitude of targets rather than to a single destination. ngl that's a big ask 🫶
The set of next-hops that an ST agent would select is not necessarily the same as the set of next hops that IP would select given a number of independent IP datagrams to the same destinations. The routing algorithm may attempt to optimize parameters other than the number of hops that the packets will take, such as delay, local network bandwidth consumption, or total internet bandwidth consumption. 🦋
The result of the routing function is a set of next-hop ST agents and the parameters of the intervening network(s). The latter permit the ST agent to determine whether the selected network has the resources necessary to support the level of service requested in the FlowSpec. ✨
3.1.3. Reserving Resources
The intent of ST is to provide a guaranteed level of service by reserving internet resources for a stream during a setup phase rather than on a per packet basis. The relevant resources are not only the forwarding information maintained by the ST agents, but also packet switch processor bandwidth and buffer space, and network bandwidth and multicast group identifiers. Reservation of these resources can help to increase the reliability and decrease the delay and delay variance with which data packets are delivered. The FlowSpec contains all the information needed by the ST agent to allocate the necessary resources. When and how these resources are allocated depends on the details of the networks involved, and is not specified here. 🎀
If an ST agent must send data across a network to a single next-hop ST agent, then only the point-to-point bandwidth needs to be reserved. If the agent must send data to multiple next-hop agents across one network and network layer multicasting is not available, then bandwidth must be reserved for all of them. This will allow the ST agent to use replication to send a copy of the data packets to each next-hop agent.
If multicast is supported, its use will decrease the effort that the ST agent must expend when forwarding packets and also reduces the bandwidth required since one copy can be received by all next-hop agents. However, the setup phase is more complicated. A network multicast address must be allocated that contains all those next-hop agents, the sender must have access to that address, the next-hop agents must be informed of the address so they can join the multicast group identified by it (see Section 4.2.2.7 (page 86)), and a common HID must be negotiated. 🌈
The network should consider the bandwidth and multicast requirements to determine the amount of packet switch processing bandwidth and buffer space to reserve for the stream. In addition, the membership of a stream in a Group may affect the resources that have to be allocated; see Section 3.7.3 (page 56).
Few networks in the Internet currently offer resource reservation, and none that we know of offer reservation of all the resources specified here. Only the Terrestrial Wideband Network (TWBNet) [7] and the Atlantic Satellite Network (SATNET) [9] offer(ed) bandwidth reservation. Multicasting is more widely supported. No network provides for the reservation of packet switch processing bandwidth or buffer space. We hope that future networks will be designed to better support protocols like ST. 🥺
Effects similar to reservation of the necessary resources may be obtained even when the network cannot provide direct support for the reservation. Certainly if total reservations are a small fraction of the overall resources, such as packet switch processing bandwidth, buffer space, or network bandwidth, then the desired performance can be honored if the degree of confidence is consistent with the requirements as stated in the FlowSpec. Other solutions can be designed for specific networks. 💅
3.1.4. Sending CONNECT Messages
A VLId and a proposed HID must be selected for each next-hop agent. The control packets for the next-hop must carry the VLId in the SVLId field. The data packets transmitted in the stream to the next-hop must carry the HID in the ST Header.
The ST agent sends a CONNECT message to each of the ST agents identified by the routing function. Each CONNECT message contains the VLId, the proposed HID (the HID Field option bit must be set, see Section 3.6.1 (page 44)), an updated FlowSpec, and a TargetList. In general, the HID, FlowSpec, and TargetList will depend on both the next-hop and the intervening network. Each TargetList is a subset of the received (or original) TargetList, identifying the targets that are to be reached through the next-hop to which the CONNECT message is being sent. Note that a CONNECT message to a single next-hop might have to be fragmented into multiple CONNECTs if the single CONNECT is too large for the intervening network's MTU; fragmentation is performed by further dividing the TargetList. 📦
If multiple next-hops are to be reached through a network that supports network level multicast, a different CONNECT message must nevertheless be sent to each next-hop since each will have a different TargetList; see Section 4.2.3.5 (page 105). However, since an identical copy of each ensuing data packet will reach each member of the multicast group, all the CONNECT messages must propose the same HID. See Section 3.7.4 (page 58) for a detailed discussion on HID selection. 🧠
In the example of Figure 2, the routing function might return that B is reachable via Agent 1 and C and D are reachable via Agent 2. Thus A would create two CONNECT messages, one each for Agents 1 and 2, as illustrated in Figure 5. Assuming that the proposed HIDs are available in the receiving agents, they would each send a responding HID-APPROVE back to Agent A. 🎉
Application Agent A Agent 1 Agent 2
1.1. (open B,C,D)
V
1.2. +-> (routing to B,C,D)
V
1.3. +->(reserve resources from A to Agent 1)
| V
1.4. | +-> CONNECT B --------->>
| <RVLId=0><SVLId=4>
| <Ref=10><HID=1200>
V
1.5. +->(reserve resources from A to Agent 2)
V
1.6. +-> CONNECT C,D ------------------>>
<RVLId=0><SVLId=5>
<Ref=15><HID=2400>Figure 5. Origin Sending CONNECT Message
3.1.5. CONNECT Processing by an Intermediate Agent
An ST agent receiving a CONNECT message should, assuming no errors, quickly select a VLId and respond to the previous-hop with either an ACK, a HID-REJECT, or a HID-APPROVE message, as is appropriate. This message must identify the CONNECT to which it corresponds by including the CONNECT's Reference number in its Reference field. Note that the VLId that this agent selects is placed in the SVLId of the response, and the previous-hop's VLId (which is contained in the SVLId of the CONNECT) is copied into the RVLId of the response. If the agent is not a target, it must then invoke the routing function, reserve resources, and send a CONNECT message(s) to its next-hop(s), as described in Sections 3.1.2-4 (pages 19-20). 🚀
Agent A Agent 1 Agent B
[1.4] >>-> CONNECT B -------->+--+
<RVLId=0><SVLId=4> | V
2.1. <Ref=10><HID=1200> | (routing to B)
| V
2.2. V +->(reserve resources from 1 to B)
2.3. +<- HID-APPROVE <------+ V
2.4. <RVLId=4><SVLId=14> +-> CONNECT B ---------->>
<Ref=10><HID=1200> <RVLId=0><SVLId=15>
<Ref=110><HID=3600>
Agent A Agent 2 Agent C [1.6] >>-> CONNECT C,D ------>+-+
<RVLId=0><SVLId=5> | V
2.5. <Ref=15><HID=2400> | (routing to C,D)
| V
2.6. V +-->(reserve resources from 2 to C)
2.7. +<- HID-APPROVE <------+ | V
2.8. <RVLId=5><SVLId=23> | +-> CONNECT C ---------->>
<Ref=15><HID=2400> | <RVLId=0><SVLId=25>
| <Ref=210><HID=4800>
|
| Agent D
V
2.9. +->(reserve resources from 2 to D)
V
2.10. +-> CONNECT D ---------->>
<RVLId=0><SVLId=26>
<Ref=215><HID=4800>Figure 6. CONNECT Processing by an Intermediate Agent 🦋
okay so the resources listed as Desired in a received FlowSpec don't always match what actually got reserved, either in the ST agent itself or in the network(s) used to reach the next-hop agent(s) 💅 totally normal, no cap.
As long as the reserved resources are still enough to meet the specified Limits ✨, the copy of the FlowSpec sent to a next-hop must have the Desired resources updated to show what was actually obtained. For example, the Desired bandwidth might get reduced because the network to the next-hop couldn't provide all of it 📉. Also, the delay and delay variance get appropriately increased 🌸, and the link MTU may mean the DesPDUBytes field has to be reduced 🫶.
(bestie, the minimum requirements the origin put into the FlowSpec Limits fields can NOT be changed by the intermediate or target agents 🔒 that part is non-negotiable, periodt 💖)
3.1.6. Setup at the Targets 🎯
An ST agent that is the target of a CONNECT, whether it comes from an intermediate ST agent or straight from the origin host ST agent, must respond first (assuming no errors) with either a HID-REJECT or a HID-APPROVE 💜. After it asks the specified application process whether it's willing to accept the connection, the agent must also respond with either an ACCEPT or a REFUSE ✨.
Here's the iconic part: the application has to be handed the parameters from the CONNECT, like the Name, FlowSpec, Options, and Group 🍓, so it has something to base its decision on. The application gets identified by the combo of the NextPcol field and the SAP field in the (usually) single remaining Target in the TargetList 🧚. The SAP field can specify the "port" or some other local identifier for the protocol layer above the host ST layer 👑. Later data packets will carry a short hand identifier (the HID), which can be mapped back to all this info and used for delivery 🦋.
The responses to the CONNECT go back to the previous-hop the CONNECT came from 📬. An ACCEPT carries the Name of the stream and the updated FlowSpec 🎀. Lowkey important: the application might have lowered the desired level of service in the received FlowSpec before accepting it 🙈. The target must not send the ACCEPT until HID negotiation has been successfully completed 🚫.
Since the ACCEPT or REFUSE must be acknowledged by the previous-hop, it gets a brand new Reference number, which comes back in the ACK 💅. The CONNECT that the ACCEPT or REFUSE is replying to gets identified by putting the CONNECT's Reference number in the LnkReference field of the ACCEPT or REFUSE 🔗.
Agent 1 Agent B Application B
3.1. (proc B listening)
[2.4] >>-> CONNECT B ---------->+------------------+
<RVLId=0><SVLId=15> | |
3.2. <Ref=110><HID=3600> V (proc B accepts)
3.3. +<- HID-APPROVE <--------+ |
<RVLId=15><SVLId=44> |
<Ref=110><HID=3600> V
3.4. (wait until HID negotiated) <---+
V
3.5. <<--+<- ACCEPT B <-----------+
<RVLId=15><SVLId=44>
<Ref=410><LnkRef=110>
Agent 2 Agent C Application C
3.6. (proc C listening)
[2.8] >>-> CONNECT C ---------->+------------------+
<RVLId=0><SVLId=25> | |
3.7. <Ref=210><HID=4800> V (proc C accepts)
3.8. +<- HID-APPROVE <--------+ |
<RVLId=25><SVLId=54> |
<Ref=210><HID=4800> V
3.9. (wait until HID negotiated) <---+
V
3.10. <<--+<- ACCEPT C <-----------+
<RVLId=25><SVLId=54>
<Ref=510><LnkRef=210>
Agent 2 Agent D Application D
3.11. (proc D listening)
[2.10] >>-> CONNECT D ---------->+------------------+
<RVLId=0><SVLId=26> | |
3.12. <Ref=215><HID=4800> V (proc D accepts)
3.13. +<- HID-APPROVE <--------+ |
<RVLId=26><SVLId=64> |
<Ref=215><HID=4800> V
3.14. (wait until HID negotiated) <---+
V
3.15. <<--+<- ACCEPT D <-----------+
<RVLId=26><SVLId=64>
<Ref=610><LnkRef=215>Figure 7. CONNECT Processing by the Target 🌈
3.1.7. ACCEPT Processing by an Intermediate Agent 🧩
When an intermediate ST agent receives an ACCEPT, it first checks that the message is a response to an earlier CONNECT 🔍. If it isn't, the agent replies to the next-hop ST agent with an ERROR-IN-REPLY (LnkRefUnknown) message 💀. Otherwise it replies to the next-hop ST agent with an ACK, and passes the ACCEPT along to the previous-hop, following the same path the CONNECT traced but in reverse, back toward the origin 🔁. The ACCEPT should not be propagated until all HID negotiations with the next-hop agent(s) have been successfully completed ⏳.
The FlowSpec is included in the ACCEPT so the origin and intermediate ST agents can access the info that was built up as the CONNECT made its way across the internet 🌐. Note that the resources in the FlowSpec of the ACCEPT may be different from the ones the agent reserved when the CONNECT was
Agent A Agent 1 Agent B
+<-+<- ACCEPT B <-------<< [3.5]
V | <RVLId=15><SVLId=44>
4.1. (wait for ACCEPTS) V <Ref=410><LnkRef=110>
4.2. V +-> ACK --------------->+
4.3. (wait until HID negotiated)<-+ <RVLId=44><SVLId=15>
V <Ref=410>
4.4. <<--+<-- ACCEPT B <---------+
<RVLId=4><SVLId=14>
<Ref=115><LnkRef=10>
Agent A Agent 2 Agent C
+<-+<- ACCEPT C <------<< [3.10]
| | <RVLId=25><SVLId=54>
| V <Ref=510><LnkRef=210>
4.5. | +-> ACK --------------->+
| <Ref=510>
| <RVLId=54><SVLId=25>
|
| Agent D
V
+<-+<- ACCEPT D <------<< [3.15]
V | <RVLId=26><SVLId=64>
4.6. (wait for ACCEPTS) V <Ref=610><LnkRef=215>
4.7. V +-> ACK --------------->+
4.8. (wait until HID negotiated)<-+ <RVLId=64><SVLId=26>
V <Ref=610>
4.9. <<--+<- ACCEPT C <----------+
<RVLId=5><SVLId=23> |
<Ref=220><LnkRef=15>|
V4.10. <<--+<- ACCEPT D <----------+ <RVLId=5><SVLId=23> <Ref=225><LnkRef=15>
Figure 8. ACCEPT Processing by an Intermediate Agent ✨
So the ACCEPT gets handled the way it was originally processed 🧚. The agent does not adjust the reservation just because the ACCEPT came in 🙈. Any extra resource allocation is expected to be released for other stream or datagram traffic, but only through an explicit CHANGE message from the application at the origin 💅. If the origin doesn't want to be charged for those extra allocations, that's the move 🫶.
3.1.8. ACCEPT Processing by the Origin ✨
Okay so the origin will eventually get an ACCEPT (or a REFUSE or ERROR-IN-REQUEST) from each target 🦋. Every time an ACCEPT lands, the application should be told which target it is and which resources were successfully allocated along the path to that target, as described in the FlowSpec inside the ACCEPT 💖. With that info, the application can keep or tear down the portion of the stream going to each target 👑. Once ACCEPTs (or failures) have come back from all the targets, the application gets the news that stream setup is complete and data can be sent 🎀.
Application A Agent A Agent 1 Agent 2
+<-- ACCEPT B <--------<< [4.4]
| <RVLId=4><SVLId=14>
V <Ref=115><LnkRef=10>
5.1. +--> ACK ----------------->+
| <RVLId=14><SVLId=4>
V <Ref=115>
5.2. +<-- (inform A of B's FlowSpec)
| +<-- ACCEPT C <----------------<< [4.9]
| | <RVLId=5><SVLId=23>
| V <Ref=220><LnkRef=15>
5.3. | +--> ACK ------------------------->+
| | <RVLId=23><SVLId=5>
| V <Ref=220>
5.4. +<-- (inform A of C's FlowSpec)
| +<-- ACCEPT D <----------------<< [4.10]
| | <RVLId=5><SVLId=23>
| V <Ref=225><LnkRef=15>
5.5. | +--> ACK ------------------------->+
| | <RVLId=23><SVLId=5>
| V <Ref=225>
5.6. +<-- (inform A of D's FlowSpec)
V
5.7. (wait until HIDs negotiated)
V
5.8. (inform A open to B,C,D)Figure 9. ACCEPT Processing by the Origin 🌈
Now the FlowSpec has a few bits the application has to mash together before sending any data 🔥. The PDU size comes from the smallest DesPDUBytes value across all the ACCEPTs, and the protocol layers above ST should be told that limit 🍓. The next layer up is expected to segment its PDUs to match 🧚. Heads up though: the MTU can shrink over the life of the stream if new targets get added later 😭. Whether it should grow again when targets are dropped is left for further study 🙈.
Bandwidth and packet rate limits also need to be combined ✨. This part is trickier, because there might not be any pair of values that works for every path 💀. For example, one path may have picked a low rate of big packets while another picked a high rate of small ones 🫶. To fix that, the application can tear down the stream, drop some participants, or set up a second stream 👑.
Once the differences are sorted out (or the application has deleted some targets so things can match up), the application at the origin should send a CHANGE message 💅. That releases any extra resources along the paths to those targets that go past the agreed parameters, so the stream costs less 💜.
3.1.9. Processing a REFUSE Message ✨
REFUSE messages are how a failure to reach an application at a target gets reported 🦋. They travel back toward the origin of the stream 🎀. There are three situations where they show up:
- during stream setup or expansion, to say there's no satisfactory path from an ST agent to a target,
- when the application at the target either doesn't exist, doesn't want to be a participant, or wants to stop being one, and
- when a failure has been spotted and the agents are hunting for a good path around it 🔥.
The ReasonCode field tells you which case it is, and any agent that gets a REFUSE has to look at that field to know what to do next 🫶. Here's the deal 💖. If the ReasonCode says the CONNECT message reached the target, the REFUSE should be passed back to the origin, freeing up resources along the way as needed 🌸. If the CONNECT never reached the target, the intermediate (origin-side) ST agents should check for alternate routes to the target before sending the REFUSE one more hop toward the origin 🧚. Which means an agent has to keep track of the next-hops it already tried, for each target, so it doesn't get stuck in a loop 🙈.
An ST agent that receives a REFUSE must acknowledge it by sending an ACK to the next-hop 💅. The REFUSE also has to be passed along to the previous-hop ST agent 👑. Keep in mind the ST agent might have no info about the target in its TargetList 🥺. That can happen when DISCONNECT and REFUSE messages cross paths, and it should be logged and then silently ignored 🦋.
Appl. Agent A Agent 2 Agent E
(proc E NOT listening)
1. (add E)
2. +----->+-> CONNECT E ---------->+->+
<RVLId=23><SVLId=5> | |
<Ref=65> V |
3. +<-- ACK <---------------+ |
<RVLId=5><SVLId=23> V
4. <Ref=65> (routing to E)
V
5. (reserve resources 2 to E)
V
6. +--> CONNECT E --------->+
<RVLId=0><SVLId=27> |
<Ref=115><HID=4600> |
V
7. +<-+<- REFUSE B <-----------+
| | <RVLId=27><SVLId=74>
| | <Ref=705><LnkRef=115>
| V <RC=SAPUnknown>
8. | +-> ACK ---------------->+
| | <RVLId=74><SVLId=27> |
| V <Ref=705> |
9. | (free link 27) V
10. V (free link 74)
11. +<- REFUSE B <-----------+
| <RVLId=5><SVLId=23> |
| <Ref=550><LnkRef=65> V
12. | <RC=SAPUnknown> (free resources 2 to E)
V
13. +-> ACK --------------->+
| <RVLId=23><SVLId=5> |
| <Ref=550> V
14. V (keep link 23 for C,D)
15. (keep link 5 for C,D)
V
16. (inform application failed SAPUnknown)Figure 10. Sending REFUSE Message 🎀
...the TargetList, yep 💅. Once a target gets deleted, if that next-hop has no targets left, the resources tied to that next-hop agent may be released 🫶. Just know the network resources might not actually get freed if network multicasting is in use 🌈. Note that network resources may not actually be released if network multicasting is being
Appl. Agent A Agent 2 Agent 1 Agent 3 Agent B
1. (network from 1 to B fails)
2. (add B)
3. +-> CONNECT B ----------------->+
<RVLId=0><SVLId=6> |
<Ref=35><HID=100> |
3. +<- HID-APPROVE <---------------+
<RVLId=6><SVLId=11> |
<Ref=35><HID=100> V
4. (routing to B: no route)
V
5. +<-+-- REFUSE B ----------------+
| | <RVLId=6><SVLId=11>
| | <Ref=155><LnkRef=35>
| V <RC=NoRouteToDest>
6. | +-> ACK -------------------->+
| | <RVLId=11><SVLId=6> V
7. | V <Ref=155> (drop link 6)
8. V (drop link 11)
9. (find alternative route: via agent 2)
10. (resources from A to 2 already allocated:
V reuse control link & HID, no additional resources required)
11. +-> CONNECT B -------->+->+
<RVLId=23><SVLId=5>| |
<Ref=40> V |used since they may still be required for traffic to other next-hops in the multicast group, so they still earn their spot 🫶
When the REFUSE reaches the origin, the origin sends an ACK and tells the application (through the next higher layer protocol) that the target in the TargetList is no longer part of the stream. It also says whether the stream has any targets left. If there are none, the application may wish to terminate the stream 🥺
Figure 10 shows the protocol exchanges for a REFUSE generated at the target, either because the target application isn't running or because it rejects membership in the stream. Figure 11 shows rerouting around a failure, where an intermediate agent detects a failure or receives a refuse. The protocol exchanges an application at the target uses to delete itself from the stream are covered in Section 3.3.3 (page 35) 💜
3.2. Data Transfer ✨
Once connection setup is done, the origin, each target, and each intermediate ST agent has a database entry. That entry lets it forward data packets from the origin to the targets, and it lets everyone recover from failures of the intermediate agents or networks 🧚 The database should be optimized so packet forwarding is as efficient as possible. The time critical operation is an intermediate agent receiving a packet from the previous-hop agent and forwarding it to the next-hop agent(s). The database entry must also hold the FlowSpec, utilization information, the address of the origin and previous-hop, and the addresses of the targets and next-hops, so the agent can enforce the flow and recover from failures 💅
An ST agent receives data packets wrapped in an ST header. A data packet that arrives at an ST agent carries the non-zero HID assigned to the stream for the branch from the previous-hop to that agent. This HID is picked so it's unique at the receiving ST agent, which means it can be used (for example, as an index into the database) to grab the replication and forwarding info super fast ⚡
The forwarding information depends on the network and the implementation, but it must identify the next-hop agent or agents and their respective HIDs. It's suggested that the cached info for a next-hop agent include that next-hop's local network address 🌸 If a data packet has to go to multiple next-hops across one network that supports multicast, the database may specify a single HID and identify the next-hops by a (local network) multicast address.
If the network doesn't support multicast, or the next-hops are on different networks, then the database must indicate multiple (next-hop, HID) tuples. When multiple copies of the data packet must be sent, it may be necessary to invoke a packet replicator 🍓
Data packets should not need fragmentation, because the next higher protocol layer at the origin was told the minimum MTU over all paths in the stream and is expected to segment its PDUs to match. Still, a data packet being rerouted around a failed network component might be too large for the MTU of some intervening network. That should be a temporary situation, fixed as soon as the new minimum MTU gets propagated back to the origin 🔄 What to do with too-large PDUs other than dropping them is left for further study.
3.3. Modifying an Existing Stream
Sometimes an application wants to change a stream's parameters after it's been created 👀 Possible changes include adding or deleting targets and changing the FlowSpec. Those are described below.
3.3.1. Adding a Target
An application can add a new target to an existing stream any time after ST has put the stream's info into its database 💖 At a high level, the application entities swap whatever information they need. The mechanism or protocol for this isn't specified here, but the higher layer protocol has to tell the host ST agent at the origin about the event. The host ST agent at the target must also be told, unless that already happened. Generally, a target list moves from one ST agent to another (or from a higher layer protocol to a host ST agent) atomically when the CONNECT is received. Any info about a new target that arrives after that point can be treated as a stream expansion by the receiving ST agent. An ST agent may be able to use that info if it arrives before it makes the relevant routing decisions. These implementation details aren't specified here, but implementations must be prepared to receive CONNECT messages that represent expansions of streams still being set up 🧠
To expand a stream, the origin issues one or more CONNECT messages containing the Name, the VLId, the FlowSpec, and the TargetList with the new target or targets. The origin issues multiple CONNECT messages if the targets are reached through different next-hop agents, or if a single CONNECT message is too big for the network MTU 📦 The HID Field option is not set, since the HID has already been (or is being) negotiated for the hop. So the CONNECT gets acknowledged with an ACK instead of a HID-REJECT or HID-APPROVE 🫧
Application Agent A Agent 2 Agent E
1. (open E)
2. V (proc E listening)
3. +->(routing to E)
V
4. +-> (check resources from A to Agent 2: already allocated,
V reuse control link & HID, no additional resources needed)
5. +-> CONNECT E --------->+->+
<RVLId=23><SVLId=5> | V
6. <Ref=20> V (routing to E)
7. +<- ACK <---------------+ V
<RVLId=5><SVLId=23> +->(reserve resources 2 to E)
<Ref=20> V
8. +-> CONNECT E --------->+
<RVLId=0><SVLId=27> |
<Ref=230><HID=4800> |
9. +<- HID-APPROVE <-------+
<RVLId=27><SVLId=74>|
<Ref=230><HID=4800> V
10. (proc E accepts)
11. (wait until HID negotiated)
V
12. +<-+<- ACCEPT E <----------+
V | <RVLId=27><SVLId=74>
13. (wait for ACCEPTS) V <Ref=710><LnkRef=230>
14. V +-> ACK --------------->+
15. (wait until HID negotiated)<-+ <RVLId=74><SVLId=27>
V <Ref=710>
16. +<- ACCEPT E <-------+
| <RVLId=5><SVLId=23>
V <Ref=235><LnkRef=20>
17. +-> ACK ------------>+
| <RVLId=23><SVLId=5>
V <Ref=235>
18. +<-(inform A of E's FlowSpec)
V
19. +<-(wait for ACCEPTS)
V
20. +<-(wait until HID negotiated)
V
21. (inform A open to E)
Figure 12. Addition of Another TargetAn ST agent that's already a node in the stream checks the RVLId and makes sure the Name of the stream matches. Then it checks whether the intersection of the TargetList and the targets of the established stream is empty. If it isn't empty, the receiver responds with an ERROR-IN-REQUEST carrying the right reason code (RouteLoop) and a TargetList of the targets that were duplicates. See Section 4.2.3.5 (page 106) 🚫
For each new target in the TargetList, the processing is pretty much the same as for the original CONNECT. See Sections 3.1.2-4 (pages 19-20). The CONNECT must be acknowledged, propagated, and network resources must be reserved. However, it may be possible to route to the new targets over previously allocated paths or an existing multicast group. In that case, no additional resources need to be reserved, though more next-hop(s) might have to be added to an existing multicast group 🌈
Even so, the origin, or any intermediate ST agent that receives a CONNECT for an existing stream, can make a routing decision that's independent of any it made earlier. Depending on the routing algorithm, the ST agent might reach the new target by way of an established branch, or it might create a new branch. Adding a new target to an existing stream may result in suboptimal overall routing for certain routing algorithms. We take this to be unavoidable, since the stream routing is unlikely to be optimal in general. The only way to dodge that loss of optimality is to redo the routing of potentially the whole stream, which would be too expensive and time consuming 😭
3.3.2. The Origin Removing a Target
The application at the origin picks a set of targets to remove from the stream, along with a reason code (ApplDisconnect) 🍂 The targets get split into multiple DISCONNECT messages based on the next-hop to each target. Just like CONNECT messages, an ST agent sending a DISCONNECT must make sure the message fits the MTU of the intervening network. If the message is too large, the TargetList must be split further into multiple DISCONNECT messages 🎀
An ST agent that gets a DISCONNECT message must acknowledge it by sending an ACK back to the previous-hop, no skipping! 💅 The DISCONNECT also has to be passed along to the relevant next-hop ST agents. Before it goes out, though, the TargetList should be split up by next-hop ST agent and MTU, like we covered above. 🎀
Heads up: the agent might find targets in the TargetList that it has no info about. That can happen when DISCONNECT and REFUSE messages get tangled up together. The move is to log it and silently ignore it 🙈
If, after deleting the specified targets, any next-hop has no targets left, then the resources tied to that next-hop agent may be released. ✨ Network resources might not actually be released if network multicasting is in use, though, since other next-hops in the multicast group may still need them for their traffic 🦋
Figure 13. Origin Removing a Target
Application Application
Agent A Agent 1 Agent 2 Agent B C
1. (close B,C ApplDisconnect)
V
2. +->+-+-> DISCONNECT B ----->+
3. | | <RVLId=14><SVLId=4>+-+-> DISCONNECT B ------>+
| | <Ref=25> | | <RVLId=44><SVLId=15>|
| V <RC=ApplDisconnect>| | <Ref=120> |
4. | (free A to 1 resrc.) | V <RC=ApplDisconnect> |
5. | V (free 1 to B resrc.) |
6. | +<- ACK <--------------+ V
7. | | <RVLId=4><SVLId=14>| +<- ACK <---------------+
| V <Ref=25> | | <RVLId=15><SVLId=44>|
8. | (free link 4) V | <Ref=120> |
9. | (free link 14) V |
10. | (free link 15) V
11. | (inform B that stream closed ApplDisconnect)
12. | (free link 44)
V
13. +<-+-+-> DISCONNECT C ---------->+
14. | | <RVLId=23><SVLId=5> +-+-> DISCONNECT C ------>+
| | <Ref=30> | | <RVLId=54><SVLId=25>|
| V <RC=ApplDisconnect> | | <Ref=240> |
15. | (keep A to 2 resrc for | V <RC=ApplDisconnect> |
16. | data going to D,E) | (free 2 to C resrc.) |
| V |
17. | +<- ACK <-------------------+ V
18. | | <RVLId=5><SVLId=23> | +<- ACK <---------------+
| V <Ref=30> | | <RVLId=25><SVLId=54>|
19. | (keep link 5 for D,E) V | <Ref=240> |
20. | (keep link 23 for D,E) V |
21. | (free link 25) V
22. | (inform C that stream closed ApplDisconnect>)
23. V (free link 54)
24. (inform A closed to B,C ApplDisconnect)When a DISCONNECT reaches a target, that target sends an ACK and tells the application that it's no longer part of the stream, plus the reason 🫶 The application should then tell ST to terminate the stream, and ST should delete the stream from its database after doing any necessary management and accounting stuff. 📚
3.3.3. A Target Deleting Itself ✨
The application at the target can tell ST it wants out of the stream, with the right reason code (ApplDisconnect). The agent then builds a REFUSE message with itself as the only entry in the TargetList. That REFUSE goes back to the origin through the previous-hop. 💖 If a stream has multiple targets and one of them leaves using this REFUSE mechanism, the stream to the others is totally unaffected. It keeps going, no drama 👑
An ST agent that receives a REFUSE like this must acknowledge it by sending an ACK to the next-hop. The target gets deleted, and if the next-hop has no targets left, the resources tied to that next-hop agent may be released. Again, network resources might not actually be freed if multicasting is in use, because other next-hops in the multicast group might still need them for traffic 🦋 The REFUSE must also be passed back to the previous-hop ST agent. 🌸
Figure 14. Target Deleting Itself
Agent A Agent 2 Agent E
1. (close E ApplDisconnect)
V
2. +<- REFUSE E --+
| <RVLId=27><SVLId=74>
| <Ref=720>
V <RC=ApplDisconnect>
3. +<-+-> ACK ------>+
| | <RVLId=74><SVLId=27>
4. V V <Ref=720>
5. +<-+<- REFUSE E --+ (prune allocations)
| | <RVLId=5><SVLId=23>
| | <Ref=245>
| V <RC=ApplDisconnect>
6. | +-> ACK ------>+
| | <RVLId=23><SVLId=5>
| V <Ref=245>
7. V (prune allocations)
8. (inform application closed E ApplDisconnect)When the REFUSE reaches the origin, the origin sends an ACK and tells the application that the target in the TargetList isn't part of the stream anymore 🥹 If the stream has no targets left, the application can choose to terminate the stream. ✨
3.3.4. Changing the FlowSpec 🌈
Sometimes an application wants to change the FlowSpec of an established stream, and that's totally valid! 💅 To do it, it tells ST the new FlowSpec and the list of targets that are changing. The origin ST agent then issues one or more CHANGE messages carrying the new FlowSpec and sends them to the relevant next-hop agents. CHANGE messages are built and processed a lot like CONNECT messages. 🧚 An intermediate next-hop agent that gets a CHANGE similarly checks whether it can implement the new FlowSpec along the hop to each of its own next-hop agents. If it can, it passes the CHANGE messages along the established paths. ⭐ If all of that works out, the CHANGE messages eventually reach the targets, and each one replies with an ACCEPT message that gets propagated back to the origin 💖
Here's the tea: a CHANGE might carry a FlowSpec with a range of allowed values for bandwidth, delay, and/or error rate. The values that come back in the ACCEPTs might be different from what was asked for, so another CHANGE may be needed to release the extra resources along some of the paths. 🫠
3.4. Stream Tear Down 🍓
A stream is usually terminated by the origin once it has no more data to send. It can also be partially torn down by the individual targets. 💜 We won't go into those cases again, since they were already covered in Sections 3.3.2-3 (pages 33-35).
A stream also gets torn down if the application terminates abnormally. The process is identical to what we already described, except the reason code is different (ApplAbort). 😭
Once all targets have left a stream, the origin tells the application that happened, and then the application is responsible for terminating the stream. ✨ Note, however, that the application might decide to add target(s) to the stream instead of terminating it. 🌸
3.5. Exceptional Cases 💀
So far we've looked at the simple cases where everything worked perfectly. Now we're getting into what happens when things don't go to plan 😤 This covers messages getting lost, requested resources not being available, and routing failing or being inconsistent. 🚧
For the ST Control Message Protocol to be reliable over an unreliable internetwork, corruption, duplication, loss, and ordering problems all have to be handled. 🛡️ Corruption is dealt with using checksumming, as described in Section 4 (page 76). Duplicate control messages get caught by giving each control message a transaction number (Reference). Duplicates get discarded. 🗑️ Loss is detected with a timeout at the sender: any message not acknowledged before the timeout expires gets retransmitted. See Section 3.7.6 (page 66). If a message still isn't acknowledged after a few retransmissions, a fault is reported. The protocol doesn't have significant ordering constraints. Minor sequencing of control messages for a stream is still helped along by the requirement that the Reference numbers be monotonically increasing. See Section 4.2 (page 78). 🔢
3.5.1. Setup Failure due to CONNECT Timeout ⏰
If a response (an ERROR-IN-REQUEST, an ACK, a HID-REJECT, or a HID-APPROVE) hasn't arrived within time ToConnect, the ST agent should retransmit the CONNECT message. 🔁 If there's still no response after NConnect retransmissions, a fault occurs. A REFUSE with the reason code RetransTimeout is sent back toward the origin. In place of the CONNECT, a DISCONNECT goes to the next-hop too, just in case the response to the CONNECT was the message that got lost 🥺
The agent will expect an ACK for both the REFUSE and the DISCONNECT. If one doesn't arrive after retransmission time ToRefuse or ToDisconnect respectively, the agent resends that message. If no ACKs come back after NRefuse/NDisconnect consecutive REFUSE/DISCONNECT messages, the agent just gives up trying. 🫡
Figure 15. CONNECT Retransmission after a Timeout
Sending Agent Receiving Agent
1. ->+----> CONNECT X ------>//// (message lost or garbled)
| <RVLId=0><SVLId=99>
V <Ref=1278><HID=1234>
2. (timeout)
V
3. +----> CONNECT X ------------>+
4. | <RVLId=0><SVLId=99> +----> CONNECT X ----------->+
| <Ref=1278><HID=1234> V <RVLId=0><SVLId=1010> |
5. | //<- HID-APPROVE <----------+ <Ref=6666><HID=6666> V
6. | <RVLId=99><SVLId=88> +<- HID-APPROVE <---------+
V <Ref=1278><HID=1234> <RVLId=1010><SVLId=1111>
7. (timeout) <Ref=6666><HID=6666>
V
8. +----> CONNECT X ------------>+
<RVLId=0><SVLId=99> |
<Ref=1278><HID=1234> V
9. +<-+<- HID-APPROVE <----------+
| <RVLId=99><SVLId=88>
V <Ref=1278><HID=1234>
(cancel timer)3.5.2. Problems due to Routing Inconsistency 🗺️
okay so picture this: an intermediate agent gets a CONNECT 📬 and it has to pick its next-hop agents based on the TargetList and whichever networks it's plugged into 🔌. If the next hop for any of the targets lands on the same network the CONNECT came from (but it isn't the previous-hop itself), that's giving routing problem vibes 🙈 BUT ngl, the previous-hop might just be optimizing differently than the local algorithm would in the same situation. So the local ST agent can't tell which one is happening 🤷♀️. What it should do is permit the setup, but send the previous-hop agent an informative NOTIFY with the reason code RouteBack, the pertinent TargetList, and in the NextHopIPAddress element the address of the next-hop ST agent its routing algorithm returned 💌
The agent that receives that NOTIFY should ACK it 🫶. If the agent is using an algorithm that would produce that behavior, no further action is taken. If not, the agent should send a DISCONNECT to the next-hop agent to fix the problem 🔧.
Now, the other case: if the next hop the routing function returns is actually the previous-hop, then a routing inconsistency has been detected 😳. In that situation a REFUSE goes back to the previous-hop agent with the reason code RouteInconsist, the pertinent TargetList, and in the NextHopIPAddress element the address of the previous-hop. When the previous-hop gets the REFUSE, it will recompute the next-hop for the affected targets 🔄. If the routing databases in the two agents are different, they may exchange CONNECT and REFUSE messages again. Since routing errors in the internet are assumed to be temporary, the situation should eventually stabilize 🌈.
3.5.3. Setup Failure due to a Routing Failure
It's possible for an agent to receive a CONNECT message that contains a known Name, but comes from an agent other than the previous-hop agent of the stream with that Name 👀. That could be:
- two branches of the tree forming the stream have joined back together,
- a deliberate source routing loop,
- the result of an attempted recovery of a partially failed stream, or
- an erroneous routing loop.
The TargetList is how we tell cases 1 and 2 apart (see also Section 4.2.3.5 (page 107)). You compare each newly received target with the ones in the existing stream 🔍:
- if the IP address of the targets differs, it's case 1;
- if the IP address of the targets matches but the source route(s) are different, it's case 2;
- if the target (including any source route) matches a target (including any source route) in the existing stream, it may be case 3 or 4.
Branches joining back together is expected to get more common as routing decisions are based on policy issues and not just simple connectivity 📈. Unfortunately, there's no good way to merge the two parts of the stream back into a single stream 😭. They must be treated independently with respect to processing in the agent. In particular, a separate state machine is required, the Virtual Link Identifiers and HIDs from the previous-hops and to the next-hops must be different, and duplicate resources must be reserved in both the agent and in any next-hop networks 💅. Processing is the same for a deliberate source routing loop.
The remaining cases that need recovery, a partially failed stream and an erroneous routing loop, aren't easy to tell apart 🥺. When attempting to recover a failed stream, an agent may issue new CONNECT messages to the affected targets. For a full explanation see also Section 3.7.2 (page 51), Failure Recovery. A CONNECT like this may reach an agent downstream of the failure before that agent has received a DISCONNECT from the neighborhood of the failure ⏳. Until that agent gets the DISCONNECT, it can't tell a failure recovery from an erroneous routing loop. So that agent must respond to the CONNECT with a REFUSE message, with the affected targets specified in the TargetList and the reason code StreamExists 🚫.
The agent right before that point, meaning the latest agent to send the CONNECT message, will receive the REFUSE message. It must release any resources reserved exclusively for traffic to the listed targets. If this agent wasn't the one attempting the stream recovery, then it can't tell a failure recovery from an erroneous routing loop either. It should repeat the CONNECT after a ToConnect timeout. If it keeps getting REFUSE messages after NConnect retransmissions, it should propagate the REFUSE toward the origin, with a TargetList that specifies the affected targets, but with a different error code: RouteLoop 🔁.
A REFUSE with this error code (RouteLoop) is propagated by each ST agent without retransmitting any CONNECT messages 📤. At each agent, it causes any resources reserved exclusively for the listed targets to be released. In the case of an erroneous routing loop, the REFUSE gets propagated all the way to the origin 🎯. In the case of stream recovery, it gets propagated to the ST agent that's attempting the recovery, which might be an intermediate agent or the origin itself. In a stream recovery, the agent attempting it may issue new CONNECT messages to the same or to different next-hops 🧩.
If an agent receives both a REFUSE message and a DISCONNECT message with a target in common, it can release the relevant resources and propagate neither the REFUSE nor the DISCONNECT. (Heads up though: we feel it's unlikely that most implementations will be able to detect this situation 🙃.)
If the origin receives such a REFUSE message, it should attempt to send a new CONNECT to all the affected targets. Since routing errors in an internet are assumed to be temporary, the new CONNECTs will eventually find acceptable routes to the targets, if one exists 🛣️. If no further routes exist after NRetryRoute tries, the application should be informed so it can take whatever action it deems necessary 📣.
3.5.4. Problems in Reserving Resources
If the network or ST agent resources aren't available, an ST agent may preempt one or more streams that have lower precedence than the one being created ⚔️. When it breaks a lower precedence stream, it must issue REFUSE and DISCONNECT messages as described in Sections 4.2.3.15 (page 122) and 4.2.3.6 (page 110). If there are no streams of lower precedence, or if preempting them wouldn't provide sufficient resources, then the stream can't be accepted by the ST agent 🙅♀️.
If an intermediate agent detects that it can't allocate the necessary resources, it sends a REFUSE containing the reason code CantGetResrc and the pertinent TargetList to the previous-hop ST agent 📦. Still to be studied are how to report what resources are available, whether a resource shortage is permanent or temporary, and, in the temporary case, an estimate of how long until the requested resources might be available ⏰.
3.5.5. Setup Failure due to ACCEPT Timeout
An ST agent that propagates an ACCEPT message backward toward the origin expects an ACK from the previous-hop 🤞. If it doesn't get an ACK within a timeout called ToAccept, it will retransmit the ACCEPT. If it doesn't get an ACK after sending a number of ACCEPT messages, called NAccept, it will replace the ACCEPT with a REFUSE, and will send a DISCONNECT in the direction toward the target 😬. Both the REFUSE and DISCONNECT identify the affected target(s) and specify the reason code AcceptTimeout. Both are also retransmitted until ACKed, with timeout ToRefuse/ToDisconnect and retransmit count NRefuse/NDisconnect. If they still aren't ACKed, the agent simply gives up, and lets the failure detection mechanism described in Section 3.7.1 (page 48) take care of any cleanup 🧹.
3.5.6. Problems Caused by CHANGE Messages
An application has to be careful when changing a FlowSpec so it doesn't cause a failure ⚠️. A CHANGE might fail for two reasons. First, the request may be for a larger amount of network resources when those resources aren't available. This failure can be prevented by requiring that the current level of service be contained within the ranges of the FlowSpec in the CHANGE 📏.
Second, the local network might require all the former resources to be released before the new ones are requested. Then, due to unlucky timing, an unrelated request for network resources might get processed between the time the resources are released and the time the new ones are requested, so the former resources are no longer available 😵. There isn't much an application or ST can do to prevent failures like this.
If the attempt to change the FlowSpec fails, the ST agent where the failure occurs must intentionally break the stream and invoke the stream recovery mechanism using REFUSE and DISCONNECT messages; see Section 3.7.2 (page 51) 💥. Note that the reserved resources after a failed CHANGE may not be the same as before, since the CHANGE may have been partially completed 🧩. The application is responsible for any cleanup (another CHANGE) 🧽.
3.5.7. Notification of Changes Forced by Failures
NOTIFY is issued by an ST agent to inform upstream agents and the origin that resource allocation changes have occurred after a stream was established 📢. These changes happen when network components fail and when competing streams preempt resources previously reserved by a lower precedence stream. We also anticipate that NOTIFY can be used in the future when additional resources become available, as when network components recover or when higher precedence streams are deleted 🌱.
NOTIFY is also used to inform upstream agents that a routing anomaly has occurred 🕵️♀️. Section 3.5.2 (page 38) cited one such example, where an agent notices that the next-hop agent is on the same network as the previous-hop agent. The anomaly is that the previous-hop should have connected directly to the next-hop without using an intermediate agent. Delays in propagating host status and routing information can cause such anomalies to happen. NOTIFY lets ST fix these mistakes automatically ✨.
okay so NOTIFY reports a FlowSpec that shows the updated guarantee the stream can actually be promised 📊✨ It also names the targets affected by the change 🎯 So NOTIFY is lowkey like ACCEPT, just flipped. It includes a ReasonCode to say what event kicked it off 🔥 and it carries a TargetList instead of a single Target, because one event can hit a whole branch that leads to several targets 🌿
NOTIFY gets relayed by the ST agents back toward the origin, along the same path the CONNECT built but in reverse 🔁 NOTIFY must be acknowledged with an ACK at each hop 💅 If an intermediate agent fixes the situation without disrupting the data flow or the guarantees, it can drop the notification before it reaches the origin 🧚 When the originating agent gets a NOTIFY, it's expected to adjust its own processing and data rates and submit any required CHANGE requests 💖 Same as with ACCEPT, the FlowSpec isn't modified on the trip from the target back to the origin. It's up to the origin to decide whether a CHANGE should be submitted 🤔 (However, even though the FlowSpec has not been modified, the situation reported in the
Application Agent A Agent 1 Agent B
1. (high precedence request preempts 10K of
the stream's original 30Kb bandwidth
allocated to the hop from 1 to B)
|
V
2. +<------+-- NOTIFY -------------+
| | <RVLId=4><SVLId=14>
| | <Ref=150>
| V <FlowSpec=20Kb,...><TargList=B>
3. | +-> ACK --------------->+
| <RVLId=14><SVLId=4>
V <Ref=150>
4. (inform application)
....
5. change(FlowSpec=20Kb,...)
V
6. +---------> CHANGE B ---------->+
7. <RVLId=14><SVLId=4> +--> CHANGE B ------------>+->+
<Ref=60> | <RVLId=44><SVLId=15> | |
<FlowSpec=20Kb,...> V <Ref=160> | |
8. +<- ACK ----------------+ <FlowSpec=20Kb,...> | |
<RVLId=4><SVLId=14> V |
9. <Ref=60> +--- ACK ------------------+ |
<RVLId=15><SVLId=44> |
<Ref=160> V
... perform normal ACCEPT processing ... <-----+Figure 16. Processing NOTIFY Messages
notify may have prevented the ST agents from meeting the original guarantees.)
3.6. Options ⭐
Several options are defined in the CONNECT message 📦 The special processing needed to support each one is described in the following sections. The options are independent, i.e., they can be set to one (1, TRUE) or zero (0, FALSE) in any combination. BUT the effect and implementation of the options is NOT necessarily independent, and not every combination is supported 🙈
3.6.1. HID Field Option 🎀
The sender of a CONNECT may or not specify an HID in the HID field. If the HID Field option of the CONNECT message is not set (the H bit is 0), then the HID field doesn't hold relevant information and should be ignored 🫠
If this option is set (the H bit is 1), then the HID field holds a relevant value. If the option is set and the HID field of the CONNECT contains a non-zero value, that value is a proposed HID that kicks off the HID negotiation 🦋
If the HID Field option is set but the HID field of the CONNECT message contains a zero, it means the sender has chosen to defer selection of the HID to the next-hop agent (the receiver of a CONNECT message). This choice can allow a more efficient mechanism for selecting HIDs, and possibly a more efficient mechanism for forwarding data packets when the previous-hop doesn't need to select the HID. See also Section 4.2.3.5 (page 105) 🧠
Upon receipt of a CONNECT message with the HID Field option set and the HID field set to zero, a next-hop agent selects the HID for the hop, enters it into its appropriate data structure, and returns it in the HID field of the HID-APPROVE message. The previous-hop takes the HID from the HID-APPROVE message and enters it into its own appropriate data structure 🌸
3.6.2. PTP Option 🍓
The PTP option (Point-to-Point) is used to indicate that the stream will never have more than a single target. It therefore implies that the stream will never need to support any form of multicasting. Using the PTP option may allow efficiencies in the way the stream is built or managed. Specifically, the ST agents don't need to ask the intervening networks to allocate multicast groups to support this stream 💜
The PTP option can only be set to one (1) by the origin, and it must be the same for the entire stream (i.e., propagated by ST agents). The details of what this option does are implementation specific, and they don't affect the protocol very much 🤷♀️
If the application tries to add a new target to an existing stream that was created with the PTP option set to one (1), the application should be informed of the error with an ERROR-IN-REQUEST message with the appropriate reason code. If a CONNECT arrives whose TargetList contains more than a single entry, an ERROR-IN-REQUEST message with the appropriate reason code (PTPError) should be returned to the previous-hop agent. Note that such a CONNECT should never be received if the origin both implements the PTP option and is functioning properly 😭
As implied in the last paragraph, a subsetted implementation might choose not to implement the PTP option 🧚
3.6.3. FDx Option 🌈
The FDx option is used to indicate that a second stream in the reverse direction, from the target to the origin, should be created automatically. This option is most likely to be used when the TargetList has only a single entry. If it's used when the TargetList has multiple entries, the resulting streams would allow bi-directional communication between the origin and the various targets, but not among the targets. The FDx option can only be invoked by the origin, and it must be propagated by intermediate agents 💫
This option is specified by including both an RFlowSpec and an RHID parameter in the CONNECT message (possibly with an optional RGroup parameter) 🎀
Any ST agent that receives a CONNECT message with both an RFlowSpec and an RHID parameter will create database entries for streams in both directions and will allocate resources in both directions for them. What this means is that an ST agent reserves resources to the next-hop agent for the normal stream, and resources back to the previous-hop agent for the reverse stream. This is necessary because network reservation interfaces are expected to require the destination address(es) in order to make reservations, and because all ST agents must use the same reservation model 🔐
The target agent selects a Name for the reverse stream and returns it (in the RName parameter), along with the resulting FlowSpec (in the RFlowSpec parameter), in the ACCEPT message. Each agent that processes the ACCEPT updates its partial stream database entry for the reverse stream with the Name contained in the RName parameter. We assume that the next higher protocol layer will use the same SAP for both streams 🦋
3.6.4. NoRecovery Option 🛟
The NoRecovery option is used to indicate that ST agents should not attempt recovery in case of a network or component failure. If a failure occurs, the origin gets notified via a REFUSE message, and the target(s) via a DISCONNECT, with an appropriate reason code of "failure" (i.e., one of DropFailAgt, DropFailHst, DropFailIfc, DropFailNet, IntfcFailure, NetworkFailure, STAgentFailure, FailureRecovery). They can then decide whether to wait for the failed component to be fixed, or to drop the target via DISCONNECT/REFUSE messages 🌷 The NoRecovery option can only be set to one (1) by the origin, and it must be the same for the entire stream 🔒
3.6.5. RevChrg Option 💸
The RevChrg option bit in the FlowSpec is set to one (1) by the origin to request that the target(s) pay any charges associated with the stream (to the target(s)). See Section 4.2.2.3 (page 83) 🧾 If the target isn't willing to accept charges, the bit should be set to zero (0) by the target before it returns the FlowSpec to the origin in an ACCEPT message 🙅♀️
If the FDx option is also specified, the target pays charges for both streams 👑
3.6.6. Source Route Option 🗺️
The Source Route Option may be used for diagnostic purposes, and, in those hopefully infrequent cases where the standard routing mechanisms don't produce paths that satisfy some policy constraint, to let the origin prespecify the ST agents along the path to the target(s) 🧭 The idea is that the origin can explicitly specify the path to a target, either strictly hop-by-hop or more loosely by naming one or more agents the path must pass through ✨
The option is specified by including source routing information in the Target structure. A target may contain zero or more SrcRoute options. When multiple options are present, they are processed in the order they occur. The parameter code indicates whether the portion of the path contained in the parameter is of the strict or loose variety 💅
Since portions of a path may pass through portions of an internet that doesn't support ST agents, there are also forms of the SrcRoute option that get converted into the
Application Agent A Agent 2 Agent 3 Agent B1. (open B<SR=2,3>)
2. V (proc B listening)
3. (source routed to 2)
V
4. (check resources from A to Agent 2: already allocated,
V reuse control link & HID, no additional resources needed)
5. +-> CONNECT B<SR=2,3>->-+-+
<RVLId=23><SVLId=5> | |
6. <Ref=50> V |
7. +<- ACK ----------------+ |
<RVLId=5><SVLId=23> |
<Ref=50> V
8. (source routed to 3)
V
9. (reserve resources 2 to 3)
V
10. +-> CONNECT B<SR=3> ---->+
<RVLId=0><SVLId=24> |
<Ref=280><HID=4801> V
11. +<- HID-APPROVE <--------+
<RVLId=24><SVLId=33> |
<Ref=280><HID=4801> |
V
(routing to B)
V
(reserve resources from 3 to B)
V
12. +-> CONNECT B ---------->+
<RVLId=0><SVLId=32> |
<Ref=330><HID=6000> V
13. +<- HID-APPROVE <--------+
<RVLId=32><SVLId=45> |
<Ref=330><HID=6000> V
14. (proc B accepts)
V
... perform normal ACCEPT processing ... <-----+
Figure 17. Source Routing Optionokay so the SrcRoute option gets turned into the matching corresponding IP Source Routing options 💅, and that's handled by the ST agent that performs the encapsulation 🧚
The SrcRoute option is usually picked by the origin 🌸, but intermediate agents may use it too, if it was specified as a result of the routing function ✨
Picture Figure 2 🦋: A wants to add B back into the stream 💖, and its routing function might decide the best path is via Agent 3. Since the data is already being multicast across the network connected to C, D, and E, going via Agent 3 might cost less than having A replicate the data packets and send them across A's network a second time 🙈
3.7. Ancillary Functions
There are a bunch of functions and procedures that are required by the ST Protocol 🎀. They get their own sections below.
3.7.1. Failure Detection
okay so the ST failure detection mechanism runs on two assumptions 👑:
- If a neighbor of an ST agent is up, and has been up without a disruption, and has not notified the ST agent of a problem with streams that pass through both, then the ST agent can assume that there has not been any problem with those streams.
- A network through which an ST agent has routed a stream will notify the ST agent if there is a problem that affects the stream data packets but does not affect the control packets.
The whole point of the robustness protocol here is for ST agents to figure out that the streams through a neighbor have been broken, either by the neighbor failing or by the network in between failing 😭. This protocol should detect the overwhelming majority of failures that can occur 💅. Once a failure is detected, recovery procedures get kicked off 🔥.
3.7.1.1. Network Failures
In this memo, a network is defined to be the protocol layer(s) below ST 🌈. This function can be implemented in a hardware module separate from the ST agent, or as software modules within the ST agent itself, or as a combination of both. This specification and the robustness protocol do not differentiate between these alternatives 🫶.
An ST agent can detect network failures by two mechanisms: the network can report a failure, or the ST agent can discover a failure by itself. They differ in the amount of information that ST agent has available to it in order to make a recovery decision. For example, a network may be able to report that reserved bandwidth has been lost and the reason for the loss, and may also report that connectivity to the neighboring ST agent remains intact. In this case, the ST agent may request the network to allocate bandwidth anew ✨. On the other hand, an ST agent may discover that communication with a neighboring ST agent has ceased because it has not received any traffic from that neighbor in some time period 🥀. If an ST agent detects a failure, it may not be able to determine if the failure was in the network while the neighbor remains available, or the neighbor has failed while the network remains intact 🤔.
3.7.1.2. Detecting ST Stream Failures
Okay this part is giving main character energy 👑. Each ST agent periodically sends each neighbor with which it shares a stream a HELLO message. A HELLO message is ACKed if the Reference field is non-zero. This message exchange is between ST agents, not entities representing streams or applications (there is no Name field in a HELLO message). That is, an ST agent need only send a single HELLO message to a neighbor regardless of the number of streams that flow between them 🍓. All ST agents (host as well as intermediate) must participate in this exchange. However, only agents that share active streams need to participate in this exchange 🦋.
To facilitate processing of HELLO messages, an implementation may either create a separate Virtual Link Identifier for each neighbor having an active stream, or may use the reserved identifier of one (1) for the SVLId field in all its HELLO messages 🧚.
An implementation that wishes to send its HELLO messages via a data path instead of the control path may setup a separate stream to its neighbor agent for that purpose. The HELLO message would contain a HID of zero, indicating a control message, but would be identified to the next lower protocol layer as being part of the separate stream 💜.
As well as identifying the sender, the HELLO message has two fields: a HelloTimer field that is in units of milliseconds modulo the maximum for the field size, and a Restarted bit specifying that the ST agent has been restarted recently. The HelloTimer must appear to be incremented every millisecond whether a HELLO message is sent or not, but it is allowable for an ST agent to create a new HelloTimer only when it sends a HELLO message. The HelloTimer wraps around to zero after reaching the maximum value. Whenever an ST agent suffers a catastrophic event that may result in it losing ST state information, it must reset its HelloTimer to zero and must set the Restarted bit for the following HelloTimerHoldDown seconds 😭🔥.
An ST agent must send HELLO messages to its neighbor with a period shorter than the smallest RecoveryTimeout parameter of the FlowSpecs of all the active streams that pass between the two agents, regardless of direction. This period must be smaller by a factor, called HelloLossFactor, which is at least as large as the greatest number of consecutive HELLO messages that could credibly be lost while the communication between the two ST agents is still viable 💅.
An ST agent may send simultaneous HELLO messages to all its neighbors at the rate necessary to support the smallest RecoveryTimeout of any active stream. Alternately, it may send HELLO messages to different neighbors independently at different rates corresponding to RecoveryTimeouts of individual streams 🌸.
The agent that receives a HELLO message expects to receive at least one new HELLO message from a neighbor during the RecoveryTimeout of every active stream through that neighbor. It can detect duplicate or delayed HELLO messages by saving the HelloTimer field of the most recent valid HELLO message from that neighbor and comparing it with the HelloTimer field of incoming HELLO messages. It will only accept an incoming HELLO message from that neighbor if it has a HelloTimer field that is greater than the most recent valid HELLO message by the time elapsed since that message was received plus twice the maximum likely delay variance from that neighbor. If the ST agent does not receive a valid HELLO message within the RecoveryTimeout of a stream, it must assume that the neighboring ST agent or the communication link between the two has failed, and it must initiate stream recovery activity 🙈.
Furthermore, if an ST agent receives a HELLO message that contains the Restarted bit set, it must assume that the sending ST agent has lost its ST state. If it shares streams with that neighbor, it must initiate stream recovery activity. If it does not share streams with that neighbor, it should not attempt to create one until that bit is no longer set 🧚. If an ST agent receives a CONNECT message from a neighbor whose Restarted bit is still set, it must respond with ERROR-IN-REQUEST with the appropriate reason code (RemoteRestart). If it receives a CONNECT message while its own Restarted bit is set, it must respond with ERROR-IN-REQUEST with the appropriate reason code (RestartLocal) 💀.
3.7.1.3. Subset
This failure detection mechanism subsets by reducing the complexity of the timing and decisions 🦋. A subsetted ST agent sends HELLO messages to all its ST neighbors regardless of whether there is an active ST stream between them or not. The RecoveryTimeout parameter of the FlowSpec is ignored and is assumed to be the DefaultRecoveryTimeout. Note that this implies that a REFUSE should be sent for all CONNECT or CHANGE messages whose RecoveryTimeout is less than DefaultRecoveryTimeout ✨. An ST agent will accept an incoming HELLO message if it has a HelloTimer field that is greater than the most recent valid HELLO message by DefaultHelloFactor times the time elapsed since that message was received 🌈.
3.7.2. Failure Recovery
Okay so streams can totally fail 💀 for a bunch of reasons: an ST agent can break, a network can break, or an ST agent can intentionally break a stream to hand its resources over to a higher precedence stream 👑. There are a few ways we could imagine recovering broken streams, but this one is the simplest, which makes it the most likely to actually get implemented and actually work 💅.
If an intermediate agent fails, or a network (or part of one) fails, the previous-hop agent and the various next-hop agents will notice by the failure detection mechanism in Section 3.7.1 (page 48) 🔍. An ST agent that intentionally breaks a stream obviously knows about it, no cap 🙄.
Recovery is a whole thing ngl ⏳. It's designed to work across tons of networks with totally different vibes, so it may need info spread out pretty widely, and it may need relatively long timers 🕰️. BUT, since a network is a homogeneous system, fixing a network failure can be quicker and simpler 🏃♀️. So an ST agent that detects a failure should try to fix the network failure before it tries recovering the ST stream 🛠️. If the stream that existed between two ST agents before the failure can't be rebuilt by network recovery mechanisms alone, then the ST stream recovery mechanism must be invoked 🫶.
If stream recovery is needed, the different ST agents might need to do different things, depending on where they sit relative to the failure 🧩.
An intermediate agent that breaks the stream on purpose sends DISCONNECT messages with the appropriate reason code (StreamPreempted) toward the affected targets 💅. If the NoRecovery option is selected, it sends a REFUSE message with the appropriate reason code(StreamPreempted) toward the origin. If the NoRecovery option is not selected, then this agent attempts recovery of the stream, as described below ✨.
A host agent that is a target of the broken stream, or is itself the next-hop of the failed component, should release resources allocated to the stream, but should keep the internal state info describing the stream 🧠. It should inform any next higher protocol of the failure 📣. It's totally appropriate for that protocol to expect the stream will be fixed soon by some alternate path, so it keeps whatever info is needed in the ST layer, the next higher layer, and the application for a while, so entries for the stream can be reactivated quickly as the alternate path comes together 🦋. The agent should use a timeout to delete all the stream information in case the stream can't be fixed in a reasonable time ⏰.
An intermediate agent that is a next-hop of a failure that was not due to a preemption should first verify that there was a failure 🕵️♀️. It can do this by using STATUS messages to query its upstream neighbor. If it can't communicate with that neighbor, then it should first send a REFUSE message with the appropriate reason code of "failure" to the neighbor, to speed up failure recovery in case the hop is unidirectional, i.e., the neighbor can hear the agent but the agent can't hear the neighbor 🙉. The ST agent detecting the failure must then send DISCONNECT messages with the same reason code toward the targets. The intermediate agents process this DISCONNECT message just like the DISCONNECT that tears down the stream. However, a target ST agent that receives a DISCONNECT message with the appropriate reason code (StreamPreempted, or "failure") will maintain the stream state and notify the next higher protocol of the failure 🎀. In effect, these DISCONNECT messages tear the stream down from the point of the failure to the targets, but tell the targets the stream may be fixed shortly 🌈.
An ST agent that is the previous-hop before the failed component first verifies that there was a failure by querying the downstream neighbor using STATUS messages. If the neighbor has lost its state but is available, then the ST agent may reconstruct the stream if the NoRecovery option is not selected, as described below 🔁. If it can't communicate with the next-hop, then the agent detecting the failure releases any resources dedicated exclusively to sending data on the broken branch, and sends a DISCONNECT message with the appropriate reason code ("failure") toward the affected targets. It does so to speed up failure recovery in case the communication may be unidirectional and this message might be delivered successfully 🚀.
If the NoRecovery option is selected, then the ST agent that detects the failure sends a REFUSE message with the appropriate reason code ("failure") to the previous-hop. If it is breaking the stream intentionally, it sends a REFUSE message with the appropriate reason code (StreamPreempted) to the previous-hop. The TargetList in these messages contains all the targets that were reached through the broken branch 📋. Multiple REFUSE messages may be required if the PDU is too long for the MTU of the intervening network 📦. The REFUSE message is propagated all the way to the origin, which can attempt recovery of the stream by sending a new CONNECT to the affected targets 🫡. The new CONNECT will be treated by intermediate ST agents as an addition of new targets into the established stream ➕.
If the NoRecovery option is not selected, the ST agent that breaks the stream intentionally or is the previous-hop before the failed component can attempt recovery of the stream. It does so by issuing a new CONNECT message to the affected targets 🔧. If the ST agent cannot find new routes to some targets, or if the only route to some targets is through the previous-hop, then it sends one or more REFUSE messages to the previous-hop with the appropriate reason code ("failure" or StreamPreempted) specifying the affected targets in the TargetList. The previous-hop can then attempt recovery of the stream by issuing a CONNECT to those targets. If it cannot find an appropriate route, it will propagate the REFUSE message toward the origin 🏃.
Regardless of which agent attempts recovery of a damaged stream, it will issue one or more CONNECT messages to the affected targets 💫. These CONNECT messages are treated by intermediate ST agents as additions of new targets into the established stream. The FlowSpecs of the new CONNECT messages should be the same as the ones contained in the most recent CONNECT or CHANGE messages that the ST agent had sent toward the affected targets when the stream was operational 📝.
Rebuilding a broken stream may not go smoothly 😬. Since there may be some delay while the information about the failure is propagated throughout an internet, routing errors may occur for some time after a failure 🌪️. As a result, the ST agent attempting the recovery may receive REFUSE or ERROR-IN-REQUEST messages for the new CONNECTs that are caused by internet routing errors. The ST agent attempting the recovery should be prepared to resend CONNECTs before it succeeds in reconstructing the stream 🔁. If the failure partitions the internet and a new set of routes cannot be found to the targets, the REFUSE messages will eventually be propagated to the origin, which can then inform the application so it can decide whether to terminate or to continue to attempt recovery of the stream 🤷♀️.
The new CONNECT may at some point reach an ST agent downstream of the failure before the DISCONNECT does 😱. In this case, the agent that receives the CONNECT is not yet aware that the stream has suffered a failure, and will interpret the new CONNECT as resulting from a routing failure. It will respond with an ERROR-IN-REQUEST message with the appropriate reason code (StreamExists). Since the timeout that the ST agents immediately preceding the failure and immediately following the failure are approximately the same, it is very likely that the remnants of the broken stream will soon be torn down by a DISCONNECT message with the appropriate reason code ("failure"). Therefore, the ST agent that receives the ERROR-IN-REQUEST message with reason code (StreamExists) should retransmit the CONNECT message after the ToConnect timeout expires. If this fails again, the request will be retried for NConnect times. Only if it still fails will the ST agent send a REFUSE message with the appropriate reason code (RouteLoop) to its previous-hop. This message will be propagated back to the ST agent that is attempting recovery of the damaged stream. That ST agent can issue a new CONNECT message if it so chooses. The REFUSE is matched to a CONNECT message created by a recovery operation through the LnkReference field in the CONNECT 🔗.
ST agents that have propagated a CONNECT message and have received a REFUSE message should maintain this information for some period of time. If an agent receives a second CONNECT message for a target that recently resulted in a REFUSE, that agent may respond with a REFUSE immediately rather than attempting to propagate the CONNECT ✂️. This has the effect of pruning the tree that is formed by the propagation of CONNECT messages to a target that is not reachable by the routes that are selected first. The tree will pass through any given ST agent only once, and the stream setup phase will be completed faster 🏁.
The time period for which the failure information is maintained must be consistent with the expected lifetime of that information ⌛. Failures due to lack of reachability will remain relevant for time periods large enough to allow for network reconfigurations or repairs 🛣️. Failures due to routing loops will be valid only until the relevant routing information has propagated, which can be a short time period 🌀. Lack of bandwidth resulting from over-allocation will remain valid until streams are terminated, which is an unpredictable time, so the time that such information is maintained should also be short 📉.
If a CONNECT message reaches a target, the target should get to work as efficiently as possible, using the state it saved before the stream failed so recovery can happen 💖 Then it sends an ACCEPT message back toward the origin. That ACCEPT gets intercepted by the ST agent trying to recover the damaged stream, unless that agent is the origin itself ✨ If the FlowSpec in the ACCEPT has the same parameter selections as before the failure, the recovering ST agent won't propagate the ACCEPT, no cap 🙈 If the selections are different, the recovering agent sends the origin a NOTIFY message with the reason code (FailureRecovery), and that NOTIFY carries a FlowSpec with the new parameter values. The origin may then have to change its data generation and its stream parameters with a CHANGE message so it can use the newly recovered subtree 🌸
3.7.2.1. Subset 🎀
Okay, so subsets of this mechanism may reduce the functionality in a few ways 💅 A host agent might not keep state describing a stream that fails with a DISCONNECT message carrying the appropriate reason code ("failure" or StreamPreempted).
An agent might force the NoRecovery option to always be set. In that case, it will allow the option to be passed along in the CONNECT message, but it will pass on the REFUSE message with the appropriate reason code ("failure" or StreamPreempted) without trying to recover the damaged stream 🫶
If an ST agent allows stream recovery and tries to recover a stream, it might choose a FlowSpec that pins down exactly the current parameter values, with no ranges or options. Iconic, honestly 👑
3.7.3. A Group of Streams 🧚
There may be a need to link related streams together 🦋 The Group mechanism is basically an association technique. It lets ST agents identify the different streams that are meant to be associated. Streams are in the same Group if they have the same Group Name in the GroupName field of the (R)Group parameter. Right now there are no ST control messages that modify Groups. Group Names have the same format as stream Names, and they can share the same name space. A stream that is a member of a Group can specify one or more (Subgroup Identifier, Relation) tuples. The Relation says how the members of the Subgroup of the Group are related. Subgroup Identifiers only need to be unique within the Group, so no drama there 💜
Streams can be associated into Groups to support activities that deal with a bunch of streams at once. How Groups of streams actually operate is a matter for further study, and this mechanism is provided to support that study 🔬 This mechanism lets streams be identified as belonging to a given Group and Subgroup, but for it to have any effect, the behavior expected of the Relation must be implemented in the ST agents. Possible applications for this mechanism include the following:
- Associating streams that are part of a floor-controlled conference. In this case, only one origin can send data through its stream at any given time. So at any point where more than one stream passes through a branch or network, only enough bandwidth for one stream needs to be allocated 🎤
- Associating streams that cannot exist independently. An example would be the various streams carrying the audio, video, and data components of a conference, or the various streams carrying data from the different participants in a conference. In this case, if some ST agent must preempt more than a single stream, and it has selected any one of the streams so associated, then it should also preempt the rest of the members of that Subgroup, rather than preempting any other streams 🫠
- Associating streams that must not be completed independently. This one is similar to the previous example, but it's about the stream setup phase. Any single member of a Subgroup of streams doesn't need to be completed unless the rest are also completed. So if one stream gets blocked, all the others will also be blocked. If there aren't enough resources to support all the conferences that are attempted, some conferences will complete and others will be blocked, instead of every conference ending up partially completed and partially blocked 😭
This document assumes that the creation and membership of the Group will be managed by the next protocol above ST, with ST helping out. For example, the next higher protocol would ask ST to create a unique Group Name and a set of Subgroups with specified characteristics. That higher protocol would then distribute this information to the other participants who are going to be members of the Group. Each participant would pass the Group Name, Subgroups, and Relations to the ST layer, which would simply include them in the stream state 🌈
3.7.3.1. Group Name Generator 🍓
This facility exists so an application or higher layer protocol can get a unique Group Name from the ST layer ✨ It's a way for the application to request a Group Name that's independent of the request to create a stream. The Group Name is then used by the application or higher layer protocol when it creates the streams that will be part of a group. All that's required is a function of this form:
AllocateGroupName()
-> result, GroupNameA matching function to release a Group Name is also desirable. Its form is:
ReleaseGroupName( GroupName )
-> result3.7.3.2. Subset 🌸
Groups are currently intended to support experimentation, and it isn't clear yet how best to use them, so it's appropriate for an implementation not to support Groups 🧪 At this time, a subsetted ST agent may ignore the Group parameter. It's expected that in the future, once Groups move from being an experimental concept to an operational one, this kind of subsetting may no longer be acceptable. At that point, a new subsetting option may be defined.
3.7.4. HID Negotiation 💫
Each data packet must carry a value that identifies the stream it belongs to, so forwarding can happen 📦 Conceptually, this value could be the Name of the stream. But a shorthand identifier is desirable, and there are two reasons for that. First, since every data packet has to carry this identifier, network bandwidth efficiency suggests it should be as small as possible. This matters most for applications that use small data packets and low bandwidth networks, like voice across packet radio networks 🎙️ Second, every intermediate ST agent in the stream has to map this identifier into a data object that holds the forwarding information. To keep delay and processing overhead low, this should be as efficient as possible. Most likely, the identifier will be used to index into an internal table. To meet these goals, ST chose a 16-bit hop-by-hop identifier (HID). It's big enough to handle the foreseen number of streams during the expected life of the protocol, but small enough not to rule out using it as a forwarding table index 🔢 Just note that HID 0 is reserved for control messages, and HIDs 1-3 are also reserved for future use.
When ST uses the multicast ability of networks that provide it, a data packet multicast by an ST agent will be received identically by several next-hop ST agents. In a multicast environment, the HID must be selected either by some network-wide mechanism that picks unique identifiers, or by the sender of the CONNECT message. Since any network-wide mechanism is outside the scope of this protocol, we propose that the previous-hop agent select the HID and send it in the CONNECT message (with the HID Field option set, see Section 3.6.1 (page 44)), subject to approval by the next-hop agents. We call this "HID negotiation" 🤝
As an origin ST agent creates a stream, or an intermediate agent propagates a CONNECT message, it must make a routing decision to determine which targets will be reached through which next-hop ST agents. In some cases, several next-hops can be reached through a network that supports multicast delivery. If so, those next-hops will be made members of a multicast group, and data packets will be sent to the group. Different CONNECT messages are still sent to the several next-hops even when the data packets go to the multicast group, because the CONNECT messages contain different TargetLists and are acknowledged and accepted separately. However, the HID in the different CONNECT messages must be identical. The ST agent selects a 16-bit quantity to be the HID and inserts it into each CONNECT message that is then sent to the appropriate next-hop 💌
The next-hop agents that receive the CONNECT messages must propagate them toward the targets, but they must also look at the HID and decide whether they can approve it 👀 An ST agent can only receive data packets with a given HID if they belong to a single stream. If the ST agent already has an established stream that uses the proposed HID, that's a HID collision, and the agent cannot approve the HID for the new stream. Otherwise, the agent can approve the HID. If it can approve the HID, it must make note of that HID, and it must respond with a HID-APPROVE message (unless it can immediately respond with an ERROR-IN-REQUEST or a REFUSE). If it cannot approve the HID, it must respond with a HID-REJECT message. Main character decision-making, fr 👑
The sender that fires off a CONNECT with the H bit set 💅 doesn't just sit there waiting for ACCEPTs. It also waits for its own acknowledgment from the next-hops, which could be a HID-ACCEPT, a HID-REJECT, or an ERROR-IN-REQUEST, and it tracks that separately 👀. No reply before ToConnect runs out? It resends the CONNECT 🔁. If every next-hop sends back a HID-ACCEPT, that means they've all approved the HID, so it's cleared for every data packet after that ✨.
If even one next-hop sends a HID-REJECT, the agent that picked the HID MUST pick a new one and send it to each next-hop in a bundle of HID-CHANGE messages 🙅♀️. Each next-hop has to answer those HID-CHANGE messages (that's its acknowledgment) with either a HID-ACCEPT or a HID-REJECT. If something goes wrong, it can send an ERROR-IN-REQUEST instead, or a REFUSE if it wants to bail on the whole HID negotiation after turning down NHIDAbort proposed HIDs 🫠. If the agent doesn't hear back within ToHIDChange, it resends the HID-CHANGE up to NHIDChange times 😤. And if a next-hop sends a REFUSE that covers every target from the original CONNECT, that next-hop gets dropped from the negotiation 👋.
The whole negotiation is only officially done once the agent gets a HID-ACCEPT for the same proposed HID from every next-hop that didn't send an ERROR-IN-REQUEST or a REFUSE 🎉.
This negotiation could take an indeterminate amount of time, which is kind of wild 🌀. The CONNECT messages could reach the targets, and their ACCEPT messages could travel all the way back to the origin before the negotiation wraps up 😳. If that were allowed, the origin wouldn't know the negotiation was unfinished and might start sending data packets. Then the agent still picking a HID would have to throw that data away instead of sending it to the next-hops, since it might not have a valid HID to attach 💀.
So to avoid that mess, an ACCEPT SHOULD NOT be passed back to the previous-hop until the HID negotiation with the next-hops is complete 🙅♀️.
Yes, the negotiation can technically run forever, but that's super unlikely 🥹. The HID only matters across a single hop, so we can estimate how likely a randomly picked HID is to clash with one already in use on an established stream 📊. Picture a stream where the hop from an ST agent to ten next-hop agents goes through a network's multicast facility 🌐. Say each of those next-hop agents is already in 1000 other streams, and each of those streams has its own different HID. A randomly picked 16-bit HID has a better than 85.9% chance of working on the first try, 98.1% on the second, and 99.8% on the third 📈. So a 16-bit HID space is big enough to run ST for now 🎀, until better multicast HID selection, like HID servers, can be rolled out 🧚.
The obvious way to pick a HID is for ST agents to grab one from a random number generator, like we mentioned above 🎲. There's also another option: intermediate agents can reuse the HID from the incoming CONNECT for all of their outgoing CONNECT messages, and only make up a random number as a backup plan 🔄. In that case, the origin ST agent would be the one responsible for generating the HID, and that same HID could be carried through the whole stream 🌊. The perk here is that a higher layer protocol that has a global view could create the HID and pick small, globally unique HIDs for all the streams 🌟. That's possible, but it's been left for further study 📚.
Agent 3 Agent B
1. +-> CONNECT B -------------->+
<RVLId=0><SVLId=32> |
<Ref=315><HID=5990> V
2. (Check HID Table, 5990 busy, 6000-11 unused)
V
3. +<- HID-REJECT --------------+
| <RVLId=32><SVLId=45>
| <Ref=315><HID=5990>
V <FreeHIDs=5990:0000FFF0>
4. +-> HID-CHANGE ------------>+
<RVLId=45><SVLId=32> |
<Ref=320><HID=6000> V
5. (Check HID Table, 6000 (still) available)
V
6. +<- HID-APPROVE -------------+
<RVLId=32><SVLId=45>
<Ref=320><HID=6000>
7. (Both parties have now agreed to use HID 6000)
Figure 18. Typical HID Negotiation (No Multicasting) Agent 2 Agent C Agent D
1. +->+-> CONNECT ---------------------------------->+
| <RVLId=0><SVLId=26> |
| <Ref=250><HID=4824> |
V <Mcast=224.1.18.216,01:00:5E:01:12:d8> |
2. +-> CONNECT --------------------+ |
<RVLId=0><SVLId=25> | |
<Ref=252><HID=4824> | V
3. <Mcast=224.1.18.216, V (Check HID Table)
4. 01:00:5E:01:12:d8> (Check HID Table) (4824 ok)
(4824 busy) (4800-4809 ok)
(4800-4820 ok) |
V |
5. +<- HID-REJECT -----------------+ |
| <RVLId=25><SVLId=54> |
| <Ref=252><HID=4824> |
V <FreeHIDs=4824:FFFFF800> V
6. +<-+<- HID-APPROVE -------------------------------+
| <RVLId=26><SVLId=64>
| <Ref=250><HID=4824>
V <FreeHIDs=4824:FFC00080>
(find common HID 4800)
V
7. +->+-> HID-CHANGE ------------------------------->+
| <RVLId=64><SVLId=26> |
V <Ref=253><HID=4800> |
8. +-> HID-CHANGE ---------------->+ |
<RVLId=54><SVLId=25> | V
9. <Ref=254><HID=4800> V (Check HID Table)
10. (Check HID Table) (4800 ok)
(4800-4820 ok) (4800-4809 ok)
V |
11. +<- HID-APPROVE ----------------+ |
| <RVLId=25><SVLId=54> |
| <Ref=254><HID=4800> |
V <FreeHIDs=4800:7FFFF800> V
12. +<-+<- HID-APPROVE -------------------------------+
| <RVLId=26><SVLId=64>
| <Ref=253><HID=4800>
V <FreeHIDs=4800:7FC00080>
13. (all parties have now agreed to use HID 4800)
Figure 19. Multicast HID Negotiation Agent 2 Agent C Agent D Agent 3
1. +----> CONNECT B ------------------------------------>+
<RVLId=0><SVLId=24> V
2. <Ref=260><HID=4800> (Check HID Table)
<Mcast=224.1.18.216, (4800 busy, 4801-4810 ok)
01:00:5E:01:12:d8> V
3. +<---- HID-REJECT <-----------------------------------+
| <RVLId=24><SVLId=33>
| <Ref=260><HID=4824>
V <FreeHIDs=4824:7FE00000>
4. (find common HID 4810)
V
5. +->+-> HID-CHANGE ----------------------------------->+
| <RVLId=33><SVLId=24> |
V <Ref=262><HID=4810> |
6. +-> HID-CHANGE-ADD ------------------->+ |
| <RVLId=64><SVLId=26> | V
7. V <Ref=263><HID=4810> | (Check HID Table)
8. +-> HID-CHANGE-ADD ---->+ | (4801-4815 ok)
<RVLId=54><SVLId=25>| V |
9. <Ref=265><HID=4810> V (Check HID Table) |
10. (Check HID Table) (4810 busy) |
(4801-4812 ok) (4801-4807 ok) |
V | |
11. +<- HID-APPROVE <-------+ | |
| <RVLId=25><SVLId=54> | |
| <Ref=265><HID=4810> | |
V <FreeHIDs=4810:7FD8000> V |
12. +<- HID-REJECT <-----------------------+ |
| <RVLId=26><SVLId=64> |
| <Ref=263><HID=4810> |
V <FreeHIDs=4810:7F000000> V
13. +<-+<- HID-APPROVE <----------------------------------+
| <RVLId=24><SVLId=33>
| <Ref=262><HID=4810>
V <FreeHIDs=4810:7FDF0000>
14. +->+-> HID-CHANGE-DELETE ---------------------------->+
| | <RVLId=33><SVLId=24> |
| V <Ref=266><HID=4810> |
15. | +-> HID-CHANGE-DELETE ->+ |
| <RVLId=54><SVLId=25>| |
| <Ref=268><HID=4810> V |
16. | +<- HID-APPROVE --------+ |
| <RVLId=25><SVLId=54> |
| <Ref=268><HID=0> V
17. | +<- HID-APPROVE -----------------------------------+
| <RVLId=24><SVLId=33>
V <Ref=266><HID=0>
18. (find common HID 4801)
Figure 20. Multicast HID Re-Negotiation (part 1)Okay, the HID dance wraps up here, bestie 💃 Once everyone agrees, the switch happens, and the old HID gets cleaned up 🧚
18. (find common HID 4801)
V
19. +->+-> HID-CHANGE ----------------------------------->+
| <RVLId=33><SVLId=24> |
V <Ref=270><HID=4801> |
20. +-> HID-CHANGE-ADD ------------------->+ |
| <RVLId=64><SVLId=26> | V
21. V <Ref=273><HID=4801> | (Check HID Table)
22. +-> HID-CHANGE-ADD ---->+ | (4801-4815 ok)
<RVLId=54><SVLId=25>| V |
23. <Ref=274><HID=4801> V (Check HID Table) |
24. (Check HID Table)(4801-4807 ok) |
(4801-4812 ok) | |
V | |
25. +<- HID-APPROVE <-------+ | |
| <RVLId=25><SVLId=54> | |
| <Ref=274><HID=4801> | |
V <FreeHIDs=4801:3FF80000> V |
26. +<- HID-APPROVE <----------------------+ |
| <RVLId=26><SVLId=64> |
| <Ref=273><HID=4801> |
V <FreeHIDs=4801:3F000000> V
27. +<-+<- HID-APPROVE <----------------------------------+
| <RVLId=24><SVLId=33>
| <Ref=270><HID=4801>
V <FreeHIDs=4801:3FFF0000>
28. (switch data stream to HID 4801, drop 4800)
V
29. +->+-> HID-CHANGE-DELETE ---------------->+
| <RVLId=64><SVLId=26> |
V <Ref=275><HID=4800> |
30. +-> HID-CHANGE-DELETE ->+ |
<RVLId=54><SVLId=25>| |
<Ref=277><HID=4800> V |
31. +<-+<- HID-APPROVE --------+ |
| <RVLId=25><SVLId=54> |
V <Ref=277><HID=0> V
32. +<-+<- HID-APPROVE -----------------------+
| <RVLId=26><SVLId=64>
V <Ref=275><HID=0>
(all parties have now agreed to use HID 4801)
Figure 20. Multicast HID Re-Negotiation (part 2)3.7.4.1. Subset 🌸
The mechanism above can work exactly as described even when the ST agents don't all use the full 16 bits of the HID. A low-capacity ST agent that can't handle a ton of simultaneous streams MAY use only some of the bits, say the low-order byte, for example. This MAY let that disadvantaged agent use smaller internal data structures, but the trade-off is that HID collisions happen more often 💀. Still, its previous-hop and next-hops don't need to know about its limitations 🫶. During the HID negotiation, the negotiators still exchange a 16-bit quantity ✨.
3.7.5. IP Encapsulation of ST 🦋
ST packets MAY be encapsulated in IP so they can slip through routers that don't support the ST Protocol. Obvi, ST resource management is precluded over a path like that, and packet overhead goes up, but if the performance is reasonably predictable, this MAY be better than not communicating at all 💅. IP encapsulation MAY also be REQUIRED for enhanced security (see Section 3.7.8 (page 67)), or for user-space implementations of ST in hosts that don't allow demultiplexing on the IP Version Number field (see Section 4 (page 75)) but do allow access to raw IP packets.
IP-encapsulated ST packets begin with a normal IP header. Most fields of the IP header SHOULD be filled in according to the same rules that apply to any other IP packet. Three fields of special interest are:
Protocolis 5 to indicate an ST packet is enclosed, as opposed to TCP or UDP, for example. The assignment of protocol 5 to ST is an arranged coincidence with the assignment of IP Version 5 to ST [18].Destination Addressis that of the next-hop ST agent. This MAY or MAY NOT be the target of the ST stream. There MAY be an intermediate ST agent to which the packet SHOULD be routed, so it can take advantage of service guarantees on the path past that agent. Such an intermediate agent would not be on a directly-connected network (or else IP encapsulation wouldn't be needed), so it would probably not be listed in the normal routing table. Additional routing mechanisms, not defined here, will be REQUIRED to learn about such agents.Type-of-ServiceMAY be set to an appropriate value for the service being requested (usually low delay, high throughput, normal reliability). This feature isn't implemented uniformly across the Internet, so its use can't be precisely defined here.
Since there can be no guarantees made about performance across a normal IP network, the ST agent that will encapsulate SHOULD modify the Desired FlowSpec parameters when the stream is being established, to indicate that performance is not guaranteed. In particular, Reliability SHOULD be set to the minimum value (1/256), and suitably large values SHOULD be added to the Accumulated Mean Delay and Accumulated Delay Variance to reflect the possibility that packets MAY be delayed up to the point of discard when there is network congestion. A suitably large value is 255 seconds, the maximum packet lifetime as defined by the Time-to-Live field.
IP encapsulation adds little difficulty for the ST agent that receives the packet. The IP header is simply removed, then the ST header is processed as usual.
The trickier part is during setup, when the ST agent MUST decide whether or not to encapsulate. If the next-hop ST agent is on a remote network, and the route to that network goes through a router that supports IP but not ST, then encapsulation is REQUIRED. As mentioned in Section 3.8.1 (page 69), routing table entries MUST be expanded to indicate whether the router supports ST.
On forwarding, the (mostly constant) IP Header MUST be inserted and the IP checksum appropriately updated.
On a directly connected network, though, one might want to encapsulate only when sending to a particular destination host that doesn't allow demultiplexing on the IP Version Number field. This requires the routing table to include host-route as well as network-route entries. Host-route entries might require static definition if the hosts don't participate in the routing protocols. If packet size isn't a critical performance factor, one solution is always to encapsulate on the directly connected network whenever some hosts require encapsulation. Those that don't require the encapsulation SHOULD be able to remove it upon reception.
3.7.5.1. IP Multicasting 🎀
If an ST agent MUST use IP encapsulation to reach multiple next-hops toward different targets, then either the packet MUST be replicated for transmission to each next-hop, or IP multicasting [6] MAY be used, if it is implemented in the next-hop ST agents and in the intervening IP routers.
This is analogous to using network-level service to multicast to several next-hop agents on a directly connected network.
When the stream is established, the collection of next-hop ST agents MUST be set up as an IP multicast group. It MAY be necessary for the ST agent that wishes to send the IP multicast to allocate a transient multicast group address and then tell the next-hop agents to join the group. Use of the MulticastAddress parameter (see Section 4.2.2.7 (page 86)) provides one way that the information MAY be communicated, but other techniques are possible. The multicast group address gets inserted into the Destination Address field of the IP encapsulation when data packets are transmitted.
A block of transient IP multicast addresses, 224.1.0.0 - 224.1.255.255, has been allocated for this purpose. There are 2^16 addresses in this block, allowing a direct mapping with 16-bit HIDs, if appropriate. The mechanisms for allocating these addresses are not defined here.
In addition, two permanent IP multicast addresses have been assigned to facilitate experimentation with exchange of routing or other information among ST agents. Those addresses are:
224.0.0.7 All ST routers
224.0.0.8 All ST hostsAn ST router is an ST agent that can pass traffic between attached networks; an ST host is an ST agent that is connected to a single network or is not permitted to pass traffic between attached networks. Note that the range of these multicasts is normally just the attached local network, limited by setting the IP time-to-live field to 1 (see [6]).
3.7.6. Retransmission 🔥
The ST Control Message Protocol is made reliable through use of retransmission when an expected acknowledgment isn't received in a timely manner. The problem of when to send a retransmission has been studied for protocols such as TCP [2] [10] [11]. The problem SHOULD be simpler for ST, since control messages usually only have to travel a single hop and they don't contain very much data. However, the algorithms developed for TCP are sufficiently simple that their use is RECOMMENDED for ST as well; see [2]. An implementor might, for example, choose to keep statistics separately for each neighboring ST agent, or combined into a single statistic for an attached network.
Estimating the packet round-trip time (RTT) is a key function in reliable transport protocols such as TCP. Estimation MUST be dynamic, since congestion and resource contention result in varying delays. If RTT estimates are too low, packets will be retransmitted too frequently, wasting network capacity. If RTT estimates are too high, retransmissions will be delayed, reducing network throughput when transmission errors occur. Article [11] identifies problems that arise when RTT estimates are poor, outlines how RTT is used and how retransmission timeouts (RTO) are estimated, and surveys several ways that RTT and RTO estimates can be improved.
Note the HELLO/ACK mechanism described in Section 3.7.1.2 (page 49) can give an estimate of the RTT and its variance. These estimates are also important for use with the delay and delay variance entries in the FlowSpec.
3.7.7. Routing 🗺️
okay so ST needs routing info to pick a path from an origin to the destination(s) 🗺️ but routing is its own separate issue, so neither the routing algorithm nor its implementation gets specified here. ST should work equally well with any reasonable routing algorithm 💅
ST could use a bunch of info that isn't available yet, but the minimum it needs is what IP already gives: finding an interface and next hop router for a specified IP destination address and Type of Service 🧚 Ways to make more info available and use it are left for further study 🔭 For early ST implementations, any routing info that's needed but not automatically provided gets manually configured into the ST agents 🛠️
3.7.8. Security ✨
bestie, the ST Protocol by itself does NOT provide security services 🙈 It's more vulnerable to misdelivery and denial of service than IP, because the ST Header only carries a 16-bit HID for identification purposes 💀 Anything like source and destination addresses that a higher-layer protocol might use to detect misdelivery is the responsibility of the application or the higher-layer protocol 🫶
ST is less prone to traffic analysis than IP, since the only identifying info in the ST Header is a hop-by-hop identifier (HID). BUT the HID is also what makes ST more vulnerable to denial of service 😭 An ST agent has no reliable way to detect when bogus traffic is injected into a user's stream, and so that traffic eats up bandwidth. Detection can be enhanced through per-interface forwarding tables and verification of local network source and destination addresses 🔍
We envision that applications that require security services will use facilities such as the Secure Digital Networking System (SDNS) layer 3 Security Protocol (SP3/D) [19] [20]. In that setup, ST PDUs would first be encapsulated in an IP Header, using IP Protocol 5 (ST) as described in Section 3.7.5 (page 64). Those IP datagrams would then be secured using SP3/D, which results in another IP Protocol 5 PDU that can be passed between ST agents 🔐
This memo does not specify how an application invokes security services 🙅
3.8. ST Service Interfaces 🎀
ST has several interfaces to other modules in a communication system ✨ ST provides its services to applications or transport-level protocols through its "upper" interface (or SAP). ST in turn uses the services provided by network layers, management functions (e.g., address translation and routing), and IP. The interfaces to these modules are described in this section in the form of subroutine calls. Note that this does NOT mean an implementation must actually be implemented as subroutines. It's just there to identify the information passed between the modules 📋
In this style, the information passed into a module is shown as arguments to the subroutine call. Return information and/or success/failure indications are listed after the arrow ("->") that follows the subroutine call. In several cases, a list of values has to be passed to or returned from a module interface, like a set of target addresses, or the mappings from a target list to a set of next hop addresses that span the route to the originally listed targets. When that happens, the values repeated for each list element are bracketed and an asterisk is added, so "<target>*" means zero, one, or many targets 🧩
3.8.1. Access to Routing Information
The design of routing functions that can support a variety of resource management algorithms is difficult 😤 In this section we suggest a set of preliminary interfaces for initial experiments. We expect these interfaces will change as we gain more insight into how routing, resource allocation, and decision making elements are best divided 🦋
routing functions are required to identify the set of potential routes to each destination site. The routing functions should make some effort to identify routes that are currently available and that meet the resource requirements. However, these properties need not be confirmed until the actual resource allocation and connection setup propagation are performed.
The minimum capability required of the interface to routing is to identify the network interface and next hop toward a given target. We expect the traditional routing table will need to be extended to include info ST requires, such as whether or not a next hop supports ST, and, if so, whether or not IP encapsulation (see Section 3.7.5 (page 64)) is required to communicate with it. In particular, host entries will be required for hosts that can only support ST through encapsulation, because the IP software either is not capable of demultiplexing datagrams based on the IP Version Number field, or the application interface only supports access to raw IP datagrams. This interface is illustrated by the function:
FindNextHop( destination, TOS )
-> result, < interface, next hop, ST-capable,
MustEncapsulate >*However, the resource management functions can best tradeoff among alternative routes when they're presented with a matrix of all potential routes 🧮 The matrix entry for a destination and a next hop would contain the estimated characteristics of the corresponding pathway. With this representation, the resource management functions can quickly figure out the next hop sets that cover the entire destination list, and compare the tradeoff parameters between the guarantees each set can promise. An interface that returns a compressed matrix, listing the suitable routes by next hop and the destinations reachable through each, is illustrated by the function:
FindNextHops( < destination >*, TOS )
-> result, < destination, < interface, next hop,
ST-capable, MustEncapsulate >* >*We hope routing protocols will be available that propagate additional metrics of bandwidth, delay, bit/burst error rate, and whether a router has ST capability 🤞 However, propagating this info in a timely fashion is still a key research issue 🔬
3.8.2. Access to Network Layer Resource Reservation
The resources required to reach the next-hops associated with the chosen routes must be allocated 📦 These allocations will generally be requested and released incrementally. As the next-hop elements for the routes are chosen, the network resources between the current node and the next-hops must be allocated. Since the resources are not guaranteed to be available (a network or node further down the path might have failed, or needed resources might have been allocated since the routing decisions were made), some of these allocations may have to be released, another route selected, and a new allocation requested 😵💫
There are four basic interface functions needed for the network resource allocator. The first checks to see if the required resources are available, returning the likelihood that an ensuing resource allocation will succeed. A probability of 0% means the resources are not available or can't promise the required guarantees. Low probabilities mean most of the resource has been allocated or there's a lot of contention for using it. This call does NOT actually reserve the resources:
ResourceProbe( requirements )
-> likelihoodAnother call reserves the resources:
ResourceReserve( requirements )
-> result, reservation_idThe third call adjusts the resource guarantees:
ResourceAdjust( reservation_id, new requirements )
-> resultThe final call allows the resources to be released:
ResourceRelease( reservation_id )
-> result3.8.3. Network Layer Services Utilized
ST requires access to the usual network layer functions to send and receive packets and to be informed of network status info 📡 On top of that, it requires functions to enable and disable reception of multicast packets. Such functions might be defined as:
JoinLocalGroup( network level group-address )
-> result, multicast_id
LeaveLocalGroup( network level group-address )
-> result
RecvNet( SAP )
-> result, src, dst, len, BufPTR )
SendNet( src, dst, SAP, len, BufPTR )
-> result
GetNotification( SAP )
-> result, infop3.8.4. IP Services Utilized
Since ST packets might be sent or received using IP encapsulation, IP level routines to join and leave multicast groups are required, on top of the usual services defined in the IP specification (see the IP specification [2] [15] and the IP multicast specification [6] for details) 🧃
JoinHostGroup( IP level group-address, interface )
-> result, multicast_id
LeaveHostGroup( IP level group-address, interface )
-> result
GET_SRCADDR( remote IP addr, TOS )
-> local IP address
SEND( src, dst, prot, TOS, TTL, BufPTR, len, Id, DF,
opt )
-> result
RECV( BufPTR, prot )
-> result, src, dst, SpecDest, TOS, len, opt
GET_MAXSIZES( local, remote, TOS )
-> MMS_R, MMS_S
ADVISE_DELIVPROB( problem, local, remote, TOS )
-> result
SEND_ICMP( src, dst, TOS, TTL, BufPTR, len, Id, DF, opt )
-> result
RECV_ICMP( BufPTR )
-> result, src, dst, len, opt3.8.5. ST Layer Services Provided
Interface to the ST layer services may be modeled using a set of subroutine calls (but doesn't need to be implemented as such) 🧠 When the protocol is implemented as part of an operating system, these subroutines may be used directly by a higher level protocol processing layer.
These subroutines might also be provided through system service calls to give a raw interface for use by an application. Often this will require further adaptation to conform with the idiom of the particular operating system. For example, 4.3 BSD UNIX (TM) provides sockets, ioctls and signals for network programming 💻
open( connect/listen, SAPBytes, local SAP, local host,
account, authentication info, < foreign host,
SAPBytes, foreign SAP, options >*, flow spec,
precedence, group name, optional parameters )
-> result, id, stream name, < foreign host,
foreign SAPBytes, foreign SAP, result, flow spec,
rname, optional parameters >*
Note that an open by a target in "listen mode" may cause ST to
create a state block for the stream to facilitate rendezvous.
add( id, SAPBytes, local SAP, local host, < foreign host,
SAPBytes, foreign SAP, options >*, flow spec,
precedence, group name, optional parameters )
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result,
flow spec, rname, optional parameters >*
send( id, buffer address, byte count, priority )
-> result, next send time, burst send time
recv( id, buffer address, max byte count )
-> result, byte count
recvsignal( id )
-> result, signal, info
receivecontrol( id )
-> result, id, stream name, < foreign host,
foreign SAPBytes, foreign SAP, result, flow spec,
rname, optional parameters >*
sendcontrol( id, flow spec, precedence, options,
< foreign host, SAPBytes, foreign SAP, options >*)
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result, flow spec, rname,
optional parameters >*
change( id, flow spec, precedence, options,
< foreign host, SAPBytes, foreign SAP, options >*)
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result, flow spec, rname,
optional parameters >*
close( id, < foreign host, SAPBytes, foreign SAP >*,
optional parameters )
-> result
status( id/stream name/group name )
-> result, account, group name, protocol,
< stream name, < foreign host, SAPbytes,
foreign SAP, state, options, flow spec,
routing info, rname >*, precedence, options >*
creategroup( members* )
-> result, group name
deletegroup( group name, members* )
-> result[This page intentionally left blank.]
4. ST Protocol Data Unit Descriptions ✨
okay bestie, so the ST PDUs that zoom between ST agents are built out of an ST Header 🎀 wrapping up either a higher layer PDU or an ST Control Message. ST is basically an extension of IP, so these packets land at the same network service access point that IP uses to receive IP datagrams. Like, ST would use the same ethertype (0x800) that IP does! 🦋
The way the two packet types tell each other apart is the IP Version Number field, which is the first four bits of the packet. IP currently uses a value of 4, and ST got assigned the value 5 [18] 💖. There is no requirement for compatibility between IP and ST packet headers beyond those first four bits, so that's the only shared real estate, no cap 💅.
The ST Header also has an ST Version Number, a total length field, a header checksum, and a HID, all shown in Figure 21. If you want the notation explained, check out Appendix 1 (page 147) 📖.
ST is the IP Version Number assigned to identify ST packets. The value for ST is 5.
Ver is the ST Version Number. This document defines ST Version 2.
Pri is the priority of the packet. It is used in data packets to indicate those packets to drop if a stream is exceeding its allocation. Zero is the lowest priority and 7 the highest. 🍓
T (bit 11) is used to indicate that a Timestamp is present following the ST Header but before any next higher layer protocol data. The Timestamp is not permitted on ST Control Messages (which may use the OriginTimestamp option) 🙈.
Bits 12 through 15 are spares and should be set to 0.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ST=5 | Ver=2 | Pri |T| Bits | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HID | HeaderChecksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Timestamp -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21. ST HeaderTotalBytes is the length, in bytes, of the entire ST packet. It includes the ST Header and optional Timestamp, but not any local network headers or trailers. Generally speaking, all length fields in the ST Protocol are in units of bytes 📏.
HID is the 16-bit hop-by-hop stream identifier. It's an abbreviation for the Name of the stream, and it's used both to shrink the packet header length and, for the receiver of the data packet, to make the forwarding function more efficient ⚡. Control Messages have a HID value of zero. HIDs are negotiated by the next-hop and previous-hop agents so the abbreviation stays unique. It's used here in the ST Header and in various Control Messages. HID values 1-3 are reserved for future use 🔒.
HeaderChecksum covers only the ST Header and Timestamp, if present. The ST Protocol uses 16-bit checksums here in the ST Header and in each Control Message. The standard Internet checksum algorithm is used: "The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero." See [1] [12] [15] for suggestions for efficient checksum algorithms 🧮.
Timestamp is an optional timestamp inserted into data packets by the origin. It's only present when the T bit, described above, is set (1). Its use is negotiated at connection setup time; see Sections 4.2.3.5 (page 108) and 4.2.3.1 (page 100). The Timestamp has the NTP format; see [13] ⏰.
4.1. Data Packets
ST packets whose HID is not zero to three are user data packets 💜. Their interpretation is a matter for the higher layer protocols, so it isn't specified here. The data packets are not protected by an ST checksum, and they will be delivered to the higher layer protocol even with errors. Yikes, but that's the deal 😬.
ST agents will not pass data packets over a new hop whose setup is not complete, i.e., a HID must have been negotiated and either an ACCEPT or REFUSE has been received for all targets specified in the CONNECT. So no sneaking data through a half-finished hop, periodt 🚫.
4.2. ST Control Message Protocol Descriptions
ST Control Messages go between a previous-hop agent and its next-hop agent(s), using a HID of zero 🫶. The control protocol follows a request-response model, and all requests expect responses. Retransmission after timeout (see Section 3.7.6 (page 66)) is used to allow for lost or ignored messages, so nothing just vanishes into the void 🌈.
Control messages do not extend across packet boundaries. If a control message is too large for the MTU of a hop, its information (usually a TargetList) is partitioned, and a control message per partition is sent 🧩. All control messages have the following format:
OpCode identifies the type of control message. Each is described in detail in following sections 📝.
Options is used to convey OpCode-specific variations for a control message ✨.
TotalBytes is the length of the control message, in bytes, including all OpCode specific fields and optional parameters. The value is always divisible by four 🔢.
RVLId is used to convey the Virtual Link Identifier of the receiver of the control message, when known, or zero in the case of an initial CONNECT or diagnostic message. The RVLId is intended to permit efficient dispatch to the portion of a stream's state machine containing information about a specific operation in progress over the link. RVLId values 1-3 are reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49) 🎀.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Options | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
: OpCode Specific Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22. ST Control Message FormatSVLId is used to convey the Virtual Link Identifier of the sender of the control message. Except for ERROR-IN-REQUEST and diagnostic messages, it must never be zero. SVLId values 1-3 are reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49) 🦋.
Reference is a transaction number. Each sender of a request control message assigns a Reference number to the message that is unique with respect to the stream. The receiver uses the Reference number to detect and discard duplicates. Each acknowledgment carries the Reference number of the request being acknowledged. Reference zero is never used, and Reference numbers are assumed to be monotonically increasing with wraparound, so the older-than and more-recent-than relations are well defined 🔁.
LnkReference contains the Reference field of the request control message that caused this request control message to be created. It's used in situations where a single request leads to multiple "responses". Examples are CONNECT and CHANGE messages that must be acknowledged hop-by-hop and will also lead to an ACCEPT or REFUSE from each target in the TargetList 🔗.
SenderIPAddress is the 32-bit IP address of the network interface that the ST agent used to send the control message. This value changes each time the packet is forwarded by an ST agent (hop-by-hop) 🌸.
Checksum is the checksum of the control message. Because control messages are sent in packets that may be delivered with bits in error, each control message must be checked before it is acted upon; see Section 4 (page 76) 🔍.
4.2.1. ST Control Messages ✨
okay so the OpCode Specific Data is where any extra info for a control message lives 🎀 what goes in there depends on which control message you're looking at, and we'll get into that below 💅 fun detail: some response messages stuff in fields of zero so the layout matches the request it's answering 🌸 and the OpCode Specific Data can also carry any of the optional Parameters from Section 4.2.2 (page 80) 🧚
CONNECT and CHANGE are the messages that set up or modify branches in the stream 🌊 they travel from the origin toward the targets 🎯 and they're end-to-end messages that the origin makes. they keep going all the way to the targets, and they need a reply, which is one of ERROR-IN-REQUEST, ACK, HID-REJECT, HID-APPROVE, ACCEPT, or REFUSE 💌 CONNECT is the stream setup message ✨ CHANGE is used to change the characteristics of a stream that already exists 🦋 CONNECT also gets used to add one or more targets to an existing stream, and during recovery of a broken stream 🩹 both messages have a TargetList parameter and get handled pretty much the same way 🫶
DISCONNECT is used to tear down streams or parts of streams 💀 it moves from the origin toward the targets too 🎯 it's either an end-to-end message the origin makes to completely tear a stream down, or it's made by an intermediate ST agent that preempts a stream or notices that its previous-hop agent or network in the stream has failed 😭 in that second case it tears down the part of the stream from the failure to the targets, so the message still goes all the way to the targets 🌈
REFUSE is sent by a target when it wants to refuse to join a stream or take itself out of one 🙅♀️ in those cases it's an end-to-end message. an intermediate ST agent issues a REFUSE if it can't find a route to a target, if it can only find a route to a target through the previous-hop, if it preempts a stream, or if it detects a failure in a next-hop ST agent or network 🔥 no matter what, a REFUSE heads back toward the origin 🔙
ACCEPT is an end-to-end message generated by a target 💖 it means the setup of a stream or part of a stream finished successfully, or that the FlowSpec got changed ✅ there are no other messages like it, it's iconic and one of a kind 👑
the next sections are the common fields and parameters, followed by the individual control messages, and both are listed in alphabetical order 📚 each one gets a quick description of what the message is for, and the packet format is shown in a diagram 🎨
4.2.2. Common SCMP Elements 🎀
a bunch of fields and parameters (we call them "elements" for short) show up in two or more PDUs 👯♀️ so instead of explaining them over and over, they're described in one place here ✨ a lot of the time, having a parameter is optional 🤷♀️ to keep parsing easy, every parameter starts with a PCode byte, then a PBytes byte that tells you how long the parameter is in bytes (counting the PCode, PByte, and any padding bytes) 💅 if the info isn't a multiple of 4 bytes, the parameter gets padded with one to three zero (0) bytes, so PBytes is always a multiple of four 🌸 and parameters can show up in any order 🦋
4.2.2.1. DetectorIPAddress 🔍
a few control messages have the DetectorIPAddress field 🕵️♀️ it identifies the agent that caused the first instance of the message to be generated, which means before it got propagated 💖 when the message gets copied into the version that's sent on to a previous-hop or next-hop, this field gets copied along too 🔁 its use is mainly diagnostic, so think of it as the detective clue 🧐
4.2.2.2. ErroredPDU 🚨
the ErroredPDU parameter (PCode = 1) is for diagnostics 🩺 it wraps up a received ST PDU that had an error in it 🎁 it can show up in ERROR-IN-REQUEST, ERROR-IN-RESPONSE, or REFUSE messages 💌 again, its use is mainly diagnostic 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 1 | PBytes | PDUBytes | ErrorOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PDUInError : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 23. ErroredPDU
here's the breakdown of the bits inside it 👀
- PDUBytes tells you how many bytes of the PDUInError are actually there 📏
- ErrorOffset is the number of bytes into the errored PDU where the field with the error lives 🎯 the errored PDU has to include at least that much, so the field or parameter that ErrorOffset points to is in there 💯 and an ErrorOffset of zero would mean the problem is with the IP Version Number or ST Version Number fields 😱
- PDUInError is the PDU in error, starting with the ST Header 🎀
4.2.2.3. FlowSpec & RFlowSpec 🌊
the FlowSpec is how stream service requirements get communicated end-to-end 💫 we expect other versions of FlowSpec to show up later, and they might or might not be subsets or supersets of the one here 🔮 PBytes lets new constraints get added on the end without every implementation in the field needing an update at the same time 🫶 implementations are expected to handle a Version 4 (or higher) structure that has more elements than shown here, and to do it gracefully 🕊️
the FlowSpec parameter (PCode = 2) shows up in several messages to carry the FlowSpec 📦
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | PBytes | Version = 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DutyFactor | ErrorRate | Precedence | Reliability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tradeoffs | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnCost | LimitOnDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnPDUBytes | LimitOnPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinBytesXRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdMeanDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdDelayVariance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesPDUBytes | DesPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 24. FlowSpec & RFlowSpec
the RFlowSpec parameter (PCode = 12) goes with the FDx option 🔄 it carries the FlowSpec that gets used in the reverse direction ↩️
here's what each field in the FlowSpec does 👇
- Version tells you which version of the FlowSpec it is. Version 3 is the one defined here 🌸
- DutyFactor is the estimated proportion of time the requested bandwidth will actually be in use ⏰ zero means 256, which signals a duty factor of 1 💯 any other value gets divided by 256 to get the duty factor 🧮
- ErrorRate expresses the error rate as the negative exponent of 10 in the error rate 🤓 one (1) stands for a bit error rate of 0.1, and 10 stands for 0.0000000001 🔢
- Precedence is the precedence of the connection being established 👑 zero is the lowest precedence. heads up, non-zero values of this parameter should be subject to authentication and authorization checks, but those checks aren't specified here 🔐 the big difference between precedence and priority is that precedence says which streams are allowed to take previously committed resources away from another stream, while priority says which PDUs a stream would be happiest to have dropped when it goes over its guaranteed limits 🥹
- Reliability gets modified by each intervening ST agent, and it measures the probability that a given offered data packet gets forwarded and not dropped 🛡️ zero means 256, which is a probability of 1 ✨ any other value gets divided by 256 to get the probability 🧠
- Tradeoffs is incompletely defined right now 🚧 these are the bits that are currently specified:
- the most significant bit in the field, bit 0 in Figure 24, is one (1) when each ST agent must "implement" all constraints in the FlowSpec, even if they're not shown in the figure (like when the FlowSpec has been extended). when it's zero (0), unknown constraints may be ignored 🙈
- the second most significant bit, bit 1, is one (1) when one or more constraints are unknown and have been ignored. when it's zero (0), all constraints are known and got processed 🧩
- the third most significant bit, bit 2, is used for RevChrg. see Section 3.6.5 (page 46) 📖
- the other bits are currently unspecified. the origin ST agent should set them to zero (0), and other agents shouldn't change them unless they know what they mean 🚫
- RecoveryTimeout is the nominal number of milliseconds the application is willing to wait for a failed system component to be detected and for any corrective action to be taken ⏳
- LimitOnCost is the maximum cost the origin is willing to spend 💸 a value of zero means the application isn't willing to incur any direct charges for the resources the stream uses 🙅♀️ what non-zero values mean is left for further study 🔬
- LimitOnDelay is the maximum end-to-end delay, in milliseconds, that the origin can tolerate ⚡
The FlowSpec keeps going, and these numbers are so specific 😭🎀
LimitOnPDUBytes is the smallest packet size, measured in ST-user data bytes, that the origin can put up with 💅
LimitOnPDURate is the lowest packet rate the origin can tolerate, written as tenths of a packet per second 🦋
MinBytesXRate is the minimum bandwidth the origin can tolerate, expressed as a product of bytes and tenths of a packet per second ✨
AccdMeanDelay gets modified by every ST agent it passes through 🧚 It reports the total expected delay for a data packet in milliseconds. Also, it's implicitly assumed that the requested mean delay is zero and there's no limit on mean delay, so there are no parameters to spell that out explicitly 🙈
AccdDelayVariance is also modified by each intervening ST agent. It measures packet dispersion in milliseconds squared 📐 The target or origin can use it to decide whether the stream has a good enough quality of service to support the application. Same deal here: the requested delay variance is implicitly zero with no limit, so there are no explicit parameters for it 💜
DesPDUBytes is the desired PDU size in bytes. It's not necessarily the same as the minimum necessary PDU size 🌸 Intervening ST agents can make this value smaller, as long as it doesn't go below LimitOnPDUBytes. The *PDUBytes limits measure the size of the PDUs of the next-higher protocol layer, aka the user information inside a data packet. An ST agent must account for both the ST Header (including possible IP encapsulation) and any local network headers and trailers when comparing a network's MTU with *PDUBytes. In an ACCEPT message, this field's value will be no larger than the MTU of the path to the specified target 👑
DesPDURate is the requested PDU rate, expressed as tenths of a packet per second. Intervening ST agents may make it smaller, as long as it's not smaller than LimitOnPDURate 🍓
It is expected that the next parameter added to the FlowSpec will be a Burst Descriptor. It will describe how bursty the offered traffic is. For example, it might include the simple average rate, peak rate and variance values, or more complete descriptions that characterize the distribution of expected burst rates and how long they last. The algorithms that deal with burstiness, and the information this parameter needs to describe, will be subjects of further experimentation 🔥 It is expected that a new FlowSpec with Version = 4 will be defined that looks like Version 3 but has a Burst Descriptor parameter appended to the end ⭐
4.2.2.4. FreeHIDs ✨
The FreeHIDs parameter (PCode = 3) is used to communicate suggestions for a HID to the previous-hop. It consists of BaseHID and FreeHIDBitMask fields. Experiments will determine how long the mask should be for practical use of this parameter. The parameter (if implemented) should be included in all HID-REJECTs, and in HID-APPROVEs that are linked to a multicast CONNECT, e.g., one containing the MulticastAddress parameter 🦋
BaseHID was the suggested value in a HID-CHANGE or CONNECT. It's chosen to be the suggested HID value so that the masks from multiple FreeHIDs parameters will overlap 🧚
FreeHIDBitMask identifies available HID values like this: bit 0 corresponds to a HID with a value equal to BaseHID with the 5 least significant bits set to zero, bit 1 corresponds to that value + 1, and so on. Aligning the mask on a 32-bit boundary means masks from several FreeHIDs parameters can be combined with a bit-wise AND function to find a free HID. Iconic engineering 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 3 | 4+4*N | BaseHID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDBitMask :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25. FreeHIDs4.2.2.5. Group & RGroup 🌈
The Group parameter (PCode = 4) is an optional argument, used only when creating a stream. It contains a GroupName. The GroupName may be the same as the Name of one of the group's streams. There may also be some number of <SubGroupId, Relation> tuples that describe what the grouping means and how the members relate to each other. The forms of grouping are for further study 🫶
The RGroup parameter (PCode = 13) is an optional argument, used only when creating a stream in the reverse direction that is a member of a Group. See the FDx option, Section 3.6.3 (page 45). It has the same format as the Group parameter 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12+4*N | !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
! GroupName !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26. Group & RGroupA GroupName has the same format as a Name. See Figure 29 🦋
4.2.2.6. HID & RHID 🌸
The HID parameter (PCode = 5) is used in the NOTIFY message when the notification is related to a HID. It may also appear in the STATUS-RESPONSE message to convey additional HIDs that are valid for a stream when there's more than one. It consists of the PCode and PBytes bytes prepended to a HID. HIDs were described in Section 4 (page 76) ✨
The RHID parameter (PCode = 14) is used together with the FDx option to convey the HID that is to be used in the reverse direction. It consists of the PCode and PBytes bytes prepended to a HID 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4 | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27. HID & RHID4.2.2.7. MulticastAddress 🧚
The MulticastAddress parameter (PCode = 6) is an optional parameter. When setting up a network-level multicast group, it communicates an IP and/or local network multicast address to the next-hop agents that should become members of the group 🎀
LocalNetBytes is the length of the Local Net Multicast Address 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 6 | PBytes | LocalNetBytes | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Local Net Multicast Address : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28. MulticastAddressThe IP Multicast Address is described in [6]. This field is zero (0) if no IP multicast address is known or applicable. The block of addresses 224.1.0.0 - 224.1.255.255 has been allocated for use by ST 🌈
The Local Net Multicast Address is the multicast address to be used on the local network. It corresponds to the IP Multicast Address when the latter is non-zero 🫶
4.2.2.8. Name & RName 💜
Each stream is uniquely (i.e., globally) identified by a Name. A Name is created by the origin host ST agent and is made up of 1) a 16-bit number chosen to make the Name unique within the agent, 2) the IP address of the origin ST agent, and 3) a 32-bit timestamp. If the origin has multiple IP addresses, any that can be used to reach target may be used in the Name. The intent is that the <Unique ID, IP Address> tuple is unique for the lifetime of the stream. To increase robustness, it's suggested that a Unique ID value not be reused for a period of time on the order of 5 minutes 🔥
The Timestamp is included both to make the Name unique over long intervals (e.g., forever) for purposes of network management and accounting/billing, and to protect against failure of an ST agent that causes knowledge of active Unique IDs to be lost. The assumption is that all ST agents have access to some "clock". If that isn't the case, the agent should have access to some form of non-volatile memory where it can store some number that at least gets incremented per restart 🍓
The Name parameter (PCode = 7) is used in most control messages to identify a stream 💅
The RName parameter (PCode = 15) is used together with the FDx option to convey the Name of the reverse stream in an ACCEPT message ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12 | Unique ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 29. Name & RName 🎀
4.2.2.9. NextHopIPAddress ✨
okay so the NextHopIPAddress parameter is PCode = 8 💖 and it's an optional parameter of NOTIFY (RouteBack) or REFUSE (RouteInconsist or RouteLoop). it carries the IP address of a suggested next-hop ST agent, so it's basically the router going "psst, try this one next" 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 8 | 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 30. NextHopIPAddress 🌸
4.2.2.10. Origin 💜
the Origin parameter is PCode = 9 and its whole job is to tell you where the stream came from 🦋 It identifies the origin of the stream, the next higher protocol, and the SAP being used with that protocol. iykyk that's the stuff that makes demultiplexing work ✨
- NextPcol is an 8-bit field used in demultiplexing operations to identify the protocol to be used above ST. Its values live in the same number space as the IP Header's Protocol field, so they're defined in the Assigned Numbers RFC [18] 🧠
- OriginSAPBytes tells you the length of the OriginSAP, not counting any padding needed to keep things 32-bit aligned 🍓
- OriginIPAddress is (one of) the IP address of the origin 🌈
- OriginSAP identifies the origin's SAP associated with the NextPcol protocol 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 9 | PBytes | NextPcol |OriginSAPBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OriginSAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 31. Origin 💅
4.2.2.11. OriginTimestamp ⭐
the OriginTimestamp parameter (PCode = 10) is used to indicate the time at which the control message was sent. that's the whole vibe 🕰️
the units and format of the timestamp are the ones defined in the NTP protocol specification [13]. ngl this is where it gets spicy: discontinuities over leap seconds are expected 🙈
also, the time synchronization implied by using this parameter is the subject of systems management functions that aren't described in this memo, e.g., NTP. so the sync part is somebody else's job 💁♀️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 10 | 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Timestamp -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 32. OriginTimestamp 🫶
4.2.2.12. ReasonCode 💀
okay bestie, errors are gonna happen during protocol processing, and that's just life 😭 All ST error codes come from a single number space, so there's only one list to keep track of. Here's the list of currently defined values and what they mean. Note that new error codes may be defined from time to time, and all implementations are expected to handle new codes in a graceful manner. if you run into an unknown ReasonCode, it should be assumed to be fatal. no cap 🚨
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33. ReasonCode
Name Value Meaning
---------------- ----- ---------------------------------------
AcceptTimeout 2 An Accept has not been
acknowledged.
AccessDenied 3 Access denied.
AckUnexpected 4 An unexpected ACK was received.
ApplAbort 5 The application aborted the stream
abnormally.
ApplDisconnect 6 The application closed the stream
normally.
AuthentFailed 7 The authentication function
failed.
CantGetResrc 8 Unable to acquire (additional)
resources.
CantRelResrc 9 Unable to release excess
resources.
CksumBadCtl 10 A received control PDU has a bad
message checksum.
CksumBadST 11 A received PDU has a bad ST Header
checksum.
DropExcdDly 12 A received PDU was dropped because
it could not be processed within
the delay specification.
DropExcdMTU 13 A received PDU was dropped because
its size exceeds the MTU.
DropFailAgt 14 A received PDU was dropped because
of a failed ST agent.
DropFailHst 15 A received PDU was dropped because
of a host failure.
DropFailIfc 16 A received PDU was dropped because
of a broken interface.
DropFailNet 17 A received PDU was dropped because
of a network failure.
Name Value Meaning
---------------- ----- ---------------------------------------
DropLimits 18 A received PDU was dropped because
it exceeds the resource limits for
its stream.
DropNoResrc 19 A received PDU was dropped due to
no available resources (including
precedence).
DropNoRoute 20 A received PDU was dropped because
of no available route.
DropPriLow 21 A received PDU was dropped because
it has a priority too low to be
processed.
DuplicateIgn 22 A received control PDU is a
duplicate and is being
acknowledged.
DuplicateTarget 23 A received control PDU contains a
duplicate target, or an attempt to
add an existing target.
ErrorUnknown 1 An error not contained in this
list has been detected.
failure N/A An abbreviation used in the text
for any of the more specific
errors: DropFailAgt, DropFailHst,
DropFailIfc, DropFailNet,
IntfcFailure, NetworkFailure,
STAgentFailure, FailureRecovery.
FailureRecovery 24 A notification that recovery is
being attempted.
FlowVerBad 25 A received control PDU has a
FlowSpec Version Number that is
not supported.
GroupUnknown 26 A received control PDU contains an
unknown Group Name.
HIDNegFails 28 HID negotiation failed.
HIDUnknown 29 A received control PDU contains an
unknown HID.
Name Value Meaning
---------------- ----- ---------------------------------------
InconsistHID 30 An inconsistency has been detected
with a stream Name and
corresponding HID.
InconsistGroup 31 An inconsistency has been detected
with the streams forming a group.
IntfcFailure 32 A network interface failure has
been detected.
InvalidHID 33 A received ST PDU contains an
invalid HID.
InvalidSender 34 A received control PDU has an
invalid SenderIPAddress field.
InvalidTotByt 35 A received control PDU has an
invalid TotalBytes field.
LnkRefUnknown 36 A received control PDU contains an
unknown LnkReference.
NameUnknown 37 A received control PDU contains an
unknown stream Name.
NetworkFailure 38 A network failure has been
detected.
NoError 0 No error has occurred.
NoRouteToAgent 39 Cannot find a route to an ST
agent.
NoRouteToDest 40 Cannot find a route to the
destination.
NoRouteToHost 41 Cannot find a route to a host.
NoRouteToNet 42 Cannot find a route to a network.
OpCodeUnknown 43 A received control PDU has an
invalid OpCode field.
PCodeUnknown 44 A received control PDU has a
parameter with an invalid PCode.
ParmValueBad 45 A received control PDU contains an
invalid parameter value.
Name Value Meaning
---------------- ----- ---------------------------------------
PcolIdUnknown 46 A received control PDU contains an
unknown next-higher layer protocol
identifier.
ProtocolError 47 A protocol error was detected. PTPError 48 Multiple targets were specified
for a stream created with the PTP
option.
RefUnknown 49 A received control PDU contains an
unknown Reference.
RestartLocal 50 The local ST agent has recently
restarted.
RemoteRestart 51 The remote ST agent has recently
restarted.
RetransTimeout 52 An acknowledgment to a control
message has not been received
after several retransmissions.
RouteBack 53 The routing function indicates
that the route to the next-hop is
through the same interface as the
previous-hop and is not the
previous-hop.
RouteInconsist 54 A routing inconsistency has been
detected, e.g., a route loop.
RouteLoop 55 A CONNECT was received that
specified an existing target.
SAPUnknown 56 A received control PDU contains an
unknown next-higher layer SAP
(port).
STAgentFailure 57 An ST agent failure has been
detected.
StreamExists 58 A stream with the given Name or
HID already exists.
StreamPreempted 59 The stream has been preempted by
one with a higher precedence.
Name Value Meaning
---------------- ----- ---------------------------------------
STVerBad 60 A received PDU is not ST Version
2.
TooManyHIDs 61 Attempt to add more HIDs to a
stream than the implementation
supports.
TruncatedCtl 62 A received control PDU is shorter
than expected.
TruncatedPDU 63 A received ST PDU is shorter than
the ST Header indicates.
UserDataSize 64 The UserData parameter is too
large to permit a control message
to fit into a network's MTU.4.2.2.13. RecordRoute ✨
okay bestie, the RecordRoute parameter (PCode = 11) 🦋 is how you ask for the route between the origin and a target to get recorded and sent back to whoever is listed in the DetectorIPAddress field. so it's basically a little paper trail 📜💖
FreeOffset is the offset to the position where the next next-hop IP address should be inserted. it starts at four (4) and goes up by four every time an agent drops its IP address in. the way that it just keeps stacking up, iconic 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 11 | PBytes | 0 | FreeOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34. RecordRoute4.2.2.14. SrcRoute 🧭
the SrcRoute parameter is used, in the Target structure shown in Figure 36, to specify the IP addresses of the ST agents that the stream to the target should go through 🗺️ there are two flavours, and they're told apart by the PCode 💅
with loose source route (PCode = 18), each ST agent first checks the first next-hop IP address in the option. if that address is (one of) the address of the current ST agent, that entry gets removed and the PBytes field goes down by four (4). if the resulting PBytes field contains 4 (aka there are no more next-hop IP addresses), the parameter is removed from the Target. either way, the Target's TargetBytes field and the TargetList's PBytes field must be reduced accordingly. then the ST agent routes toward the first next-hop IP address in the option, if there is one, or toward the target otherwise. note that the target's IP address is not included as the last entry in the list 🫶
with a strict source route (PCode = 19), each ST agent first checks the first next-hop IP address in the option. if that address is not (one of) the address of the current ST agent, a routing error has happened and should be reported with the appropriate reason code 😭 otherwise that entry gets removed and the PBytes field goes down by four (4). if the resulting PBytes field contains 4 (no more next-hop IP addresses), the parameter is removed from the Target. either way, the Target's TargetBytes field and the TargetList's PBytes field must be reduced accordingly. then the ST agent routes toward the first next-hop IP address in the option, if there is one, or toward the target otherwise. and yes, the target's IP address is still not included as the last entry in the list 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4+4*N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35. SrcRoutesince a single hop between ST agents can actually be made of multiple IP hops using IP encapsulation, you might need to also specify an IP source routing option 🎀 there are two extra PCodes for that. see [15] for a description of IP routing options 📖
an IP Loose Source Route (PCode = 16) says that PDUs for the next-hop ST agent should be encapsulated in IP, and that the IP datagram should contain an IP Loose Source Route built from the list of IP router addresses in this option 🦋
an IP Strict Source Route (PCode = 17) is used in a similar way, for when the matching IP Strict Source Route option should be built 💜
so the "routing parameter" can be made of one or more separate parameters with PCodes 16, 17, 18, or 19. it's giving layers 🧁
4.2.2.15. Target and TargetList 🎯
several control messages use a parameter called TargetList (PCode = 20), and it holds info about the targets that the message is about 💖 for each Target in the TargetList, the info includes the IP addresses of the target, the SAP for the next higher layer protocol, the length of the SAP (SAPBytes), and zero or more optional SrcRoute parameters. see Section 4.2.2.14 (page 95). because of that, a Target structure can be any length 🌈 each entry looks like Figure 36.
the optional SrcRoute parameter only means something in CONNECT messages. if it shows up in other messages, they're ignored 🙈 also, the SrcRoute parameter(s) cut down how many Targets fit in a TargetList, since the max size of a TargetList is 256 bytes. so an implementation should be ready to accept multiple TargetLists in a single message 👑
⚠️ the vibe check: the TargetList has a hard 256-byte cap, so the more SrcRoutes you stuff in, the fewer targets fit. plan accordingly, bestie 💅
- TargetIPAddress is the IP Address of the Target.
- TargetBytes is the length of the Target structure, starting at the TargetIPAddress and including any SrcRoute Parameter(s).
- SAPBytes is the length of the SAP, not counting any padding needed to keep 32-bit alignment. i.e., no padding is needed for SAPs with lengths of 2, 6, etc., bytes 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetBytes | SAPBytes | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+
: SAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SrcRoute Parameter(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36. Targetok so we're assuming that ST agents must know the max packet size (the MTU) of the networks they're connected to, and those sizes will limit how many targets can be specified in control messages 🤏 we feel like that's not a serious drawback 💅 high bandwidth networks like the Ethernet or the Terrestrial Wideband network support packets big enough to fit well over one hundred targets, and we feel conferences with a bigger number of participants won't happen for quite some time ✨ we also expect future higher bandwidth networks to allow even larger packets 🚀
it may be desirable to send ST voice data packets in individual B-ISDN ATM cells, which are small 🦋 but network services on ATM will provide "adaptation layers" to do network-level fragmentation that may be used to carry larger ST control messages. ATM really said "we got you" 🫶🌸
Okay bestie, the TargetList is about to get split up, so let's see how it survives 🧩
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 20 | PBytes | TargetCount = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 37. TargetList
Here's the deal: if a message has to cross a network with a teeny maximum packet size, the message must get chopped up into multiple messages, each carrying a piece of the TargetList. The message can still do its job even when it's split up 💅 Splitting it does hurt performance, but everything still works properly ✨
For example, if a CONNECT got split up, the first CONNECT sets up the stream and the rest get treated as additions to that first one. The routing decisions might be sus, though, since they'd be based on partial info 💀 but the stream still gets created 🦋
4.2.2.16. UserData 🎀
UserData (PCode = 21) is an optional parameter that may be used by the next higher protocol or an application to send arbitrary info to its peers 💖 Note that since control messages are limited in size by the smallest MTU on the path to the target(s), the maximum size of this parameter can't be set in advance. If the parameter is too big for some network's MTU, a UserDataSize error will occur. The parameter must be padded to a multiple of 32 bits 🧚
UserBytes specifies the number of valid UserInformation bytes.
UserInformation is arbitrary data meaningful to the next higher protocol layer or application.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 21 | PBytes | UserBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserInformation : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 38. UserData
4.2.3. ST Control Message PDUs 🌸
Each control message gets its own section coming up, so keep reading 📖 For an explanation of the notation, check out Appendix 1 (page 147).
4.2.3.1. ACCEPT 🦋
ACCEPT (OpCode = 1) is what a target sends back as a positive response to a CONNECT message 💜 It means the target is ready to accept data from the origin along the stream the CONNECT set up. The ACCEPT carries the FlowSpec with the cumulative info the intervening ST agents calculated as the CONNECT made its way from origin to target, plus any changes the application at the target made. The ACCEPT gets relayed by the ST agents from the target back to the origin, along the same path the CONNECT took but in reverse. The ACCEPT must be acknowledged with an ACK at each hop 🔥
The FlowSpec doesn't get modified on the trip back from target to origin. Since the cumulative FlowSpec can be different for different targets, no attempt is made to combine the ACCEPTs from the various targets. The TargetList in each ACCEPT contains the IP address of only the target that issued that ACCEPT 👑
Any SrcRoute parameters in the TargetList are ignored 🙈
Since an ACCEPT might be the first response from a next-hop on a control link (thanks, network reordering), the SVLId field may be the first source of the Virtual Link Identifier to be used in the RVLId field of later control messages sent to that next-hop.
When the FDx option has been selected to set up a second stream in the reverse direction, the ACCEPT will contain both RFlowSpec and RName parameters. Each agent should update the state tables for the reverse stream with this info ✨
TSR (bits 14 and 15) specifies the target's response for the use of data packet timestamps; see Section 4 (page 76). Its values and semantics are:
00 Not implemented.
01 No timestamps are permitted.
10 Timestamps must always be present.
11 Timestamps may optionally be present.Reference contains a number assigned by the agent sending the ACCEPT, for use in the acknowledging ACK.
LnkReference is the Reference number from the corresponding CONNECT or CHANGE.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 1 | 0 |TSR| TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RFlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RName Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 39. ACCEPT Control Message
4.2.3.2. ACK 💖
ACK (OpCode = 2) is used to acknowledge a request. The Reference in the header is the Reference number of the control message being acknowledged 🫶
Since an ACK might be the first response from a next-hop on a control link, the SVLId field may be the first source of the Virtual Link Identifier to be used in the RVLId field of later control messages sent to that next-hop 🌈
ReasonCode is usually NoError, but other possibilities exist, e.g., DuplicateIgn.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 2 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 40. ACK Control Message
4.2.3.3. CHANGE-REQUEST 🍓
CHANGE-REQUEST (OpCode = 4) is used by an intermediate or target agent to ask the origin to change the FlowSpec of an established stream. The CHANGE-REQUEST message gets propagated hop-by-hop to the origin, with an ACK at each hop 🔥
Any SrcRoute parameters in the targets of the TargetList are ignored.
G (bit 8) is used to request a global, stream-wide change; the TargetList parameter may be omitted when the G bit is specified 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 4 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41. CHANGE-REQUEST Control Message4.2.3.4. CHANGE 🦋
Okay, so CHANGE (OpCode = 3) is how you tweak the FlowSpec of a stream that's already up and running ✨. It takes the same parameters as CONNECT, except the TargetList is NOT REQUIRED 💅. It gets processed pretty much like CONNECT, except it travels along the path of an established stream 🌸.
If the new FlowSpec asks less of the networks involved, the change is giving high probability of success along the established stream's path 💖. Each ST agent that gets a CHANGE makes the requested changes to its network resource allocations, and if that works, it passes the CHANGE along the established paths 🫶. If the change can't be made, the ST agent MUST recover using DISCONNECT and REFUSE messages, same as it would for a network failure 😭. A failure to change the resources for a specific target or targets SHOULD NOT cause the other targets in the stream to get deleted 🌈. The CHANGE MUST be ACKed 💅.
If the CHANGE is the result of a CHANGE-REQUEST, the LnkReference field of the CHANGE will contain the value from the Reference field of the CHANGE-REQUEST 🎀.
It is RECOMMENDED that the origin only have one outstanding CHANGE per target 🍓. If the application requests more than one to be outstanding at a time, it's the application's responsibility to deal with any sequencing problems that might pop up 🙈.
Any SrcRoute parameters in the targets of the TargetListParameter are ignored 🧚.
G (bit 8) is used to request a global, stream-wide change 👑. The TargetList parameter MAY be omitted when the G bit is specified 🫶.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 3 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42. CHANGE Control Message4.2.3.5. CONNECT 🌟
CONNECT (OpCode = 5) requests the setup of a new stream, an addition to an existing stream, or the recovery of one 🧚. Only the origin can issue the initial set of CONNECTs to set up a stream, and the first CONNECT to each next-hop is used to convey the initial suggestion for a HID 💅. If the stream's data packets will be sent to some set of next-hop ST agents by multicast, then the CONNECTs to that set MUST suggest the same HID 🫶. Otherwise, the HIDs in the various CONNECTs can be different ✨.
The CONNECT message MUST fit within the maximum allowable packet size (MTU) for the intervening network 🦋. If a CONNECT message is too large, it MUST be fragmented into multiple CONNECT messages by partitioning the TargetList; see Section 4.2 (page 77) 🍓. Any UserData parameter will be replicated in each fragment for delivery to all targets 💖.
The next-hop can initially respond with any of the following five responses:
ERROR-IN-REQUEST, which implies that theCONNECTwas not valid and has been ignored 😭.ACK, which implies that theCONNECTwith theHbit not set was valid and is being processed 🌸.HID-APPROVE, which implies that theCONNECTwith theHbit set was valid, and the suggested HID can be used or was deferred 👑.HID-REJECT, which implies that theCONNECTwith theHbit set was valid but the suggested HID cannot be used, and another must be suggested in a subsequentHID-CHANGEmessage 🙈.REFUSE, which implies that theCONNECTwas valid but the included list of targets in theREFUSEcannot be processed for the stated reason 🌈.
The next-hop will later relay back either an ACCEPT or a REFUSE from each target not already specified in the REFUSE of case 5 above. Note that multiple targets may be included in a single REFUSE message 💅.
An intermediate ST agent that receives a CONNECT selects the next-hop ST agents, partitions the TargetList accordingly, reserves network resources in the direction toward the next-hop (updating the FlowSpec accordingly; see Section 4.2.2.3 (page 81)), selects a proposed HID for each next-hop, and sends the resulting CONNECTs 🎀.
If the intermediate ST agent processing a CONNECT fails to find a route to a target, it responds with a REFUSE with the appropriate reason code 😭. If the next-hop to a target is by way of the network the CONNECT came from, then it sends a NOTIFY with the appropriate reason code (RouteBack) 🙈. Either way, the TargetList specifies the affected targets. The intermediate ST agent will only route to and propagate a CONNECT to the targets for which it does not issue either an ERROR-IN-REQUEST or a REFUSE 🫶.
Processing a received CONNECT takes real care, because you want to avoid routing loops that could come from delays in propagating routing information among ST agents 🚨.
If a received CONNECT contains a new Name, a new stream SHOULD be created (unless the Virtual Link Identifier matches a known link, in which case an ERROR-IN-REQUEST SHOULD be sent) 🦋. If the Name is known, there are four cases to think about 🔥:
- The Virtual Link Identifier matches and the Target matches a current Target. The duplicate target SHOULD be ignored 💅.
- The Virtual Link Identifier matches but the Target is new. The stream SHOULD be expanded to include the new target ✨.
- The Virtual Link Identifier differs and the Target matches a current Target. An
ERROR-IN-REQUESTmessage SHOULD be sent, specifying that the target is involved in a routing loop 😭. If it's a reroute, the old path will eventually time out and send aDISCONNECT, and a subsequent retransmission of the reroutedCONNECTwill then be processed under case 2 above 🌸. - The Virtual Link Identifier differs but the Target is new. A new (instance of the) stream SHOULD be created for the target, which is deliberately part of a loop using a
SrcRouteparameter 🌈.
Note that the test for a known or matching Target includes comparing any SrcRoute parameter that might be present 🎀.
Option bits are specified by either the origin's service user or an intermediate agent, depending on the specific option 💜. Bits not specified below are currently unspecified, and SHOULD be set to zero (0) by the origin agent and not changed by other agents unless those agents know what they mean 🙈.
H(bit 8) is used for the HID Field option; see Section 3.6.1 (page 44) 💖. It is set to one (1) only if the HID field contains either zero (when the HID selection is being deferred) or the proposed HID. This bit is zero (0) if the HID field does not contain valid data, and the field SHOULD be ignored 🫶.P(bit 9) is used for the PTP option; see Section 3.6.2 (page 44) 🦋.S(bit 10) is used for the NoRecovery option; see Section 3.6.4 (page 46) 💅.TSP(bits 14 and 15) specifies the origin's proposal for the use of data packet timestamps; see Section 4 (page 76) ✨. Its values and semantics are:
00 No proposal.
01 Cannot insert timestamps.
10 Must always insert timestamps.
11 Can insert timestamps if requested.RVLId, the receiver's Virtual Link Identifier, is set to zero in all CONNECT messages until its value arrives in the SVLId field of an acknowledgment to the CONNECT 🌸.
SVLId, the sender's Virtual Link Identifier, is set to a value chosen by each hop to make dispatching of subsequent control messages efficient 🧚.
HID is the identifier that will be used with data packets moving through the stream in the direction from the origin to the targets 💜. It's a hop-by-hop shorthand identifier for the stream's Name, and each agent chooses it for the branch to the next-hop agents 👑. The contents of the HID field are only valid, and a HID-REJECT or HID-APPROVE reply MAY only be sent, when the HID Field option (H bit) is set (1) 🔥. If the HID Field option is specified and the proposed HID is zero, the selection of the HID is deferred to the receiving next-hop agent 🙈. If the HID Field option is not set (H bit is 0), then the HID field does not contain valid data and SHOULD be ignored; see Section 3.6.1 (page 44) 🎀.
TargetList is the list of IP addresses of the target processes, bestie 🎯 and it can be any size you want, up to whatever the maximum is for packets traveling across that specific network 🌐
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 5 |H|P|S| 0 |TSP| TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Origin Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Group Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MulticastAddress Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RFlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RGroup Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! RHID Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 43. CONNECT Control Message 🎀
4.2.3.6. DISCONNECT 💜
Okay so DISCONNECT (OpCode = 6) is the message an origin uses to tear down an established stream (or just part of one), or an intermediate agent uses when it notices a failure between itself and its previous-hop. The ReasonCode is what tells those two situations apart 💅
It names the list of targets that are to be disconnected 🎯 An ACK is required in response to a DISCONNECT message, and the DISCONNECT message gets propagated all the way to the specified targets. The targets are expected to bounce out of the stream 🦋
Heads up: if it's a failure, it may be advantageous to keep the state information around, since the stream should be repaired shortly. See Section 3.7.2 (page 52) 💖
G (bit 8) is the switch for asking to DISCONNECT all of the stream's targets 🌸 When G is set (1), the TargetList parameter can be left out.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 6 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 44. DISCONNECT Control Message ✨
4.2.3.7. ERROR-IN-REQUEST 😭
ERROR-IN-REQUEST (OpCode = 7) gets sent back as the acknowledgment to a request where an error was detected. Nothing is done with the erroneous request and no state for the stream is kept, so it's appropriate for the SVLId to be zero (0). No ACK is expected.
An ERROR-IN-REQUEST is never sent in response to either an ERROR-IN-REQUEST or an ERROR-IN-RESPONSE 🙅 but the event should still be logged for diagnostic purposes. The receiver of an ERROR-IN-REQUEST is encouraged to try again without waiting for a retransmission timeout 🏃♀️
Reference is the Reference number of the request that went wrong.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 7 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 45. ERROR-IN-REQUEST Control Message 🧚
4.2.3.8. ERROR-IN-RESPONSE 🙈
ERROR-IN-RESPONSE (OpCode = 8) gets sent back as the acknowledgment to a response where an error was detected. No ACK is expected. What the requester and responder do next depends on the nature of the request 🍓
An ERROR-IN-REQUEST is never sent in response to either an ERROR-IN-REQUEST or an ERROR-IN-RESPONSE 🙅 but the event should still be logged for diagnostic purposes. The receiver of an ERROR-IN-RESPONSE is encouraged to try again without waiting for a retransmission timeout 🏃♀️
Reference identifies the erroneous response.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 8 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 46. ERROR-IN-RESPONSE Control Message 🌈
4.2.3.9. HELLO 🔍
HELLO (OpCode = 9) helps with the ST failure detection mechanism 🔍 see Section 3.7.1.2 (page 49).
R (bit 8) is the Restarted bit 🔄
If Reference is non-zero, it tells the receiver to send an ACK promptly so the sender can update its round-trip time estimates ⏱️ If Reference is zero, no ACK should be sent.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 9 |R| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference/0 | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloTimer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! OriginTimestamp !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 47. HELLO Control Message 💖
4.2.3.10. HID-APPROVE ✨
okay so HID-APPROVE (OpCode = 10) is the message an agent sends when it's replying to either a CONNECT or a HID-CHANGE with a big fat yes 💅. That yes can mean going ahead with the proposed HID, or adding or deleting the specified HID. In every case except deletion, the newly approved HID gets sent back in the HID field. For deletion, the HID field MUST be set to zero 🙈. HID-APPROVE is the acknowledgment of a CONNECT or HID-CHANGE, so it's the reply that closes the loop 🫶.
The optional FreeHIDs parameter gives the previous-hop agent hints about which other HIDs are acceptable, just in case a multicast HID is being negotiated 🦋. Check Section 4.2.2.4 (page 84) for the deets ✨.
Since a HID-APPROVE might be the first response from a next-hop on a control link, the SVLId field MAY be the first source of the Virtual Link Identifier you'll use in RVLId for later control messages to that next-hop 🧚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 10 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDs Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 48. HID-APPROVE Control Message 🌸
4.2.3.11. HID-CHANGE-REQUEST ✨
HID-CHANGE-REQUEST (OpCode = 12) is what a next-hop agent sends when it would like to change the HID that's in use, for administrative reasons 📋. The receiving previous-hop agent answers with an ERROR-IN-REQUEST if it's unwilling to make the change, or with a HID-CHANGE if it can accommodate the request 💅.
Here's how the bits work 🎀:
A(bit 8) means the specified HID SHOULD be included in the set of HIDs for the specified Name. When a HID is added, the acknowledging HID-APPROVE SHOULD contain aHIDfield holding the HID that was just added.D(bit 9) means the specified HID SHOULD be removed from the set of HIDs for the specified Name. When a HID is deleted, the acknowledging HID-APPROVE SHOULD contain aHIDfield set to zero. Note that theReferencefield MAY be used to figure out which HID got deleted 🔍.- If neither bit is set, the specified HID SHOULD replace the one currently in use with the specified Name 🔄.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 12 |A|D| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 49. HID-CHANGE-REQUEST Control Message 🦋
4.2.3.12. HID-CHANGE ✨
HID-CHANGE (OpCode = 11) is used by the agent that sent a CONNECT and got a HID-REJECT back. It's how that agent tries to negotiate a suitable HID 🧚. The HID in the HID-CHANGE MUST be different from the one in the CONNECT, or from any previous HID-CHANGE messages for the given Name. The agent receiving the HID-CHANGE MUST respond with a HID-APPROVE if the new HID is suitable, or a HID-REJECT if it isn't. If something goes wrong, either an ERROR-IN-REQUEST or a REFUSE MAY be returned as the acknowledgment 🙅.
Since an agent MAY send CONNECT messages with the same HID to several next-hops in order to use multicast data transfer, any HID-CHANGE MUST also be sent to that same set of next-hops 💖. So a next-hop agent MUST be prepared to receive a HID-CHANGE either before or after it has sent a HID-APPROVE response to the CONNECT or a previous HID-CHANGE. Only the last HID-CHANGE matters, and the previous-hop agent will ignore HID-APPROVE or HID-REJECT messages for earlier CONNECT or HID-CHANGE messages 🙈.
A DISCONNECT can be sent instead of a HID-CHANGE, or a REFUSE can be sent instead of a HID-APPROVE or HID-REJECT. Either one fatally ends the HID negotiation and the agent's knowledge of the stream 💀.
The A and D bits are used to change a HID, for example when adding a new next-hop to a multicast group. This is done so that data packets flowing through the network don't get mishandled because of a race condition while HID-CHANGE messages are processed between the previous-hop and its next-hops 🌈. An implementation MAY choose to limit the number of simultaneous HIDs associated with a stream, but it MUST allow at least two 👑.
A(bit 8) means the specified HID SHOULD be included in the set of HIDs for the specified Name. When a HID is added, the acknowledging HID-APPROVE SHOULD contain aHIDfield holding the HID that was just added.D(bit 9) means the specified HID SHOULD be removed from the set of HIDs for the specified Name. When a HID is deleted, the acknowledging HID-APPROVE SHOULD contain aHIDfield set to zero. Note that theReferencefield MAY be used to figure out which HID got deleted 🔍.- If neither bit is set, the specified HID SHOULD replace the one currently in use for the specified Name 🔄.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 11 |A|D| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 50. HID-CHANGE Control Message 🎀
4.2.3.13. HID-REJECT ✨
HID-REJECT (OpCode = 13) is the acknowledgment that a CONNECT or HID-CHANGE was received and is being processed. It also means the HID in that CONNECT or HID-CHANGE is NOT acceptable 🙅♀️. Once the agent that issued the CONNECT or HID-CHANGE gets this, it MUST now issue a HID-CHANGE to try to find a suitable HID. That HID-CHANGE can cause another HID-REJECT, but eventually the HID-CHANGE MUST be acknowledged with a HID-APPROVE to successfully wrap up the HID negotiation 🏁. The agent that issued the HID-REJECT MAY NOT issue an ACCEPT until it has found an acceptable HID.
Since a HID-REJECT might be the first response from a next-hop on a control link, the SVLId field MAY be the first source of the Virtual Link Identifier to be used in the RVLId field of subsequent control messages sent to that next-hop 🧚.
Either agent MAY end the negotiation by issuing a DISCONNECT or a REROUTE. The agent that issued the HID-REJECT MAY issue a REFUSE, or a REROUTE, at any time after the HID-REJECT. When that happens, the stream can't be created, the HID negotiation doesn't need to keep going, and the previous-hop doesn't need to send any more messages. Any further messages that come in SHOULD be ignored 🙈✨
The OPTIONAL FreeHIDs parameter is the previous-hop agent slipping the next agent a hint about which HIDs would have been acceptable 💅 For the deets, check out Section 4.2.2.4 (page 84) 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 13 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | RejectedHID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDs Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 51. HID-REJECT Control Message 🎀
4.2.3.14. NOTIFY 🔔
Okay so NOTIFY (OpCode = 14) is what an agent sends to tell other agents, the origin, or the target(s) about events that MAY be significant 👀 What the receiver does depends on the ReasonCode, no cap. The events we're talking about are suspected routing problems or resource allocation changes that happen after a stream is already up. These pop up when network components fail, and when competing streams preempt resources that a lower precedence stream had reserved. We also expect NOTIFY can be used later when more resources free up, like when network components recover or when higher precedence streams get deleted 🌈
NOTIFY MAY contain a FlowSpec that reflects the revised guarantee that can be promised to the stream. NOTIFY MAY also identify the targets affected by the change. So it's kinda giving ACCEPT vibes ✨
NOTIFY MAY be relayed by the ST agents back to the origin, along the path the CONNECT made but in the reverse direction 🦋 It's up to the origin to decide whether a CHANGE SHOULD be submitted.
When NOTIFY reaches the origin, the application SHOULD be notified of the target and the change in resources allocated along the path to it, as described in the FlowSpec inside the NOTIFY message. The application MAY then use that info to either adjust or terminate the portion of the stream to each affected target 💅
The NOTIFY MAY be propagated beyond the previous-hop or next-hop agent. It MUST be acknowledged with an ACK 🫶
Referencecontains a number the sending agent assigns, which gets used in the acknowledging ACK.ReasonCodeidentifies the reason for the notification.LnkReference, when non-zero, is the Reference number from a command that is the subject of the notification.HIDis present when the notification is related to a HID.Nameis present when the notification is related to a stream.NextHopIPAddressis an OPTIONAL parameter that contains the IP address of a suggested next-hop ST agent.TargetListis present when the notification is related to one or more targets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 14 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! HID Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! NextHopIPAddress Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 52. NOTIFY Control Message 🍓
4.2.3.15. REFUSE 🙅♀️
Okay bestie, REFUSE (OpCode = 15) is sent by a target that either doesn't want to accept a CONNECT message or wants to remove itself from an established stream. An intermediate agent might send it too, in response to a CONNECT or CHANGE, to fatally end a failing HID negotiation, to end a routing loop, or when it can't find a satisfactory next-hop to a target. It MAY also be a separate command when an existing stream has been preempted by a higher precedence stream, or when an agent detects the failure of a previous-hop, next-hop, or the network between them. In all cases, the TargetList says which targets are affected by the condition. Each REFUSE MUST be acknowledged by an ACK 💖
The REFUSE gets relayed by the agents from the originating agent to the origin (or the intermediate agent that created the CONNECT or CHANGE), along the path the CONNECT traced. The agent that receives the REFUSE handles it differently depending on the condition that caused it, as spelled out in the ReasonCode field. Sometimes, like when a next-hop can't get resources, the agent can release any resources reserved exclusively for transmissions in that stream to the target in the TargetList, and the previous-hop can try to find an alternate route. Other times, like a routing failure, the previous-hop can't tell where the failure happened, so it MUST propagate the REFUSE back to the origin, which can try to recover the stream by sending a new CONNECT 🔥
No special effort is made to combine multiple REFUSE messages, since it's considered super unlikely that separate REFUSEs both pass through an agent at the same time and can be easily combined, e.g., they have identical ReasonCodes and parameters 🙈
Since a REFUSE might be the first response from a next-hop on a control link, the SVLId field MAY be the first source of the Virtual Link Identifier used in the RVLId field of later control messages sent to that next-hop 🌸
Referencecontains a number the sending agent assigns, which gets used in the acknowledging ACK.LnkReferenceis either the Reference number from the corresponding CONNECT or CHANGE, if the REFUSE is the result of one of those messages, or zero when the REFUSE was originated as a separate command.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 15 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ErroredPDU :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 53. REFUSE Control Message 🧚
4.2.3.16. STATUS 🧐
STATUS (OpCode = 16) is used to ask whether a particular stream exists 👀 You identify that stream either by a HID (H bit set) or by a Name (Name Parameter present) ✨
Okay so when a stream has been found, the STATUS-RESPONSE comes back with the HID and/or Name you asked for and literally nothing else if the stream is unknown 🫠. If it is real, it's giving full details: the current HID(s), Name, FlowSpec, TargetList, and maybe Group(s) 🎀. Quick note: if a stream has no current HID, the HID field just shows zero. If there's a valid HID, the first (or only) one goes in the HID field, and any extra valid HIDs ride along in HID parameters 💅.
STATUS is for diagnostics and cleaning up streams, so it's not a sending-it-everywhere kind of thing 🧹. Heads up: if you send both a HID and a Name, and they don't belong to the same stream, you get an ERROR-IN-REQUEST with the InconsistHID reason code 😬.
Things can get messy 🌀 with multiple failures or network partitions. An ST agent might still think a stream exists after it's gone or been rerouted around it 👻. So when an agent decides a stream hasn't been used in a while and might not be valid anymore, it can poke the stream's previous-hop or next-hop(s) and ask if they still think the stream goes through it ✨. If they don't, they reply with a STATUS-RESPONSE holding the HID and/or Name and no other parameters. If the stream is still alive, they send back the stream's parameters instead 🦋.
H (bit 8) tells you whether there's a HID in the HID field: 1 means yes, 0 means no 🌸.
Q (bit 9) is the remote diagnostics flag 🔍. Set it to one (1) and the receiving agent should send back the stream's parameters, even if the sender isn't a previous-hop or next-hop on that stream. Be careful though, because this has potential for disclosure of sensitive information 🙈.
RVLId and SVLId can be zero, or both can, when STATUS is used for diagnostics 🧚.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 16 |H|Q| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 54. STATUS Control Message
4.2.3.17. STATUS-RESPONSE ✨
STATUS-RESPONSE (OpCode = 17) is the reply to a STATUS message 💌. If the stream in the STATUS message isn't known, the reply has the specified HID and/or Name and no other parameters. Otherwise, it carries the current HID(s), Name, FlowSpec, TargetList, and maybe Group of the stream 🎀. If the stream has no current HID, the H bit in the STATUS-RESPONSE is zero. The HID field holds the first (or only) valid HID, and any additional valid HIDs come back in HID parameters 🦋.
H (bit 8) tells you whether a HID is in the HID field: 1 for yes, 0 for no 🌸.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 17 |H|Q| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId/0 | SVLId/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | HID/0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Group Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! HID Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 55. STATUS-RESPONSE Control Message
4.3. Suggested Protocol Constants 🧁
The ST Protocol has a few fields that need exact values to work, plus some values each implementation gets to pick 🎯. This section lists the required values and suggests starting values for the rest. The suggested values should be implemented as variables, so they're easy to change once experience shows better ones 🔧. Eventually they should be managed through the normal network management facilities 📊.
ST uses IP Version Number 5 🌊.
When it's encapsulated in IP, ST uses IP Protocol Number 5 🫶.
Value ST Command Message Name Value ST Element Name
------- ----------------------- ------- ---------------------
1 ACCEPT 1 ErroredPDU
2 ACK 2 FlowSpec
3 CHANGE 3 FreeHIDs
4 CHANGE-REQUEST 4 Group
5 CONNECT 5 HID
6 DISCONNECT 6 MulticastAddress
7 ERROR-IN-REQUEST 7 Name
8 ERROR-IN-RESPONSE 8 NextHopIPAddress
9 HELLO 9 Origin
10 HID-APPROVE 10 OriginTimestamp
11 HID-CHANGE 11 RecordRoute
12 HID-CHANGE-REQUEST 12 RFlowSpec
13 HID-REJECT 13 RGroup
14 NOTIFY 14 RHID
15 REFUSE 15 RName
16 STATUS 16 SrcRoute, IP Loose
17 STATUS-RESPONSE 17 SrcRoute, IP Strict
18 SrcRoute, ST Loose
19 SrcRoute, ST Strict
20 TargetList
21 UserDataFiguring out the minimum number of bits in the FreeHIDBitMask element of the FreeHIDs parameter is still an open question 🤷♀️. The suggestion is a minimum of 64 bits, meaning N in Figure 25 has a value of two (2) 🔢.
HID value zero (0) is reserved for ST Control Messages 🔒. HID values 1-3 are reserved for future use 🔮.
VLId value zero (0) may only be used in the RVLId field of an ST Control Message when the right value hasn't been received from the other end of the virtual link yet 💫. Except for an ERROR-IN-REQUEST or diagnostic message, the SVLId field must never contain zero, and diagnostic messages are the only exception there 🙅♀️. VLId value 1 is reserved for HELLO messages, for agents that want every HELLO labeled that way 👋. VLId values 2-3 are reserved for future use 🌱.
The following permanent IP multicast addresses have been assigned to ST 📮:
224.0.0.7 All ST routers
224.0.0.8 All ST hostsThere's also a block of transient IP multicast addresses, 224.1.0.0 - 224.1.255.255, allocated for ST multicast groups 🌈. For Ethernet, an ST Multicast address of 224.1.cc.dd maps to an Ethernet Multicast address of 01:00:5E:01:cc:dd (see [6]) 🧵.
SCMP uses retransmission for reliability, so it has several "retransmission timers" ⏰. Each "timer" is modeled by an initial time interval (ToXxx), which gets updated dynamically as control traffic is measured, plus a number of times (NXxx) to retransmit a message before declaring a failure 💀. All time intervals are in milliseconds ⏱️.
Value Timeout Name Meaning
------- ---------------------- ----------------------------------
1000 ToAccept Initial hop-by-hop timeout for
acknowledgment of ACCEPT
3 NAccept ACCEPT retries before failure
1000 ToConnect Initial hop-by-hop timeout for
acknowledgment of CONNECT
5 NConnect CONNECT retries before failure
1000 ToDisconnect Initial hop-by-hop timeout for
acknowledgment of DISCONNECT
3 NDisconnect DISCONNECT retries before
failure
Value Timeout Name Meaning
------- ---------------------- ----------------------------------
1000 ToHIDAck Initial hop-by-hop timeout for
acknowledgment of
HID-CHANGE-REQUEST
3 NHIDAck HID-CHANGE-REQUEST retries
before failure
1000 ToHIDChange Initial hop-by-hop timeout for
acknowledgment of HID-CHANGE
3 NHIDChange HID-CHANGE retries before
failure 1000 ToNotify Initial hop-by-hop timeout for
acknowledgment of NOTIFY
3 NNotify NOTIFY retries before failure
1000 ToRefuse Initial hop-by-hop timeout for
acknowledgment of REFUSE
3 NRefuse REFUSE retries before failure
1000 ToReroute Timeout for receipt of ACCEPT or
REFUSE from targets during
failure recovery
5 NReroute CONNECT retries before failure
5000 ToEnd2End End-to-End timeout for receipt
of ACCEPT or REFUSE from targets
by origin
0 NEnd2End CONNECT retries before failure
Value Parameter Name Meaning
------- ---------------------- ----------------------------------
10 NHIDAbort Number of rejected HID proposals
before aborting the HID
negotiation process
10000 HelloTimerHoldDown Interval that Restarted bit must
be set after ST restart
5 HelloLossFactor Number of consecutively missed
HELLO messages before declaring
link failure
2000 DefaultRecoveryTimeout Interval between successive
HELLOs to/from active neighbors
2 DefaultHelloFactor HELLO filtering function factor5. Areas Not Addressed ✨
okay so there's a whole pile of stuff that needs sorting out eventually 🫶 but this doc isn't gonna tackle it. some of it is network-specific or implementation-specific. like, how multicast groups get managed depends on what interface the network hands the ST agent, and an UP/DOWN protocol built on ST HELLO messages depends on the nitty-gritty details of the ST agents 🧚. both of those can affect implementations, but we don't think it's right to pin them down here.
other stuff is just not clear yet, so no solution yet 🙈 these are the big ones:
This document does not include a routing mechanism. we don't think a routing strategy that just minimizes the number of hops from source to destination is necessarily the move 💅 an alternative is minimizing the consumption of internet resources while staying within some delay constraints. and honestly it would be way better if routing looked at bandwidth, delay, reliability, and maybe other stuff too, not just connectivity 🌸 that would make a selected route more likely to actually succeed. the catch is this would probably make the ST agents swap a lot more routing info than they do right now. we think more research and experimentation is needed before a routing strategy is well enough defined to go into the ST spec.
Once the bandwidth for a stream has been agreed on, it is not sufficient to rely on the origin to send traffic at that rate 😭 the internet should not rely on the origin to operate properly. even if the origin does send at the agreed rate, packets can bunch up unintentionally and cause local congestion. there are a few ways to deal with this, like metering the traffic in each stream as it passes through each agent. experimentation is needed before picking one of those mechanisms.
The interface between the agent and the network is very limited 🦋 there's a mechanism where the ST layer can ask the network how likely it is that a stream can be supported. but this facility will need some real-world experience before anyone can define how to use it properly.
The simplex tree model of a stream doesn't easily allow for multiple paths to get more bandwidth, and that's kinda a vibe-killer ngl 💀 at any given point in a stream, the entire incoming bandwidth has to go to the same next-hop to reach some target. if the bandwidth isn't available along any single path, the stream can't be built to that target. but it might be that the bandwidth isn't there on one path, while splitting the data across multiple paths (and so multiple next-hops) would have enough bandwidth. as it's currently specified, the ST agent where those flows converge will refuse the second connection, because it can only be read as a routing failure. a mechanism that allows multiple paths in a stream and can still protect against routing failures has not been defined yet.
If there isn't enough bandwidth, both preemption and rerouting are possible 🔥 but it's not clear when to use one or the other. as currently specified, an ST agent that can't get enough bandwidth will try to preempt lower precedence streams before it tries rerouting around the bottleneck. that could lead to an undesirably high number of preemptions 😬 a higher precedence stream might be able to reroute around the lower precedence streams and still meet its performance requirements, while the preempted lower precedence streams can't be rebuilt and still meet theirs. a simple and effective algorithm to make a better call hasn't been identified.
If a stream can't be completed, ST doesn't really tell the application what went wrong 🙃 not in any great detail anyway. specifically, the application can't figure out where the bottleneck is, whether the problem is permanent or temporary, or roughly how long it might take to get resolved. the application can only try to build the stream again later and hope the trouble has cleared up. schemes could be imagined where info gets relayed back to the application, but only practical experience can show what kind of trouble is most likely and what info would actually be most useful to the app ✨
There's also no mechanism for cases where a stream can't be completed, not because of a lack of resources, but because of an unexpected failure that results in an ERROR-IN-REQUEST message. an ERROR-IN-REQUEST message comes back when an ST agent sends a malformed control message to a neighbor. that's unexpected, and it might be caused by a bad or incomplete ST implementation 🧐 in some cases a message like NOTIFY should be sent to the origin. this isn't defined because it isn't clear what information can be pulled out of it, or what the origin should even do with it.
No special action is taken when a target is removed from a stream 🍓 removing a target might also remove a bottleneck, whether it's in bandwidth, packet rate, or packet size, but nobody takes advantage of that opportunity automatically. the application can start a change to the stream's characteristics, but it isn't really in the best position to do that, since it might not know what the bottleneck is. the ST layer might have the best info, but a mechanism to do this could get super complex. so this one needs more thought.
An agent just throws away a stream's data packets if it can't forward them 🗑️ that could happen because the packets are too big or they're coming in too fast. other options could include trying to do something with the packets, like fragmenting them, or telling the origin about the trouble. fixing things on the spot might be too complex, so it may be better to just notify the origin with a NOTIFY message. but if the incoming packet rate is what's causing the congestion, then the NOTIFY messages themselves might cause even more trouble 😭 how the communication should work hasn't been defined yet.
The FlowSpec has a cost field, but nobody has figured out how it should be implemented 💸 the units of cost can probably be defined pretty easily, and the cost of bandwidth can probably be assigned too. it's less clear how cost gets assigned to other things, like high precedence or low delay, or how the costs of the different components of a stream get combined. it's obvious that the cost of providing services is going to matter more soon, but how that cost is determined isn't clear right now.
A bunch of FlowSpec parameters are meant to be used as ranges, but some might be more useful as discrete values 🎀 for example, the FlowSpec might say bandwidth for a voice stream should be reserved in a range from 16Kbps to 64Kbps, because the voice codec has a variable coding rate. but the voice codec might only switch among certain discrete values, like 16Kbps, 32Kbps, and 64Kbps. a stream with 48Kbps of bandwidth is no better than one with 32Kbps 🙄 the FlowSpec parameters where this might matter should optionally specify discrete values. this is being considered.
Groups are defined as a way to associate different streams, but what the association actually means is left for future study 👑 one example is letting streams whose traffic is inherently not simultaneous share the same allocated resources. that could happen in a conference with an explicit floor, so only one site can generate video or audio at any given time. the grouping facility can be implemented based on this spec, but using groups for those kinds of things will need new functionality added to the ST agents. the uses for groups, and the implementation to support them, will be worked out as experience is gained and the need comes up.
We hope that the ST we propose here will act as a vehicle for studying the use and performance of stream oriented services across packet switched networks 💜
[This page intentionally left blank.]
6. Glossary 🧚
appropriate reason code This phrase refers to one reason code, or maybe a set of them, that indicate why a particular action is being taken. usually these come from detecting errors or anomalous conditions. it can also mean that an application component or agent has presented invalid parameters.
DefaultRecoveryTimeout The DefaultRecoveryTimeout is maintained by each ST agent. it's the default time interval to use for sending HELLO messages 🌈
downstream The direction in a stream from an origin toward its targets 🦋
element The fields and parameters of the ST control messages are collectively called elements ✨
FlowSpec The Flow Specification, abbreviated "FlowSpec", is how an application specifies the required and desired characteristics of the stream 💖 it specifies bandwidth, delay, and reliability parameters. both minimal requirements and desired characteristics are included. this info is then used to guide route selection and resource allocation decisions. the desired vs. required characteristics are used to guide tradeoff decisions among competing stream requests 🎀
group 🎀
Okay so a bunch of related streams can get grouped together! ✨ You do this by generating a Group Name and slapping it on every stream in the group. 🫶 The grouping info can then be used by the ST agents when they're making resource management and other control decisions. Like, when you need to preempt something to set up a high precedence stream, you can use the group info to minimize how many stream groups get preempted. Iconic. 💅
Group Name 🌸
The Group Name tells everyone that a collection of streams is related. 🦋 It's structured to be unique across all hosts: it has the address of the host where it was generated, combined with a unique number that host generated. Then a timestamp gets added so the whole thing is unique over all time. 😭 (A Group Name has the same format as a stream Name, btw.)
HelloLossFactor 💜
The HelloLossFactor is a parameter each ST agent keeps track of. It's the expected number of consecutive HELLO messages typically lost due to transient factors. So an agent gets assumed to be down once we miss more than HelloLossFactor messages. 🙈
HelloTimer ⏱️
The HelloTimer is a millisecond timer each ST agent maintains, and it's included in every HELLO message. It represents the time since the agent was restarted, modulo the precision of the field. ✨ It's used to detect variations in the delay between the two agents, by comparing the arrival interval of two HELLO messages to the difference between their HelloTimer fields. Very mathy, very cute. 🧚
HelloTimerHoldDown 🍓
Each ST agent maintains the HelloTimerHoldDown value. When an ST agent gets restarted, it sets the "Restarted" bit in all HELLO messages it sends for HelloTimerHoldDown seconds. 🔥
HID 🔑
The Hop IDentifier, or HID for short, is a numeric key stored in the header of each ST packet. An ST agent uses it to associate the packet with one of the incoming hops the agent manages. A receiving agent can use it to map to the set of outgoing next-hops the message should be forwarded to. ✨ The HID field of an ST packet will generally need to be changed as it passes through each ST agent, since there may be many HIDs associated with a single stream. Main character energy, honestly. 👑
hop 🛤️
A "hop" is the portion of a stream's path between two neighbor ST agents. It's usually represented by a physical network. 🌈 A multicast hop can connect a single ST agent to several next-hop ST agents though, so it's not always one-to-one. 🦋
host agents 🫧
Synonym for host ST agents. Same bestie, shorter name. 💖
host ST agents 🏠
Host ST agents are the ST agents that provide services to higher layer protocols and applications. 💅 These services include ways to source data from and sink data to the higher layer or application, plus ways to request and modify streams. Basically the ones who talk to the apps. 🎀
intermediate agents 🌷
Synonym for intermediate ST agents. ✨
intermediate ST agents 🔀
Intermediate ST agents are the ST agents that can forward ST packets between the networks they're attached to. 🧚
MTU 📏
MTU stands for Maximum Transmission Unit, which is the maximum packet size in bytes that a given network can accept for transmission. 🫶 ST agents work out the maximum packet size for a stream so that data written to the stream can be forwarded through the networks without fragmentation. Iykyk. 🙈
multi-destination simplex 📡
The topology and data flow of ST streams are described as multi-destination simplex. 💜 All data on the stream comes from a single origin and gets passed to one or more destination targets. Only control information, which is invisible to the application program, ever travels in the upstream direction. 🔥
NAccept 🔁
NAccept is an integer parameter each ST agent maintains, and it controls retransmission of an ACCEPT message. Since an ACCEPT request is relayed by agents back toward the origin, it must be acknowledged by each previous-hop agent. ✨ If that ACK isn't received within the appropriate timeout interval, the request gets resent up to NAccept times before giving up. Persistent, but make it make sense. 💅
Name 🎀
Name generally refers to the name of a stream. A stream Name is structured to be unique across all hosts: it includes the address of the host where it was generated, combined with a unique number generated at that host. 🦋 A timestamp gets added so the overall Name is unique over all time. (A stream Name has the same format as a Group Name, as we said. 💖)
NConnect 📞
NConnect is an integer parameter each ST agent maintains, and it controls retransmission of a CONNECT message. A CONNECT request must be acknowledged by each next-hop agent as it's propagated toward the targets. 🌸 If a HID-ACCEPT, HID-REJECT, or ACK isn't received for the CONNECT between any two agents within the appropriate timeout interval, the request gets resent up to NConnect times before giving up. 😭
NDisconnect 👋
NDisconnect is an integer parameter each ST agent maintains, and it controls retransmission of a DISCONNECT message. A DISCONNECT request must be acknowledged by each next-hop agent as it's propagated toward the targets. 🫶 If this ACK isn't received for the DISCONNECT between any two agents within the appropriate timeout interval, the request gets resent up to NDisconnect times before giving up. Bye bye, but politely. 💜
next protocol identifier 🪪
The next protocol identifier is used by a target ST agent to figure out which of several higher layer protocols it should pass data packets to when it receives them from the network. 🌈 Examples of higher layer protocols include the Network Voice Protocol and the Packet Video Protocol. These higher layer protocols will typically do further demultiplexing among multiple application processes as part of their protocol processing. Layers upon layers, bestie. 🧁
next-hop ➡️
Synonym for next-hop ST agent. 💖
next-hop ST agent 👉
For each origin or intermediate ST agent managing a stream, there's a set of next-hop ST agents. ✨ The intermediate agent forwards each data packet it receives to all of the next-hop ST agents. Those then forward the data toward the target host agent (if that next-hop agent is another intermediate agent), or up to the next higher protocol layer at the target (if that next-hop agent is a host agent). 🦋
NextPcol 🧩
NextPcol is a field in each Target of the CONNECT message, and it's used to convey the next protocol identifier. 🎀 See the definition of next protocol identifier above for more details. 🙈
NHIDAbort 🚫
NHIDAbort is an integer parameter each ST agent maintains. It's the number of unacceptable HID proposals before an ST agent aborts the HID negotiation process. Three strikes and we're out, sort of. 💀
NHIDAck 🔄
NHIDAck is an integer parameter each ST agent maintains, and it controls retransmission of HID-CHANGE-REQUEST messages. An ST agent sends HID-CHANGE-REQUEST to the previous-hop ST agent to request that the HID in use between those agents be changed. 🌸 The previous-hop acknowledges the HID-CHANGE-REQUEST message by sending a HID-CHANGE message. If the HID-CHANGE isn't received within the appropriate timeout interval, the request gets resent up to NHIDAck times before giving up. 😭
NHIDChange 🔁
NHIDChange is an integer parameter each ST agent maintains, and it controls retransmission of the HID-CHANGE message. A HID-CHANGE message must be acknowledged by the next-hop agent. ✨ If this ACK isn't received within the appropriate timeout interval, the request gets resent up to NHIDChange times before giving up. 💅
NRefuse 🙅
NRefuse is an integer parameter each ST agent maintains, and it controls retransmission of a REFUSE message. As a REFUSE request gets relayed by agents back toward the origin, it must be acknowledged by each previous-hop agent. 🫶 If this ACK isn't received within the appropriate timeout interval, the request gets resent up to NRefuse times before giving up. Not today, but we'll try again. 💜
NRetryRoute 🗺️
NRetryRoute is an integer parameter each ST agent maintains, and it's used to control route exploration. When an agent receives a REFUSE message whose ReasonCode indicates that the originally selected route isn't acceptable, the agent should try to find an alternate route to the target. 🦋 If the agent hasn't found a viable route after a maximum of NRetryRoute choices, it should give up and notify the previous-hop or application that it can't find an acceptable path to the target. Plan B has limits, babe. 😭
origin 🌟
The origin of a stream is the host agent where an application or higher level protocol originally requested that the stream be created. 👑 The origin specifies the data to be sent through the stream. 💖
parameter 🎛️
Parameters are additional values that may be included in control messages. 🌈 They're often optional. They're distinguished from fields, which are always present. 🧚
participants 🙋
Participants are the end-users of a stream. 💜
PDU 📦
PDU is short for Protocol Data Unit, which is defined below. 🎀
peer 👯
The term peer is used to refer to entities at the same protocol layer. ✨ It's used here to identify instances of an application or protocol layer above ST. For example, data is passed through a stream from an originating peer process to its target peers. 🫶
previous-hop ⬅️
Synonym for previous-hop ST agent. 🌸
previous-hop ST agent 👈
This is the origin or intermediate agent from which an ST agent receives its data. 🦋
protocol data unit 🧱
A protocol data unit (PDU) is the unit of data passed to a protocol layer by the next higher layer protocol or user. It consists of control information and possibly user data. 💅 Think of it as the little package that gets handed down the layers. 🎁
RecoveryTimeout ⏳
RecoveryTimeout is specified in the FlowSpec of each stream. The minimum of these values over all streams between a pair of adjacent agents determines how often those agents must send HELLO messages to each other. 🔥 That's how failure of one of the agents gets detected quickly enough to meet the guarantee implied by the FlowSpec. Timing is everything. 🙈
Restarted bit 🔄
The Restarted bit is part of the HELLO message. When it's set, it indicates that the sending agent was restarted recently, within the last HelloTimerHoldDown seconds. 🌈
round-trip time 🏓
The round-trip-time is the time it takes a message to be sent, delivered, processed, and the acknowledgment received. ✨ It includes both network and processing delays. Everything counts, even the slow bits. 😭
RTT ⏱️
RTT is short for round-trip-time. 💖
RVLId 🪪
RVLId is short for Receiver's Virtual Link Identifier. It uniquely identifies to the receiver the virtual link, and this stream, used to send it a message. 🧚 See the definition for Virtual Link Identifier below. 🎀
SAP 🚪
SAP is short for Service Access Point. 💜
SCMP 🛎️
SCMP is short for ST Control Message Protocol, which is defined below. 🫶
Service Access Point 🔌
A Service Access Point is a point where a protocol service provider makes available the services it offers to a next higher layer protocol or user. 💅 It's the plug where the good stuff is served. 🦋
setup phase 💌 Before any data can zoom through a stream, the ST agents have to pass the stream's state info along to every agent on the path(s) to the target(s). That's the setup phase 🧚. It wraps up once every ACCEPT and REFUSE sent by the targets has reached the origin. Then the data transfer phase starts and data can finally flow ✨. You can still request changes to the stream during data transfer, and the data keeps flowing without interruption 🌊.
ST agent 🤖 An ST agent is any entity that implements the ST Protocol. Basically, the main characters of the whole show 👑.
ST Control Message Protocol 🎛️ This is the subset of the full ST Protocol that handles creating, modifying, maintaining, and tearing down a stream. It also covers event notification and status monitoring, so it's giving full control room energy 💅.
stream 🌊 A stream is the basic object the ST Protocol manages for moving data around. It has exactly one origin, where the data gets created, and one or more targets, where the data lands for processing. The origin provides a flow specification describing what the application needs and what guarantees the ST agents can promise. The origin, intermediate agents, and targets all negotiate that spec together 🤝.
subsets 🧩 Subsets of the ST Protocol are allowed, as defined in various sections of this spec. They exist so simpler implementations can still play nicely with the fuller ones without causing any chaos 🫶.
SVLId 🆔 Short for Sender's Virtual Link Identifier. It tells the receiver which virtual link identifier should go into the RVLId field of every reply sent over the virtual link for a given stream. Check the Virtual Link Identifier entry below for the full scoop 🦋.
target 🎯 An ST target is the destination where the data from the origin gets delivered for higher layer protocol or application processing. It's the final stop 🏁.
tear down 🧹 The tear down phase starts when the origin says it has no more data to send. The ST agents along the stream then dismantle it and release its resources. Clean-up crew mode activated 🧽.
ToAccept ⏲️ A timeout, in seconds, kept by each ST agent. It sets the retransmission interval for ACCEPT messages.
ToConnect ⏲️ A timeout, in seconds, kept by each ST agent. It sets the retransmission interval for CONNECT messages.
ToDisconnect ⏲️ A timeout, in seconds, kept by each ST agent. It sets the retransmission interval for DISCONNECT messages.
ToHIDAck ⏲️ A timeout, in seconds, kept by each ST agent. It sets the retransmission interval for HID-CHANGE-REQUEST messages.
ToHIDChange ⏲️ A timeout, in seconds, kept by each ST agent. It sets the retransmission interval for HID-CHANGE messages.
ToRefuse ⏲️ A timeout, in seconds, kept by each ST agent. It sets the retransmission interval for REFUSE messages.
upstream ⬆️ The direction in a stream going from a target back toward the origin. Reverse vibes 🔄.
Virtual Link 🔗 A virtual link is one edge of the tree that describes the path data takes through a stream. Each pair of neighbouring ST agents gets its own virtual link, even when several next hops can be reached through a single network-level multicast group. This keeps demultiplexing of ST Control Message PDUs received from one physical link or network super efficient 😤✨.
Virtual Link Identifier 🪪 For every ST Control Message sent, the sender includes its own virtual link identifier and the receiver's, if it knows it. Either identifier, paired with the address of the matching host, can uniquely identify the virtual control link to the agent. Virtual link identifiers are picked by the agent they belong to, so that agent can pinpoint the stream, state machine, and other protocol processing data it manages, no matter where the control message came from. They're not negotiated, and they don't change during the life of a stream. They get thrown away when the stream is torn down 🗑️.
7. References 📚
[1] Braden, B., Borman, D., and C. Partridge, "Computing the Internet Checksum", RFC 1071, USC/Information Sciences Institute, Cray Research, BBN Laboratories, September 1988.
[2] Braden, R. (ed.), "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989.
[3] Cheriton, D., "VMTP: Versatile Message Transaction Protocol Specification", RFC 1045, Stanford University, February 1988.
[4] Cohen, D., "A Network Voice Protocol NVP-II", USC/Information Sciences Institute, April 1981.
[5] Cole, E., "PVP - A Packet Video Protocol", W-Note 28, USC/Information Sciences Institute, August 1981.
[6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, Stanford University, August 1989.
[7] Edmond W., Seo K., Leib M., and C. Topolcic, "The DARPA Wideband Network Dual Bus Protocol", accepted for presentation at ACM SIGCOMM '90, September 24-27, 1990.
[8] Forgie, J., "ST - A Proposed Internet Stream Protocol", IEN 119, M. I. T. Lincoln Laboratory, 7 September 1979.
[9] Jacobs I., Binder R., and E. Hoversten E., "General Purpose Packet Satellite Network", Proc. IEEE, vol 66, pp 1448-1467, November 1978.
[10] Jacobson, V., "Congestion Avoidance and Control", ACM SIGCOMM-88, August 1988.
[11] Karn, P. and C. Partridge, "Round Trip Time Estimation", ACM SIGCOMM-87, August 1987.
[12] Mallory, T., and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, BBN Communications Corporation, January 1990.
[13] Mills, D., "Network Time Protocol (Version 2) Specification and Implementation", RFC 1119, University of Delaware, September 1989 (Revised February 1990).
[14] Pope, A., "The SIMNET Network and Protocols", BBN Report No. 7102, BBN Systems and Technologies, July 1989.
[15] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981.
[16] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981.
[17] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980.
[18] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.
[19] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3), SDN.301, Rev. 1.5, 1989-05-15.
[20] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3) Addendum 1, Cooperating Families, SDN.301.1, Rev. 1.2, 1988-07-12.
8. Security Considerations 🔐
See section 3.7.8.
9. Authors' Addresses 💜
Here's where the squad lives 🫶:
Stephen Casner
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (213) 822-1511 x153
EMail: Casner@ISI.EduCharles Lynn, Jr.
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3367
EMail: CLynn@BBN.ComPhilippe Park
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-2892
EMail: ppark@BBN.COMKenneth Schroder
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3167
EMail: Schroder@BBN.ComClaudio Topolcic
BBN Systems and Technologies,
a division of Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3874
EMail: Topolcic@BBN.Com[This page intentionally left blank.] 🍓
Appendix 1. Data Notations 🧮
The convention in Internet Protocol docs is to write numbers in decimal and to draw data with the most significant octet on the left and the least significant octet on the right. Simple, but important 💖.
The order of transmission for the header and data in this document is resolved down to the octet level. Whenever a diagram shows a group of octets, they're sent in the normal order you'd read them in English. For example, in the diagram below the octets go out in the order they're numbered 🔢.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 56. Transmission Order of BytesWhenever an octet stands for a number, the leftmost bit in the diagram is the high order, most significant bit. So the bit labeled 0 is the most significant one. For example, this diagram represents the value 170 (decimal) 🌈.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Figure 57. Significance of BitsSame deal for multi-octet fields: the leftmost bit of the whole field is the most significant bit. When a multi-octet quantity is sent, the most significant octet goes first 🚀.
Fields whose length is fixed and fully shown end with a vertical bar (|). Fixed fields whose contents are abbreviated are marked with an exclamation point (!). Variable fields are marked with colons (:) 🎀.
Optional parameters are separated from control messages by a blank line. The order of optional parameters doesn't mean anything ✨.
📦 where this page comes from
- ietf: rfc1190 1990-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms