VENUS - Very Extensive Non-Unicast Service
RFC 2191

Document Type RFC - Informational (September 1997; No errata)
Was draft-armitage-ion-venus (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2191 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      G. Armitage
Request for Comments: 2191                         Lucent Technologies
Category: Informational                                 September 1997

               VENUS - Very Extensive Non-Unicast Service

Status of this Memo

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

Abstract

   The MARS model (RFC2022) provides a solution to intra-LIS IP
   multicasting over ATM, establishing and managing the use of ATM pt-
   mpt SVCs for IP multicast packet forwarding. Inter-LIS multicast
   forwarding is achieved using Mrouters, in a similar manner to which
   the "Classical IP over ATM" model uses Routers to inter-connect LISes
   for unicast traffic. The development of unicast IP shortcut
   mechanisms (e.g.  NHRP) has led some people to request the
   development of a Multicast equivalent. There are a number of
   different approaches. This document focuses exclusively on the
   problems associated with extending the MARS model to cover multiple
   clusters or clusters spanning more than one subnet. It describes a
   hypothetical solution, dubbed "Very Extensive NonUnicast Service"
   (VENUS), and shows how complex such a service would be. It is also
   noted that VENUS ultimately has the look and feel of a single, large
   cluster using a distributed MARS.  This document is being issued to
   help focus ION efforts towards alternative solutions for establishing
   ATM level multicast connections between LISes.

1. Introduction

   The classical model of the Internet running over an ATM cloud
   consists of multiple Logical IP Subnets (LISs) interconnected by IP
   Routers [1].  The evolving IP Multicast over ATM solution (the "MARS
   model" [2]) retains the classical model. The LIS becomes a "MARS
   Cluster", and Clusters are interconnected by conventional IP
   Multicast routers (Mrouters).

   The development of NHRP [3], a protocol for discovering and managing
   unicast forwarding paths that bypass IP routers, has led to some
   calls for an IP multicast equivalent.  Unfortunately, the IP
   multicast service is a rather different beast to the IP unicast
   service. This document aims to explain how much of what has been
   learned during the development of NHRP must be carefully scrutinized

Armitage                     Informational                      [Page 1]
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
Show full document text