RFC 1458
Requirements for Multicast Protocols
RFC 1458: Requirements for Multicast Protocols 🎀
Okay bestie, this is RFC 1458, called Requirements for Multicast Protocols, and it's giving early-90s internet energy 🦋. R. Braudes and S. Zabele from TASC wrote it, and it's dated May 1993. It comes from the Network Working Group. The header doesn't have an obsoletes or updates line, so the title block doesn't list anything it replaces or changes 🌸.
As for category, the header doesn't use a formal label, but the Status of this Memo section says it provides information for the Internet community and does not specify an Internet standard. So it's more of a guide than a rulebook 📖.
Status of this Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited 💖.
Summary 💅
Multicast protocols have been developed over the past several years to address issues of group communication 👯. Experience has shown that current protocols don't cover all of the requirements of multicast applications 😭. This memo digs into some of these unresolved issues and sketches a high-level design for a new multicast transport protocol, a group address and membership authority, and modifications to existing routing protocols 🔥.
Table of Contents 🧚
Here's the full map, copied exactly so nothing gets lost 🗺️:
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Image Communication Problem . . . . . . . . . . . . . 2
2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
3. Review of Existing Multicast Protocols . . . . . . . . . . 4
3.1 IP/Multicast . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 XTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 ST-II . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Reliable Adaptive Multicast Service . . . . . . . . . . . 9
4.1 The Multicast Group Authority . . . . . . . . . . . . . . 9
4.1.1 Address Management . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Service Registration, Requests, Release, and Group
Membership Maintenance . . . . . . . . . . . . . . . . . . 10
4.2 The Reliable Adaptive Multicast Protocol (RAMP) . . . . . 11
4.2.1 Quality of Service Levels . . . . . . . . . . . . . . . . 12
4.2.2 Error Recovery . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3 Flow Control . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Routing Support . . . . . . . . . . . . . . . . . . . . . 14
4.3.1 Path Set-up . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.2 Path Tear-down . . . . . . . . . . . . . . . . . . . . . . 15
4.3.3 Multicast Routing Based on Quality of Service . . . . . . 15
4.3.4 Quality of Service Based Packet Loss . . . . . . . . . . . 15
5. Interactions Among the Components: An Example . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Security Considerations . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 191. Introduction 🌈
Multicast protocols exist to support group communications 👥. They use a one-to-many paradigm for transmission, and they typically use class D Internet Protocol (IP) addresses to specify particular multicast groups. While designing network services for reliable transmission of very large imagery as part of the DARPA-sponsored ImNet program, we reviewed existing multicast protocols and found that none meet all of the requirements of image communications [3]. This RFC reviews the current state of multicast protocols, highlights the missing features, and motivates the design and development of an enhanced multicast protocol 💜.
First, we present the requirements for network services and underlying protocols related to image communications. Then we review existing protocols and analyze each one against those requirements. The analyses point to the need for a new multicast protocol. Finally, we lay out the features of an ideal reliable multicast protocol that adapts to network congestion when moving large data volumes. We also introduce the extra network components needed to fully support the new protocol, including a Multicast Group Authority and modifications to existing routing protocols ✨.
2. The Image Communications Problem 📸
2.1 Scope
Image management and communications systems are evolving from film-based systems toward an all-digital environment 📷. In that world, imagery is acquired, transmitted, analyzed, and stored using digital computer and communications technologies. The throughput needed to communicate large numbers of very large images is extremely high, coming to thousands of terabytes of imagery per day 🤯. Timing requirements for capturing and sharing single images are strict, ranging from seconds to at most several minutes ⏱️. Hundreds of geographically distributed users will view the imagery, and they'll need on-demand, interactive access to the data 🌍.
Traditional imaging applications involve images on the order of 512 by 512 pixels. A single image used for remote sensing, though, can have tens of thousands of pixels on a side 🛰️. Multiply that data volume by even a small number of users and it's clear we need to move past the current suite of reliable protocols 🚀.
Basic image communication applications involve sending individual images to multiple users for both individual and collaborative analyses. Network efficiency requires multicast protocols here 💡. Multicasting offers big advantages in real-time image acquisition and dissemination, distribution of annotated image-based reports, and image conferencing 🎀. Images get viewed on a heterogeneous set of workstations with different processing and display capabilities. They also travel over a heterogeneous network, with bandwidths varying by up to six orders of magnitude between the initial down link and the slowest end user 🐢.
2.2 Requirements
Multicast protocols used for image communications must address several requirements 📝. Setting up a multicast group first requires assigning a multicast group address. All multicast traffic is then delivered to this address, which means all members of the group must be listening for traffic with this address 👂.
Within an image communications architecture like the one used for the ImNet program, diversity and adaptability can be handled by trading quality of service (i.e., image quality) for speed of transmission 🔄. Multicast support for these quality-speed trades can be realized either by using different multicast groups, where each group receives a different image quality, or by using a single hierarchical stream, with routers (or users) extracting the relevant portions 🧩.
Right now routers can't support selective transmission of partial streams, so ImNet uses a multiple stream approach 🙃. Efficient operation with a multiple stream approach requires that users be able to switch streams very quickly, and that streams with no listeners not be disseminated. So rapid configuration of multicast groups and rapid switching between multicast groups switching is essential ⚡.
Packet loss is basically inevitable, because network congestion or buffer overruns cause it 📉.
Image communications need a full range of transport reliability. For some applications, like image conferencing, packet loss isn't a big deal, since dropped mouse movements can be discarded with no meaningful degradation in utility 🖱️. For functions like image archiving or detailed image analysis, though, transport must be completely reliable, so any dropped packets must be retransmitted by the sender 🔒. Several hierarchical image compression methods can also provide useful, albeit degraded, imagery using a semi-reliable service. In that setup, higher-level data is transmitted reliably and lower-level data is transmitted unreliably 🧠.
To support reliable transport, image communications services must also support adaptation to network congestion using flow control mechanisms 🚦. Flow control regulates the amount of data placed on the network per unit time interval, which increases network efficiency by reducing the number of dropped packets and avoiding the need for large numbers of retransmissions 💅.
3. Review of Existing Multicast Protocols 🔍
Several existing protocols provide varying levels of multicast support, including IP/Multicast [5], the Xpress Transfer Protocol (XTP) [11], and Experimental Internet Stream Protocol Version 2 (ST-II) [10] 🌟. The Versatile Message Transaction Protocol (VMTP) [4] also supports multicast, but it was designed for transferring small packets, so it isn't appropriate for large image communications 🙅♀️. A specification also exists for the Multicast Transport Protocol (MTP) [2] 📜.
The image communication requirements for a multicast protocol include multicast group address assignment, group set-up, membership maintenance (i.e., join, drop, and switch membership), group tear-down, error recovery, and flow control, as presented above 📋. The rest of this section looks at how well each existing protocol meets those requirements 💖.
3.1 IP/Multicast ✨
okay so IP/Multicast is basically regular IP with a multicast upgrade 🦋 but here's the tea: it has no address allocation mechanism. addresses come from an outside authority or each application just picks one for itself 🙃 which means two apps can grab the same address and then the traffic from different groups gets totally commingled 💀
there's no real set-up for IP/Multicast 🌸 once an address is determined, the sender just sends packets to it and the routers figure out the path(s) the data takes. the receiver side is a tiny bit more work: an application has to issue an add membership request so IP starts listening for traffic to that address 🎀 if it's the first member of a group, IP multicasts that request to routers on the local network using the Internet Group Multicast Protocol (IGMP) so they can put it in their routing tables 🧚 after that, multicast packets get routed like every other IP packet, and receivers accept traffic for joined groups in addition to their normal host address 💅
the big problem with this set-up approach is telling hosts which multicast group addresses exist 😭 if addresses are dynamically allocated, you need some mechanism for letting receivers know which address got assigned to which group. that takes a minimum of one round trip time: an address gets requested from a server and then sent back to the receiver 🔁
dropping membership is a request to the local IP, which decrements the member count in the IP tables 🫠 but when group membership hits zero, no special action happens. instead there's a heartbeat mechanism where hosts get periodically polled for active groups, and routers only stop forwarding group traffic to a network after several polls come back with no activity requests for that group 🫶 this is so a membership report doesn't get lost or corrupted in transit. the catch is the heartbeat is slow (minimum of one minute between polls), so unneeded traffic keeps getting sent 😩 and there's no quick way to drop a group over a given path, which makes reacting to network congestion in real-time basically impossible 🙈
and finally, there's no transport level protocol that works with IP/Multicast and is both reliable and implements a flow control mechanism. not it 💀
3.2 XTP 💜
XTP is a combined network and transport level protocol that offers significant support for multicast transfers 👑 but like IP/Multicast, it has no inherent address management scheme, so an outside authority is required.
XTP is also similar to IP/Multicast because there's no explicit set-up processing between the sender and receivers before group communications get going 🤝 there is implicit processing in key management, but an external mechanism is still required for passing the multicast group address to the receivers. receivers have to establish "filters" for the address before transmission in order to receive the data, and it suffers the same problems as IP/Multicast 🥲
in contrast to IP/Multicast, XTP does require explicit handshaking between the sender and any receivers that want to join an existing group ✨ however, there's no parallel communication for receivers dropping out of groups, and the only way for a sender to know if there are any receivers is the polling scheme used for error control and recovery. this causes the same problems with sending traffic to groups without members that we talked about under IP/Multicast 😭
the XTP specification doesn't address how routers distribute a multicast stream among different connected networks 🗺️ however, it does include a discussion of the optional bucket, damping, slotting, and cloning algorithms to reduce duplicate multicast traffic within a local network 🧠
the specification lets the user decide whether multicast transfers are unreliable or semi-reliable. semi-reliable transfers are defined to provide a "high-probability of success [9]" of delivery to all receivers 🌸 but reliability can't actually be guaranteed, because XTP doesn't maintain the cardinality of the receiver set. so it can't know the data got received by all hosts 🙃
as for error recovery, XTP uses a go-back-n approach (assuming the bucket algorithm has been implemented) and retransmits dropped packets to all members of the multicast group, since group members are unknown 🌊 this has the potential to flood the network if only a single receiver dropped a packet. and if all the dropped packets belong to a single network on an internet, the traffic still gets generated over the entire connected network 😬
3.3 ST-II 🎀
ST-II is another network protocol that provides support for multicast communications 🦋 similar to IP/Multicast and XTP, ST-II requires a separate application-specific protocol for assigning and communicating multicast group addresses.
ST-II is a network level protocol, but it guarantees end-to-end bandwidth and delay, so it obviates the need for many of the functions of a transport protocol 💅 the guarantee comes from requiring bandwidth reservations for all connections (made at set-up time) and making sure the requested bandwidth stays available for the whole lifetime of the connection. the enforcement policy makes sure the same path gets followed for all transmissions, and it prohibits new connections over the network unless there's sufficient bandwidth for the expected traffic 🔒 all the connection state lives in the network routers, so you trade the overhead of connection set-up for the performance guarantees 🧚
connection set-up means negotiating the bandwidth and delay parameters and the path between the sender, intermediate routers, and receivers. if the requested resources can't be made available, the sender gets to choose between accepting what's available or cancelling the connection request 🤷♀️
adding a new user to an existing group is a whole thing 😩 the new receiver has to first talk directly to the sender using a different protocol to exchange relevant info, like the group address. then the sender asks ST-II to add the new receiver, the basic connection set-up processing gets invoked as before, and the new connection only completes if there's sufficient bandwidth to process the user ✨
the resource guarantee system imposed by ST-II tries to stop network congestion from happening, but there are situations where priority traffic has to be introduced into the network 🚨 ST-II makes this very expensive. the resource requirements for existing connections have to be adjusted, and that can only be done by the origin of each stream. this must be completed before the connection set-up for the priority stream, which introduces a large delay before the important data can be transmitted 😭
ST-II connections can be closed by either the sender or the receiver 🫶 when the last receiver along a path has been removed, the resources allocated over that path get released. when all receivers have been removed, the sender is informed and gets the option of either adding a new receiver or tearing down the group 👑
3.4 MTP 🧚♀️
MTP is a transport level protocol designed to support efficient, reliable multicast transmissions on top of existing network protocols such as IP/Multicast 🌈 it's based on the notion of a multicast "master" that controls all aspects of group communications.
allocating a specific group address (a network service access point) isn't considered part of MTP 🙅♀️ and just like the other multicast protocols, it requires an outside addressing authority. the MTP specification does require the master to make a "robust effort [2]" to make sure the address it picks isn't already in use, by trying to join an existing group at that address. but the problems described above still stick around 😵💫
once the address is established, receivers issue a request to join the existing group using a unique connection identifier that's pre-assigned 🔑 the MTP specification doesn't address how that identifier is allocated or how receivers learn its value. it's assumed to be handled through an external protocol. the join request specifies:
- whether the receiver wants to be a producer of information or only a receiver
- whether the connection should be reliable or best effort
- whether the receiver is able to accept multiple senders of information
- the minimum throughput desired
- the maximum data packet size
if the request can be granted, the master replies with an ACK with a multicast connection identifier. otherwise, a NAK gets returned ✅❌
dropping membership is coordinated through the master 👑 the specification doesn't say what action the master should take when the group is reduced to a single member, but a logical action would be to stop distributing transmit tokens if there are no active receivers.
one of the major features in MTP is the ordering of received data 💜 the master distributes transmit tokens to data producers in the group, which lets data get provided at a specified rate. rate control gives flow control within the protocol, and members that can't maintain a minimum flow are asked to leave the group 🏃♀️
error recovery uses a NAK-based selective retransmission scheme 🔁 senders are required to maintain data for a time period specified by the master, and to be able to retransmit that data when members of the group request it. these retransmissions get multicast to the entire group, so receivers have to be able to cope with duplicate packets 🙃 and if a retransmission request arrives after the data has been released, the sender must NAK the request.
the potential problem with MTP is the significant amount of overhead, since virtually all control traffic flows through the master 😩 the extra delay and congestion make MTP inappropriate for image dissemination applications. that's a no from me 🙅♀️
3.5 Summary 🌈
okay real talk: our analysis showed there are significant problems with all of the major multicast protocols for the reliable, adaptive multicast transport of large data items 🚩 the problems include inadequate address management, excessive processing of control information, poor response to network congestion, inability to handle high priority traffic, and suboptimal error recovery and retransmission procedures. we developed a high-level notion of the requirements for a service that addresses these issues, and we'll discuss that next 👀
4. Protocol Suite for Reliable, Adaptive Multicast ✨
here's the plan 💅 we present an integrated set of three basic components required to provide a reliable multicast service: the Multicast Group Authority (MGA), the Reliable, Adaptive Multicast Protocol (RAMP), and modified routing algorithms. these components are designed to be compatible with, and take full advantage of, reservation systems such as RSVP [12].
we've also broadened the definition of the term "Quality of Service (QOS)" 🎀 there are lots of applications where the information content of the underlying data can be reduced through data compression techniques. for example, a 1,024 x 1,024 pixel image can be sub-sampled down to 512 x 512 pixels 🖼️ this degradation results in a lower quality of service for the end user, but it also reduces the traditional network QOS requirements for the transfer. it's a trade-off, bestie, and honestly? iconic 🌟
4.1 The Multicast Group Authority 👑
Okay bestie, the Multicast Group Authority (MGA) is the one handling the multicast address space and giving high-level support to groups that already exist 💅 It has three main jobs: address management, service registration, and group membership maintenance. 🫶
The MGA is hierarchical, kind of like the Internet Domain Name System (DNS) [7]. Service requests go to an MGA agent on the local workstation first, and they get passed upwards whenever needed 🌸
4.1.1 Address Management 🦋
The MGA is in charge of handing out and taking back addresses from the Internet Class D address space. When an application process or another MGA node asks for addresses, the requester gets a whole block of them. How big that block is depends on where the requester sits in the MGA hierarchy, which cuts down on how many address requests have to climb the MGA tree 🌳
Let's walk through Figure 1 together 🧚 Say an application asks the authority at node 1.1.1 for a multicast address. If this is the first request from this branch of the MGA, node 1.1.1 asks its parent, node 1.1, which passes it up to node 1. Node 1 hands it to the root, and the root issues a block of, say, 30 class D addresses. 10 of those go to node 1.1, and the other 20 are kept for requests from node 1's other children 🍓 Node 1.1 does the same thing for node 1.1.1: it passes along 3 addresses and saves the other 7 for future requests. Last step, node 1.1.1 answers the application's request and keeps the leftover 2 addresses for later 🎀
--------
| root |
--------
/ | \
/ | \
-------- --------
| 1 | ... | n |
-------- --------
/ | \
/ | \
-------- --------
| 1.1 | ... | 1.n |
-------- --------
/ | \
/ | \
-------- --------
|1.1.1 | ... |1.1.n |
-------- --------
Figure 1. Sample MGA HierarchyWhen the root runs out of address space, it asks its children to hand back any addresses they aren't using. That request travels down the tree, and the unused addresses come back up through the hierarchy and go back into the pool 🔄 If the whole address space is in use, then new address requests just don't get honored. Rip 💀
When an application doesn't need its address anymore, the address goes back to the local MGA node. The node holds on to it until one of three things happens: another application requests it, the node's parent requests it, or the node itself gets terminated. When a node terminates, all of its available addresses go back to the parent ✨ Parents also send heartbeat requests to their children now and then to make sure everyone's still connected 💜 Local nodes do the same kind of check with their applications, and if an application doesn't answer, its address gets recalled 🫶
4.1.2 Service Registration, Requests, Release, and Group Membership Maintenance 🌈
The MGA keeps track of every registered multicast service and every receiver. That state includes how many members each group has, sorted by the reliability level they asked for in their QOS. The numbers update whenever services get offered or taken back, and whenever members join or leave a group 📊 The MGA uses this info to make sure there's always at least one group member listening to each multicast transfer, which is literally the whole point 🔥
Servers register that a service is available, and they say whether reliable service is available [section 4.2.2]. They can also optionally say how many qualities of service they offer [section 4.2.1] 🎀 A multicast group address gets pulled from the address pool, and the service gets an identifier if one is needed. If a reservation protocol that needs info from the server is in use (RSVP is one example), then the MGA tells the reservation system about the service, along with any parameters it needs ⚡ The registration gets passed around through the MGA so that potential clients can find out what's available 🦋 Servers don't start sending data until the MGA tells them to 🙈
Client requests get handled through the MGA too 💅 A request names a service, a desired quality of service, and a reliability indication. If the service has already been registered, the routing support gets told to add a route for the new user [section 4.3.1]. If it's necessary, the MGA also lets the reservation protocol know. If the requested QOS isn't being provided, or it's provided unreliably and the request wants reliable transport, then the service provider gets notified too 🌸 If the service isn't registered yet, it still gets an identifier, and the request sits in a queue until the service shows up. Either way, the requester gets a response ✨
Requests to leave a group also go to the MGA 🫶 If the request came from a client, the MGA tells the routing function and the reservation protocol about the termination, so the route can be released if it should be [section 4.3.2]. If a termination means that a given QOS has no recipients left, the service provider gets told that QOS isn't needed anymore and shouldn't be transmitted 🙅♀️ When the server ends a group, it's pretty much the same deal: every client in the group gets notified, and the service offering gets removed from the MGA state tables 💔
4.2 The Reliable Adaptive Multicast Protocol (RAMP) 🍓
Okay, RAMP is the transport-level protocol built to give reliable multicast service on top of a network protocol like IP/Multicast 🚀 It also lets unreliable transport happen when that's what's wanted. The big idea is that an application can ask for one quality of service (using our extended definition), but only actually needs reliable transmission at a lower level of quality 🧠
Here's an example: think about sending hierarchical image data, where a base spatial resolution goes out first, and then the higher resolution data follows 🖼️ An app might need the base data to arrive reliably, but it can handle dropped packets for the higher resolution part. It can do that by using interpolation or pixel replication from the base level to fake the missing data 🪄 Other data types, like audio or video, can use similar tricks 🎶
4.2.1 Quality of Service Levels ✨
RAMP lets one multicast service run at several qualities of service, and all or only some of those levels can be sent reliably 🌟 Those QOS levels can be spread across different groups that each use their own class D address, or, in the simplest case, they can all be sent in individual groups. A single packet can be used for one QOS, or it might apply to several qualities of service at once 💜
When a data packet gets sent, a header field says which QOS level(s) that packet belongs to 📦 In old IP implementations, the Type of Service field can be used as a bit field, with one bit for each applicable QOS. The catch is that this approach is incompatible with RFC 1349 [1] 😬 If a packet is needed for more than one QOS, then multiple values get encoded in the field. The RAMP host receiver protocol only accepts packets that are addressed to a group the application has asked to join, and that have a QOS value in the set of values the receivers requested 🫧
The QOS for a flow can change while the flow is happening 🔁 Modification requests get forwarded to the MGA, which lowers the receiver count in the original QOS group and bumps up the count for the newly requested QOS. Those changes move through the MGA hierarchy. The server gets notified if the original QOS has no receivers left, or if the new QOS isn't being served right now. Routers get notified if routing changes are needed 🛣️
4.2.2 Error Recovery 🛠️
RAMP uses sequence numbers to figure out the order of packets within a multicast group 🔢 How to order packets sent from different senders is still a current research topic [2, 6], and an appropriate sequencing algorithm will be built into the protocol once that's sorted out 🧩
Some applications don't need in-order delivery. For example, some image servers put position identification info in each packet, so order matters less 📍 To make those schemes more efficient, RAMP has an option that allows out-of-order delivery of packets to a receiver 🏃♀️
RAMP uses a NAK-based selective retransmission scheme, because that cuts down on the protocol overhead you'd get from ACK-based schemes 🙌 When a receiver notices that one or more packets didn't arrive, and the transmission is reliable, it sends a request to the sender for the span of packets that are missing 🔍
On the sender side, RAMP collects retransmission requests for the time set by the retransmission hold timer [section 4.2.3] ⏱️ When that time is up, the requests get checked to see if enough receivers lost a given packet to make multicasting the retransmission worth it. The check compares the count against a threshold value 📊 Any packet whose number of retransmission requests is greater than the threshold gets multicast to the group address, and every other packet gets unicast to the individual requesters 📬 This is kind of a middle ground between multicasting and unicasting every single retransmission, and that's on purpose 😌 The reasoning is this: multicasting a request from one sender can flood networks that had no packet loss at all, while unicasting to a huge number of receivers can flood the whole network 🌊 The ideal move, building a new multicast group for every dropped packet, is currently too expensive because setting up groups takes too long ⏳
For the cases where the service provider can't retransmit the data because its buffers were released or overwritten, RAMP sends NAK responses. It uses multicast or unicast depending on how many retransmission requests came in 💌
4.2.3 Flow Control ✨
okay so RAMP uses a rate-based flow control mechanism 💅 it cuts the rate when it gets retransmission requests or router back-off requests (aka ICMP source quench messages 🙈), and it bumps the rate back up based on how many packets get sent without anyone asking for a retransmission 📈. when a retransmission request comes in, the protocol uses the number of packets requested to work out a rate reduction factor. a different reduction factor gets calculated when a router-generated squelch request shows up 🛑. then those reduction factors get used to compute a reduced rate of transmission. ngl that's the whole "slow down, bestie" energy 🫶
when a given number of packets have been sent without packet loss, the rate of transmission goes up incrementally 📈. the size of that increase will always be smaller than the size of the smallest rate decrease, so the throttling stays minimal 🌸
the retransmission hold timer is modified based on both application requests and network state ⏰. as the number of retransmission requests rises, the hold timer gets incremented to minimize the number of duplicate retransmissions. and when the requests drop, the timer gets decremented. the timer really said "I'm adaptable" 🦋
RAMP allows for priority traffic, which is marked in the packet header 👑 the protocol sends a variable number of packets from each sending process in proportion to the priority of the flow ✨
4.3 Routing Support 🦋
okay this part is giving infrastructure 🏗️ the protocol suite requires routing support for four functions: path set-up, path tear-down, forwarding based on QOS values, and prioritized packet loss due to congestion. the support must be integrated into routers and network-level protocols in a similar fashion to IGMP [8].
partial support comes as a direct consequence of using reservation protocols such as RSVP. this RFC does not mandate the means of implementing the required functions, and the specified protocols are compatible with known reservation protocols 💜
the routers state tables must maintain both the multicast group address and the QOS level(s) requested for each group on each outbound interface in order to make appropriate routing decisions [section 4.3.3]. therefore, the router state tables are updated whenever group membership changes, including QOS changes. the tables are always up to date, no cap 💖
4.3.1 Path Set-up
routers receive path set-up requests from the MGA as required when new members join a multicast group 🚪 each request specifies the incoming and outgoing interfaces, the group address, and the QOS associated with the request. when the message is received, the router establishes a path between the server and the receiver, and then updates the multicast group state table. the mechanism used to discern the network interfaces is not specified, but it may take advantage of other protocols such as the RSVP path and reservation mechanism 🧚
4.3.2 Path Tear-down
path tear-down requests are also propagated through the routers by the MGA when group membership changes or QOS changes no longer require data to be sent over a given route 🧹 these are used to inform routers of both deletions of QOS for a given path and deletions of entire paths. the whole point is to explicitly remove route table entries, so the router stops forwarding multicast data across networks as soon as the path isn't needed anymore. iconic cleanup behavior 💅
4.3.3 Multicast Routing Based on Quality of Service
okay so traditional multicast routing just makes route/don't route decisions based on the destination address in the packet header, and it duplicates packets as necessary to reach all destinations 📦 in the proposed new protocol suite, routers also check the QOS field for each packet, because different paths may have requested different qualities of service 👀 packets are only forwarded if the group address has been requested and the quality of service in the header is requested in the state table entry for a given interface. main character routing energy 👑
4.3.4 Quality of Service Based Packet Loss
network congestion causes router queues to overflow, and as a result, packet loss occurs 😭 the QOS and priority indications in the packet headers can be used to decide the order packets get dropped in. first, packets with the priority field set in the header are dropped last 🛟 within packets of equal priority, packets are dropped in order of QOS, with the highest QOS packets dropped first. the reasoning is that packets with lower QOS may still be usable by receivers, while packets with high QOS may not be usable without the lower QOS data 🧠
5. Interactions Among the Components: An Example 🎀
okay this section is my favourite because it shows everything working together 🥹 the MGA, RAMP, and routing support functions all cooperate in the multicast process. so picture a network with a single server (S), three routers (R1, R2, and R3), and two clients (C1 and C2). the path between S and C1 goes through R1 and R2, while the path between S and C2 goes through R1, R2, and R3. the network is shown in figure 2 🗺️
S ------- R1 -------- R2 -------- R3
| |
C1 C2
Figure 2. Sample Network ConfigurationService Registration
when S is initiated, it registers a service with the MGA node in the local workstation, offering reliable service at two qualities of service, Q1 and Q2 🎉 as this is the first multicast offering on the workstation, the local MGA requests a block of multicast addresses from the hierarchy, and assigns an address and service identifier to S. if the RSVP reservation protocol is in operation, the local MGA node in S notifies RSVP to send a RpathS message out for the service. that message goes through R1, R2, and R3, reaching the RSVP nodes on C1 and C2 📨 the service and its characteristics are propagated throughout the MGA hierarchy, ultimately reaching the MGA nodes resident on C1 and C2. the service is now available throughout the network 🌈✨
Service Request and Path Set-up
the client C1 requests reliable service from S at QOS Q1, by issuing a request to the MGA node in C1 🙋♀️ if a reservation protocol is in use, it is used to reserve bandwidth and establish a path between the sender and receiver, going through R1 and R2. otherwise, the path is established through R1 and R2 by the routing protocol. R1 now forwards all packets from S with QOS Q1 along the path to R2, which routes them to C1 🛤️ in concert with the path set-up, the add membership request is propagated through MGA to the server workstation. the local MGA tables are checked, and it's noted that the service is not currently being offered, so the server is notified to begin reliable distribution of the service at Q1 🚀
Initial Delivery
the server now begins transmitting Q1 data, which is observed by R1 👀 R1 inspects the header and notes that the packet has QOS Q1. the routing tables specify that QOS Q1 for this address is only forwarded along the interface leading to R2, so R1 acts accordingly 💁♀️ similarly, R2 routes the packet to C1. when the data arrives at C1, the RAMP node inspects the QOS and destination address fields in the header, accepts the packet, and forwards it to the C1 client process 💖
Error Recovery
during transmission, if the RAMP node in C1 realizes that packets have been dropped, a retransmission request is returned to the server identifying spans of the missing packets 🥺 the RAMP node accepts the packet, builds the retransmission packets, and sets the retransmission hold timer. when the timer expires, the number of retransmission requests for each missing packet is compared against the threshold. the packets are then either unicast directly to the requesters or multicast to the entire group. as in this case there is only requester, the threshold is not exceeded, and the packets are retransmitted to C1Us unicast address 📬 a very efficient little recovery story 🩵
Group Membership Addition
client C2 now joins the group, requesting reliable transmission at QOS Q2 🙌 following the process used for C1, the request propagates through the MGA (and potentially reservation protocol) hierarchy. upon completion of the request processing, R1 routes packets for QOS Q1 and Q2 to R2, while R2 forwards QOS Q1 packets to C1 and Q2 packets to R3. client C1 only accepts packets marked as Q1, while C2 only accepts Q2 packets 🎀 the server is notified that it now has clients for Q2, and it begins serving that QOS in addition to Q1 🥂
QOS Based Routing
first, assume that QOS Q1 data is independent of QOS Q2 data. when the server sends a packet with Q1 marked in the header, the packet is received by R1 and forwarded to R2. R2 receives the packet and sends it out the interface to C1, but not to R3 🙅♀️ next, the server delivers a packet for Q2. R1 receives the packet and sends it to R2, which forwards it to R3 but not to C1. R3 accepts the packet and forwards it to C2 🦋
now, assume that either Q2 is a subset of Q1, or that receivers of Q1 data also require Q2 data, as in conditional compression schemes. therefore, all Q2 packets are marked for both Q1 and Q2, while the remaining Q1 packets only have Q1 set in the header. Q1-only packets are routed as before, following the path S -> R1 -> R2 -> C1. however, Q2 packets are now routed from S to R1 to R2, at which point R2 duplicates the packets and sends them to both C1 and R3, with R3 forwarding them to C2. at C1, these packets have Q1 marked, so they are accepted, while at C2 the packet is accepted as the Q2 bit is verified 🧩 the duplication plot twist had me screaming 😭🔥
Group Membership Deletion
when C1 issues a drop membership request, the MGA on the client workstation is notified, and the request is propagated through the MGA hierarchy back to the server MGA node 👋 in parallel, the routers are notified to close the path, as it is no longer required, possibly through the reservation protocol. as this is the last client for the Q1 QOS, the server is informed to stop transmitting Q1 data, with Q2 data unaffected. a similar process occurs when C2 drops membership from the group, leaving the server idle 🥀 at this point, the server has the option of shutting down and returning the group address to the MGA, or continuing in an idle state until another client requests service 💤
Acknowledgements
this research was supported in part by the Defense Research Projects Agency (DARPA) under contract number F19618-91-C-0086 🫶🎀
References 🧾✨
Okay bestie, this is the receipts section 🧾 Every paper, RFC, and book this one name-drops is listed here, all twelve of them, so you can go check the sources yourself 🤓💅
- [1] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, Consultant, July 1992.
- [2] Armstrong, S., Freier, A., and K. Marzullo, "Multicast Transport Protocol", RFC 1301, Xerox, Apple, Cornell University, February 1992.
- [3] Braudes, R., and S. Zabele, "A Reliable, Adaptive Multicast Service for High-Bandwidth Image Dissemination", submitted to ACM SIGCOMM '93.
- [4] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, Stanford University, February 1988.
- [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989.
- [6] Mayer, E., "An Evaluation Framework for Multicast Ordering Protocols", Proceedings ACM SIGCOMM '92, Baltimore, Maryland, pp. 177-187.
- [7] Mockapetris, P., "Domain Names - Concepts and Facilities," STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
- [8] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 792, USC/Information Sciences Institute, September 1981.
- [9] Strayer, W., Dempsey, B., and A. Weaver, "XTP: The Xpress Transfer Protocol", Addison-Wesley Publishing Co., Reading, MA, 1992.
- [10] Topolcic, C., Editor, "Experimental Internet Stream Protocol, Version 2 (ST- II)", RFC 1190, CIP Working Group, October 1990.
- [11] "XTP Protocol Definition Revision 3.6", Protocol Engines Incorporated, PEI 92-10, Mountain View, CA, 11 January 1992.
- [12] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala, "RSVP: A New Resource ReSerVation Protocol", Work in Progress, March 1993.
Security Considerations 🔒
Security issues are not discussed in this memo. 😭 Like, the whole memo is silent on security, so keep that in mind as you read everything above. 💀
Authors' Addresses 🦋
Meet the two authors who made this whole thing happen. 🫶 Their contact details are below, exactly as they appear in the RFC.
Bob Braudes
TASC
55 Walkers Brook Drive
Reading, MA 01867
Phone: (617) 942-2000
EMail: rebraudes@tasc.com
Steve Zabele
TASC
55 Walkers Brook Drive
Reading, MA 01867
Phone: (617) 942-2000
EMail: gszabele@tasc.com📦 where this page comes from
- ietf: rfc1458 1993-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms