rfc2191.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 676 行 · 第 1/3 页

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
   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                      [Page 2]

RFC 2191                         VENUS                    September 1997


   This document will focus primarily on the internal problems of a
   VENUS Domain, and leave the IDMR interactions for future analysis.

2. What does it mean to "shortcut" ?

   Before going further it is worth considering both the definition of
   the Cluster, and 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 regarding the ATM addresses of each leaf
   node (recipient) of each pt-mpt SVC it has open. In addition, each
   MARS Client receives MARS_JOIN and MARS_LEAVE messages from the MARS
   whenever there is a requirement that Clients around the Cluster need
   to update their pt-mpt SVCs for a given IP multicast group.

   It is worth noting that no MARS Client has any concept of how big its
   local cluster is - this knowledge is kept only by the MARS that a
   given Client is registered with.

   Fundamentally the Cluster (and the MARS model as a whole) is a
   response to the requirement that any multicast IP/ATM interface using
   pt-mpt SVCs must, as group membership changes, add and drop leaf
   nodes itself. This means that some mechanism, spanning all possible
   group members within the scopes of these pt-mpt SVCs, is required to
   collect group membership information and distribute it in a timely
   fashion to those interfaces.  This is the MARS Cluster, with certain
   scaling limits described in [4].

2.2 LIS/Cluster boundary "shortcut"

   The currently popular definition of "shortcut" is based on the
   existence of unicast LIS boundaries. It is tied to the notion that
   LIS boundaries have physical routers, and cutting through a LIS
   boundary means bypassing a router. Intelligently bypassing routers
   that sit at the edges of LISs has been the goal of NHRP. Discovering
   the ATM level identity of an IP endpoint in a different LIS allows a
   direct SVC to be established, thus shortcutting the logical IP
   topology (and very real routers) along the unicast path from source
   to destination.

   For simplicity of early adoption RFC2022 recommends that a Cluster's
   scope be made equivalent to that of a LIS. Under these circumstances
   the "Classical IP" routing model places Mrouters at LIS/Cluster
   boundaries, and multicast shortcutting must involve bypassing the



Armitage                     Informational                      [Page 3]

RFC 2191                         VENUS                    September 1997


   same physical routing entities as unicast shortcutting. Each MARS
   Cluster would be independent and contain only those IP/ATM interfaces
   that had been assigned to the same LIS.

   As a consequence, a VENUS Domain covering the hosts in a number of
   LIS/Clusters would have to co-ordinate each individual MARS from each
   LIS/Cluster (to ensure group membership updates from around the VENUS
   Domain were propagated correctly).

2.3 Big Cluster, LIS boundary "shortcut"

   The MARS model's fundamental definition of a Cluster was deliberately
   created to be independent of unicast terminology. Although not
   currently well understood, it is possible to build a single MARS
   Cluster that encompasses 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 their IP multicast
   packets directly to intra-cluster group members. However, because the
   direct intra-cluster SVCs would 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 brings up the problem of how the IDMR
   protocols will react. Mrouters only need to exist at the edges of
   Clusters. In the case of a single Cluster spanning multiple LISs,
   each LIS becomes 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 is only a
   single Mrouter in or out of the Cluster. Problems arise 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 be confused at
   receiving 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
   that needs to be addressed by any multicast shortcut scheme. It has
   been noted before and a solution proposed in [7]. For the sake of
   argument this document will assume the problem solvable. (However, it
   is important that any solution scales well under general topologies
   and group membership densities.)






Armitage                     Informational                      [Page 4]