RFC 2191 (rfc2191) - Page 2 of 12
VENUS - Very Extensive Non-Unicast Service
Alternative Format: Original Text Document
RFC 2191 VENUS September 1997 before being re-applied to the multicast scenario. Indeed, the service provided by the MARS and MARS Clients in [2] are almost orthogonal to the IP unicast service over ATM. For the sake of discussion, let's call this hypothetical multicast shortcut discovery protocol the "Very Extensive Non-Unicast Service" (VENUS). A "VENUS Domain" is defined as 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. (It will be noted in section 2 that a VENUS Domain might consist of a single MARS Cluster spanning multiple LISs, or multiple MARS Clusters.) VENUS faces a number of fundamental problems. The first is exploding the scope over which individual IP/ATM interfaces must track and react to IP multicast group membership changes. Under the classical IP routing model Mrouters act as aggregation points for multicast traffic flows in and out of Clusters [4]. They also act as aggregators of group membership change information - 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. However, once you have sources within a VENUS Domain establishing shortcut connections the data and signaling plane aggregation of Mrouters is lost. In order for all possible sources throughout a VENUS Domain to manage their outgoing pt-mpt SVCs they must be kept aware of MARS_JOINs and MARS_LEAVEs occuring in every MARS Cluster that makes up a VENUS Domain. The nett effect is that a VENUS domain looks very similar to a single, large distributed MARS Cluster. A second problem is the impact that shortcut connections will have on IP level Inter Domain Multicast Routing (IDMR) protocols. Multicast groups have many sources and many destinations scattered amongst the participating Clusters. IDMR protocols assume that they can calculate 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 are able to simply bypass an Mrouter we introduce a requirement that the existence of each and every shortcut connection be 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 is injected into Mrouters at more distant points on the IP-level multicast distribution tree. (This issue has been looked at in [7], focussing on building forwarding trees within networks where the termination points are small in number and sparsely distributed. VENUS introduces tougher requirements by assuming that multicast group membership may be dense across the region of interest.) Armitage Informational
