RFC 2191

VENUS - Very Extensive Non-Unicast Service 🦋

Okay bestie, this is RFC 2191 🎀 It was written by G. Armitage at Lucent Technologies, filed as Informational, and dated September 1997. Informational means it's a "here's some info" doc, not a standard. The header doesn't list anything it obsoletes or updates. 💅

Status of this Memo 📋

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 💜

Abstract ✨

So the MARS model (RFC2022) handles IP multicasting inside one LIS over ATM, setting up and managing ATM pt-mpt SVCs for multicast packet forwarding. Multicast between LISs happens through Mrouters, kinda like how "Classical IP over ATM" uses Routers to link LISs for unicast traffic. 🌸

Then NHRP came along and made unicast shortcuts a thing, so people started asking for a multicast version, and there are a bunch of ways to do that. This doc only looks at the problems of stretching MARS to cover multiple clusters, or clusters that span more than one subnet. 🧚

It describes a hypothetical solution called "Very Extensive NonUnicast Service" (VENUS) and shows how complicated it would be. Honestly, VENUS basically looks and feels like one big cluster running a distributed MARS. 🔥

The whole point of this document is to help ION efforts focus on other solutions for setting up ATM level multicast connections between LISes. 🫶

1. Introduction 🌈

Okay so the classic way the Internet runs over an ATM cloud is with a bunch of Logical IP Subnets (LISs) connected by IP Routers [1]. The newer IP Multicast over ATM solution (the "MARS model" [2]) keeps that setup. Each LIS becomes a "MARS Cluster", and Clusters connect to each other through regular IP Multicast routers (Mrouters). ✨

NHRP [3] is a protocol for finding and managing unicast forwarding paths that skip IP routers, and that's why some people are now asking for an IP multicast version. 🦋 Here's the tea: IP multicast is a totally different beast from IP unicast. This document explains how much of what we learned building NHRP needs careful checking before we reuse it for multicast. Honestly, the services that MARS and MARS Clients provide in [2] are almost orthogonal to IP unicast over ATM. 💀

For the sake of discussion, let's call this hypothetical multicast shortcut discovery protocol "Very Extensive Non-Unicast Service" (VENUS). A "VENUS Domain" is the set of hosts from two or more participating Logical IP Subnets (LISs). A multicast shortcut connection is a point to multipoint SVC whose leaf nodes are scattered around the VENUS Domain. (Section 2 will note that a VENUS Domain might be a single MARS Cluster spanning multiple LISs, or multiple MARS Clusters.) 🍓

VENUS has a few big problems. The first is that the scope over which each IP/ATM interface has to track and react to IP multicast group membership changes explodes. 😭 In the classical IP routing model, Mrouters act as aggregation points for multicast traffic flowing in and out of Clusters [4]. They also aggregate group membership change information, so only the IP/ATM interfaces within each Cluster need to know the specific identities of their local (intra-cluster) group members at any given time. 🎀

But once sources inside a VENUS Domain start setting up shortcut connections, the data and signaling plane aggregation that Mrouters provide is gone. For every possible source across a VENUS Domain to manage its outgoing pt-mpt SVCs, they have to know about MARS_JOIN and MARS_LEAVE messages happening in every MARS Cluster that makes up the VENUS Domain. The net effect is that a VENUS domain looks very similar to a single, large distributed MARS Cluster. 👑

The second problem is how shortcut connections will affect IP level Inter Domain Multicast Routing (IDMR) protocols. Multicast groups have lots of sources and destinations scattered across the participating Clusters. IDMR protocols assume they can work out efficient inter-Cluster multicast trees by aggregating individual sources or group members in any given Cluster (subnet) behind the Mrouter serving that Cluster. 🙈 If sources can just bypass an Mrouter, then we introduce a requirement that the existence of every single shortcut connection gets propagated into the IDMR decision making processes. 🔥 The IDMR protocols may need to adapt when a source's traffic bypasses its local Mrouter(s) and gets injected into Mrouters at more distant points on the IP-level multicast distribution tree. (This issue was looked at in [7], which focused on building forwarding trees in networks where the termination points are few and sparsely spread out. VENUS brings tougher requirements by assuming group membership might be dense across the region of interest.) 🧚

