RFC 2191 (rfc2191) - Page 2 of 12

VENUS - Very Extensive Non-Unicast Service

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