This document focuses mainly on the internal problems of a VENUS Domain and leaves the IDMR interactions for future analysis. 🫶

2. What does it mean to "shortcut" ? 💖

Before we go further, it's worth looking at the definition of the Cluster, plus two possible definitions of "shortcut". 🌸

2.1 What is a Cluster? 🦋

In [2], a MARS Cluster is defined as the set of IP/ATM interfaces that are willing to engage in direct, ATM level pt-mpt SVCs to perform IP multicast packet forwarding. Each IP/ATM interface (a MARS Client) must keep state information about the ATM addresses of each leaf node (recipient) of each pt-mpt SVC it has open. On top of that, each MARS Client receives MARS_JOIN and MARS_LEAVE messages from the MARS whenever Clients around the Cluster need to update their pt-mpt SVCs for a given IP multicast group. 🎀

Worth noting: no MARS Client has any idea how big its local cluster is. Only the MARS that a given Client is registered with keeps that knowledge. 🙈

Basically, the Cluster (and the MARS model as a whole) exists because any multicast IP/ATM interface using pt-mpt SVCs must add and drop leaf nodes itself as group membership changes. So some mechanism spanning all possible group members within the scopes of those pt-mpt SVCs is required to collect group membership information and get it to those interfaces in a timely way. That's the MARS Cluster, with certain scaling limits described in [4]. ✨

2.2 LIS/Cluster boundary "shortcut" 🌈

The popular definition of "shortcut" right now is based on unicast LIS boundaries. It's tied to the idea that LIS boundaries have physical routers, and cutting through a LIS boundary means bypassing a router. Intelligently bypassing routers at the edges of LISs has been NHRP's whole goal. Finding the ATM level identity of an IP endpoint in a different LIS lets a direct SVC get set up, which shortcuts the logical IP topology (and very real routers) along the unicast path from source to destination. 💅

For simplicity of early adoption, RFC2022 recommends making a Cluster's scope equivalent to that of a LIS. In that case, the "Classical IP" routing model puts Mrouters at LIS/Cluster boundaries, and multicast shortcutting has to bypass the same physical routing entities as unicast shortcutting. Each MARS Cluster would be independent and contain only the IP/ATM interfaces assigned to the same LIS. 🍓

So a VENUS Domain covering hosts across several LIS/Clusters would have to coordinate each individual MARS from each LIS/Cluster, so group membership updates from around the VENUS Domain get propagated correctly. 🧚

2.3 Big Cluster, LIS boundary "shortcut" 👑

The MARS model's core definition of a Cluster was deliberately made independent of unicast terminology. It's possible (though not currently well understood) to build a single MARS Cluster that spans the members of multiple LISs. As expected, inter-LIS unicast traffic would pass through (or bypass, if using NHRP) routers on the LIS boundaries. Also as expected, each IP/ATM interface, acting as a MARS Client, would forward its IP multicast packets directly to intra-cluster group members. 🦋 Because the direct intra-cluster SVCs exist between hosts from the different LISs making up the cluster, this could be considered a "shortcut" of the unicast LIS boundaries. ✨

This approach immediately raises the question of how IDMR protocols will react. Mrouters only need to exist at the edges of Clusters. If a single Cluster spans multiple LISs, each LIS gets hidden behind the Mrouter at the Cluster's edge. 🙈 This is arguably not a big problem if the Cluster is a stub on an IDMR protocol's multicast distribution tree, and if there's only a single Mrouter in or out of the Cluster. Problems show up when two or more Mrouters are attached to the edges of the Cluster and the Cluster is used for transit multicast traffic. Each Mrouter's interface is assigned a unicast identity (e.g. that of the unicast router containing the Mrouter). IDMR protocols that filter packets based on the correctness of the upstream source may get confused when they receive IP multicast packets directly from another Mrouter in the same cluster, but notionally "belonging" to an LIS multiple unicast IP hops away. 💀

Adjusting the packet filtering algorithms of Mrouters is something any multicast shortcut scheme needs to address. This has been noted before, and a solution was proposed in [7]. For the sake of argument, this document will assume the problem is solvable. (However, it's important that any solution scales well under general topologies and group membership densities.) 🫶 A multi-LIS MARS Cluster can be considered a simple VENUS Domain. Since it's a single Cluster, it can be scaled using the distributed MARS solutions currently being developed within the IETF [5,6]. 💖

---

That's part 1 of 4 🌸 more parts are coming, so stay tuned!

3. So what must VENUS look like? ✨

okay so this is where it gets spicy 🌶️ bestie. A bunch of the functions in the MARS model are the foundation for managing root controlled, pt-mpt SVCs 🦋. When any one MARS Client first sets up the forwarding SVC, it has to do a query/response exchange with its local MARS 💌. That's how it figures out who the current group members are (aka which leaf nodes should be on the SVC). Once the SVC exists, the management phase kicks in 🧚. MARS Clients need to stay informed about group membership changes inside their SVC's scope, so leaf nodes can be added or dropped as needed.

For intra-cluster multicasting, the current MARS approach already handles both of those phases for us 💖 literally no notes.

For the rest of this doc, we're focusing on what VENUS would look like when a VENUS Domain spans multiple MARS Clusters 🌈. In that situation, VENUS is basically the mechanism coordinating the MARS entities of each participating cluster 👑. Each MARS gets kept up to date with enough domain-wide info to support both phases (SVC establishment and SVC management) when the SVC's endpoints are outside the immediate scope of a client's local MARS. Inside a VENUS Domain, a MARS Client gets info on group members from all participating clusters, so it's giving full-network vibes ✨.

The next subsections look at the problems with each of these phases on its own 🫶. To a first approximation, the problems identified are independent of the possible inter-MARS mechanisms 🤷. The reader can assume the MARS in any cluster has some undefined mechanism for talking to the MARSs of clusters right next door (i.e. connected by a single Mrouter hop) 🍓.

---

3.1 SVC establishment - answering a MARS_REQUEST

The SVC establishment phase has a bunch of inter-related problems 💀.

First up: the target of a MARS_REQUEST (an IP multicast group) is an abstract entity 🙈. Let's assume VENUS doesn't require every MARS to know the entire list of group members across the participating clusters. So each time a MARS gets a MARS_REQUEST from a local client, it has to build a sequence of MARS_MULTIs using locally held info (on intra-cluster members) plus remotely solicited info 🎀.

So how does it solicit that info? Unlike the unicast situation, there's no definite, single direction to route a MARS_REQUEST across the participating clusters 😭. The only "right" approach is to send the MARS_REQUEST to all clusters, since group members may exist anywhere and everywhere 🌍. But we're allowed one obvious optimization: the MARS_REQUEST gets propagated along the IP multicast forwarding tree that's been established for the target group by whatever IDMR protocol is running at the time 🔥.

As noted in [4], there are various reasons a Cluster's scope might be kept limited. Some of these (MARS Client or ATM NIC limitations) imply that the VENUS discovery process not return more group members in the MARS_MULTIs than the requesting MARS Client can handle 🧩. This gives VENUS an interesting problem: it has to propagate the original MARS_REQUEST out, but also curtail the MARS_REQUEST's propagation once a sufficient number of group members have been identified. Looking at it from another angle, the scope of shortcut a given MARS Client can achieve depends heavily on the shape of the IP forwarding tree away from its location (and the density of group members within clusters along the tree) at the time the request was issued 🌳.

How might we limit the number of group members returned to a given MARS Client? Adding a limit TLV to the MARS_REQUEST itself is trivial 💅. At first glance, it might seem like when the limit is being reached, we could summarize the next cluster along the tree by the ATM address of the Mrouter into that cluster. The net effect would be that the MARS Client establishes a shortcut to lots of hosts inside closer clusters, and passes its traffic to more distant clusters through the distant Mrouter. However, this approach only works passably well for a very simplistic multicast topology (e.g. a linear concatenation of clusters) 😬.

In a more general topology, the IP multicast forwarding tree away from the requesting MARS Client will branch a number of times, requiring the MARS_REQUEST to be replicated along each branch 🌿. Ensuring that the total number of returned group members does not exceed the client's limit becomes rather more difficult to do efficiently 🥵. (VENUS could simply halve the limit value each time it split a MARS_REQUEST, but this might cause group member discovery on one branch to end prematurely while all the group members along another branch are discovered without reaching the subdivided limit 🙃.)

Now consider this decision making process scattered across all the clients in all participating clusters 🫠. Clients may have different limits on how many group members they can handle, leading to situations where different sources can shortcut to different (sub)sets of the group members scattered across the participating clusters (because the IP multicast forwarding trees from senders in different clusters may result in different discovery paths being taken by their MARS_REQUESTs) 🧭.

Finally, when the MARS_REQUEST passes a cluster where the target group is MCS supported, VENUS must ensure the ATM address of the MCS is collected rather than the addresses of the actual group members. (To do otherwise would violate the remote cluster's intra-cluster decision to use an MCS. The shortcut in this case must be content to directly reach the remote cluster's MCS.) 🎀

(A solution to part of this problem would be to ensure that a VENUS Domain never has more MARS Clients throughout than the clients are capable of adding as leaf nodes. This may or may not appeal to people's desire for generality of a VENUS solution. It also would appear to beg the question of why the problem of multiple-LIS multicasting isn't solved simply by creating a single big MARS Cluster. 🤔)

3.2 SVC management - tracking group membership changes ✨

Okay bestie, once a client's pt-mpt SVC is established, it must be kept up to date 💅. The consequence is simple and potentially devastating 💀: the MARS_JOINs and MARS_LEAVEs from every MARS Client in every participating cluster must be propagated to every possible sender in every participating cluster. (This applies to groups that are VC Mesh supported. Groups that are MCS supported in some or all participating clusters bring in complications, described below.) The signaling load is the real problem, because as all the participating MARSs start broadcasting their MARS_JOIN/LEAVE activity, it isn't localized to clusters containing MARS Clients who have established shortcut SVCs. The IP multicast model is Any to Multipoint, and you can never know where a source MARS Client might be, so the JOINs and LEAVEs must be propagated everywhere, always, just in case 😭. (This is basically a bigger version of sending JOINs and LEAVEs to every cluster member over ClusterControlVC, and it's for exactly the same reason 🫶.)

The use of MCSs in some clusters instead of VC Meshes makes things way more complicated 🌀. So does the initial scoping of a client's shortcut during the SVC establishment phase, which is described in the preceding section.

In clusters where MCSs support certain groups, MARS_JOINs or MARS_LEAVEs only get propagated to MARS Clients when an MCS comes or goes 🍓. The tricky bit is that it isn't clear how to accommodate the current MARS_MIGRATE functionality, which lets a previously VC Mesh based group shift to an MCS within the scope of a single cluster. If an MCS starts up within a single Cluster, you can shift all the intra-cluster senders to the MCS using MARS_MIGRATE as currently described in the MARS model. But MARS Clients in remote clusters that have shortcut SVCs into the local cluster also need some kind of signal to shift. Otherwise they'll keep sending their packets directly to the group members in the local cluster 🙈.

This is a non-trivial requirement. We only want to force the remote MARS Clients to drop some of their leaf nodes (the ones to clients within the Cluster that now has an MCS), add the new MCS as a leaf node, and leave all their other leaf nodes untouched (the cut-through connections to other clusters). Simply broadcasting the MARS_MIGRATE around all participating clusters would certainly not work 🚫. VENUS needs a new control message with the semantics of replaced leaf nodes {x, y, z} with leaf node {a}, and leave the rest alone. Such a message is easy to define but harder to use 🧚.

Another issue for SVC management is that the scope over which a MARS Client needs to receive JOINs and LEAVEs has to respect the Client's limited capacity for handling leaf nodes on its SVC. Say the MARS Client initially issued a MARS_REQUEST and indicated it could handle 1000 leaf nodes. It isn't clear how to make sure that subsequent joins of new members won't exceed that limit 😬. Also, if the SVC establishment phase decided the SVC would stop at a particular Mrouter (because leaf node limits were reached), the Client probably should not be receiving direct MARS_JOIN or MARS_LEAVE messages about activity in the cluster "behind" that Mrouter. Otherwise you could end up with multiple copies of the source client's packets reaching group members inside the remote cluster: one copy through the Mrouter, and another on the direct SVC connection the source client would set up after receiving a later, global MARS_JOIN about a host inside the remote cluster 😤.

Another scenario is that the density of group members along the IDMR multicast tree increases over time after the initial MARS_REQUEST is answered. Later JOINs from Cluster members may dictate that a "closer" Mrouter aggregate the source's outbound traffic, so the source doesn't exceed its leaf node limitations. How to dynamically shift between terminating on hosts within a Cluster and terminating on a cluster's edge Mrouter is an open question 🤷‍♀️.

To complicate matters further, scoping the VENUS domain-wide propagation of MARS_JOINs and MARS_LEAVEs needs to be done on a per-source-cluster basis, at least. If MARS Clients within the same cluster have different leaf node limits, the problem gets worse 💀. One client might have been able to establish a shortcut SVC directly into a remote cluster, while a second client in the same source cluster was forced to terminate its shortcut on the remote cluster's Mrouter. The first client obviously needs to know about group membership changes in the remote cluster, but the second client doesn't. Propagating these JOIN/LEAVE messages on ClusterControlVC in the source cluster won't work. The MARS for the source cluster will need to explicitly send copies of the JOIN/LEAVE messages only to those MARS Clients whose prior SVC establishment phase indicates they need them. Propagating messages to indicate a VC Mesh to MCS transition within clusters may also need to take account of the leaf node limitations of MARS Clients. The scaling characteristics of this problem are left to the reader's imagination 🌸.

It was noted in the previous section that a VENUS domain could be limited to ensure there are never more MARS Clients than any one client's leaf node limit. That would definitely avoid the need for complicated MARS_JOIN/LEAVE propagation mechanisms. But it raises the question of how different the VENUS domain then becomes from a single, large MARS Cluster 🤔.

---

4. What is the value in bypassing Mrouters? 🦋

This is a really good question, because the whole aim of developing a shortcut connection mechanism rests on the assumption that bypassing IP level entities is always a "win". For multicast, that's arguably not true 🙃.

The most important thing to notice about shortcut connection scenarios is that they increase the exposure of any given IP/ATM interface to externally generated SVCs. If there are a potential 1000 senders in a VENUS Domain, then you (as a group member) open yourself up to a potential demand for 1000 instances of your re-assembly engine. You'd also have 1000 distinct incoming SVCs, since you get added as a leaf node to each sender's pt-mpt SVC, and your local switch port has to be able to support all of them 😳.

It shouldn't be a surprise that the ATM level scaling limits that apply to a single MARS Cluster [4] will also apply to a VENUS Domain. This brings us right back to why you'd bypass an Mrouter in the first place. As noted in [4], Mrouters do a useful job of data path aggregation. 100 senders in one cluster become 1 pt-mpt SVC out of the Mrouter into the next cluster along the tree. They also hide MARS signaling activity, since individual group membership changes in one cluster are hidden from IP/ATM interfaces in surrounding clusters. You have to factor the loss of these benefits into any network designed to use multicast shortcut connections 📝.

(For the sake of completeness, it must be noted that extremely poor mismatches of IP and ATM topologies may make Mrouter bypass attractive if it improves the use of the underlying ATM cloud. There may also be benefits in removing the additional re-assembly/segmentation latencies of having packets pass through an Mrouter. However, a VENUS Domain ascertained to be small enough to avoid the scaling limits in [4] might just as well be constructed as a single large MARS Cluster. A large cluster also avoids a topological mismatch between IP Mrouters and ATM switches.)

---

5. Relationship to Distributed MARS protocols. 🌈

The ION working group is looking closely at the development of distributed MARS architectures. An outline of some issues is provided in [5,6]. As noted earlier in this document, the problem space looks very similar to the one faced by our hypothetical VENUS Domain. For example, in the load-sharing distributed MARS model:

• The Cluster is partitioned into sub-clusters.
• Each Active MARS is assigned a particular sub-cluster, and uses its own sub-ClusterControlVC to propagate JOIN/LEAVE messages to members of its sub-cluster.
• The MARS_REQUEST from any sub-cluster member must return information from all the sub-clusters, so as to ensure that all a group's members across the cluster are identified.
• Group membership changes in any one sub-cluster must be immediately propagated to all the other sub-clusters.

There's a clear analogy to be made between a distributed MARS Cluster and a VENUS Domain made up of multiple single-MARS Clusters 🧁. The information that must be shared between sub-clusters in a distributed MARS scenario is similar to the information that must be shared between Clusters in a VENUS Domain.

The distributed MARS problem is slightly simpler than the one faced by VENUS:

• There are no Mrouters (IDMR nodes) within the scope of the distributed Cluster.
• In a distributed MARS Cluster, an MCS supported group uses the same MCS across all the sub-clusters. VENUS is different: complete generality makes it necessary to cope with mixtures of MCS and VC Mesh based Clusters 🌪️.

---

6. Conclusion. 👑

This document has described a hypothetical multicast shortcut connection scheme, dubbed "Very Extensive NonUnicast Service" (VENUS). The two phases of multicast support, SVC establishment and SVC management, are shown to be essential whether the scope is a Cluster or a wider VENUS Domain. It has been shown that once the potential scope of a pt-mpt SVC at the establishment phase has been expanded, the scope of the SVC management mechanism must similarly be expanded. This means timely tracking and propagation of group membership changes across the entire scope of a VENUS Domain 💜.

It has also been noted that there's little difference in result between a VENUS Domain and a large MARS Cluster. Both suffer from the same fundamental scaling limitations, and both can be arranged to provide shortcut of unicast routing boundaries. However, a completely general multi-cluster VENUS solution ends up being more complex. It needs to deal with bypassed Mrouter boundaries, and with dynamically changing group membership densities along multicast distribution trees established by the IDMR protocols in use 🌷.

No solutions have been presented. This document's role is to provide context for future developments 🔮.

---

Acknowledgment 🫶

This document was prepared while the author was with the Internetworking Research group at Bellcore.

---

Security Considerations 💀

This memo addresses specific scaling issues associated with the extension of the MARS architecture beyond that described in RFC 2022. It is an Informational memo, and does not mandate any additional protocol behaviors beyond those described in RFC 2022. As such, the security implications are no greater or less than the implications inherent in RFC 2022. Should enhancements to security be required, they would need to be added as an extension to the base architecture in RFC 2022 🔐.

---

Author's Address 🖋️

Grenville Armitage Bell Labs, Lucent Technologies. 101 Crawfords Corner Rd, Holmdel, NJ, 07733 USA

EMail: gja@dnrc.bell-labs.com

References ✨

okay bestie, last stop: the receipts 🧾 every source this doc leans on is listed below, so you can go read the originals if you want the full tea 💅

• [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-Packard Laboratories, December 1993. 🎀
• [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", Bellcore, RFC 2022, November 1996. 🦋
• [3] Luciani, J., et al, "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress, February 1997. 🌸
• [4] Armitage, G., "Issues affecting MARS Cluster Size", Bellcore, RFC 2121, March 1997. 💖
• [5] Armitage, G., "Redundant MARS architectures and SCSP", Bellcore, Work in Progress, November 1996. ✨
• [6] Luciani, J., G. Armitage, J. Jalpern, "Server Cache Synchronization Protocol (SCSP) - NBMA", Work in Progress, March 1997. 🧚
• [7] Rekhter, Y., D. Farinacci, "Support for Sparse Mode PIM over ATM", Cisco Systems, Work in Progress, April 1996. 👑