rfc2191.txt

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


RFC 2191                         VENUS                    September 1997


   A multi-LIS MARS Cluster can be considered a simple VENUS Domain.
   Since it is a single Cluster it can be scaled using the distributed
   MARS solutions currently being developed within the IETF [5,6].

3. So what must VENUS look like?

   A number of functions that occur in the MARS model are fundamental to
   the problem of managing root controlled, pt-mpt SVCs. The initial
   setup of the forwarding SVC by any one MARS Client requires a
   query/response exchange with the Client's local MARS, establishing
   who the current group members are (i.e. what leaf nodes should be on
   the SVC). Following SVC establishment comes the management phase -
   MARS Clients need to be kept informed of group membership changes
   within the scopes of their SVCs, so that leaf nodes may be added or
   dropped as appropriate.

   For intra-cluster multicasting the current MARS approach is our
   solution for these two phases.

   For the rest of this document we will focus on what VENUS would look
   like when a VENUS Domain spans multiple MARS Clusters. Under such
   circumstances VENUS is a mechanism co-ordinating the MARS entities of
   each participating cluster. Each MARS is kept up to date with
   sufficient domain-wide information to support both phases of client
   operation (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 is supplied information on group
   members from all participating clusters.

   The following subsections look at the problems associated with both
   of these phases independently. To a first approximation the problems
   identified are independent of the possible inter-MARS mechanisms. The
   reader may assume the MARS in any cluster has some undefined
   mechanism for communicating with the MARSs of clusters immediately
   adjacent to its own cluster (i.e. connected by a single Mrouter hop).

3.1 SVC establishment - answering a MARS_REQUEST.

   The SVC establishment phase contains a number of inter-related
   problems.

   First, the target of a MARS_REQUEST (an IP multicast group) is an
   abstract entity. Let us assume that VENUS does not require every MARS
   to know the entire list of group members across the participating
   clusters.  In this case each time a MARS_REQUEST is received by a
   MARS from a local client, the MARS must construct a sequence of
   MARS_MULTIs based on locally held information (on intra-cluster
   members) and remotely solicited information.



Armitage                     Informational                      [Page 5]

RFC 2191                         VENUS                    September 1997


   So how does it solicit this information? Unlike the unicast
   situation, there is 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. Let us allow one obvious
   optimization - the MARS_REQUEST is propagated along the IP multicast
   forwarding tree that has been established for the target group by
   whatever IDMR protocol is running at the time.

   As noted in [4] there are various reasons why a Cluster's scope 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 that the requesting MARS Client can handle. This
   provides VENUS with an interesting problem of propagating out the
   original MARS_REQUEST, but curtailing the MARS_REQUESTs propagation
   when a sufficient number of group members have been identified.
   Viewed from a different perspective, this means that the scope of
   shortcut achievable by any given MARS Client may depend greatly 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 appear that 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 nett effect would be
   that the MARS Client establishes a shortcut to many hosts that are
   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



Armitage                     Informational                      [Page 6]

RFC 2191                         VENUS                    September 1997


   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.

   Once a client's pt-mpt SVC is established, it must be kept up to
   date.  The consequence of this 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 introduce complications described below).
   Unfortunately, the consequential signaling load (as all the
   participating MARSs start broadcasting their MARS_JOIN/LEAVE
   activity) is not localized to clusters containing MARS Clients who
   have established shortcut SVCs.  Since the IP multicast model is Any
   to Multipoint, and you can never know where there may be source MARS
   Clients, the JOINs and LEAVEs must be propagated everywhere, always,
   just in case. (This is simply a larger scale version of sending JOINs
   and LEAVEs to every cluster member over ClusterControlVC, and for
   exactly the same reason.)

   The use of MCSs in some clusters instead of VC Meshes significantly
   complicates the situation, as does the initial scoping of a client's
   shortcut during the SVC establishment phase (described in the
   preceding section).

   In Clusters where MCSs are supporting certain groups, MARS_JOINs or
   MARS_LEAVEs are only propagated to MARS Clients when an MCS comes or
   goes. However, it is not clear how to effectively accommodate the
   current MARS_MIGRATE functionality (that allows a previously VC Mesh
   based group to be shifted to an MCS within the scope of a single



Armitage                     Informational                      [Page 7]

RFC 2191                         VENUS                    September 1997


   cluster). If an MCS starts up within a single Cluster, it is possible
   to shift all the intra-cluster senders to the MCS using MARS_MIGRATE
   as currently described in the MARS model. However, MARS Clients in
   remote clusters that have shortcut SVCs into the local cluster also
   need some signal to shift (otherwise they will continue to send their
   packets directly to the group members in the local cluster).

   This is a non-trivial requirement, since 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 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 needs to respect the
   Client's limited capacity for handling leaf nodes on its SVC. If the
   MARS Client initially issued a MARS_REQUEST and indicated it could
   handle 1000 leaf nodes, it is not clear how to ensure that subsequent
   joins of new members wont exceed that limit. Furthermore, if the SVC
   establishment phase decided that the SVC would stop at a particular
   Mrouter (due to leaf node limits being reached), the Client probably
   should not be receiving direct MARS_JOIN or MARS_LEAVE messages
   pertaining to activity in the cluster "behind" this Mrouter. (To do
   otherwise could lead to multiple copies of the source client's
   packets reaching group members inside the remote cluster - one
   version through the Mrouter, and another on the direct SVC connection
   that the source client would establish after receiving a subsequent,
   global MARS_JOIN regarding a host inside the remote cluster.)

   Another scenario involves the density of group members along the IDMR
   multicast tree increasing with time after the initial MARS_REQUEST is
   answered. Subsequent JOINs from Cluster members may dictate that a
   "closer" Mrouter be used to aggregate the source's outbound traffic
   (so as not to exceed the source's 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, this scoping of the VENUS domain-wide
   propagation of MARS_JOINs and MARS_LEAVEs needs to be on a per-
   source- cluster basis, at least. If MARS Clients within the same
   cluster have different leaf node limits, the problem worsens. Under
   such circumstances, one client may have been able to establish a
   shortcut SVC directly into a remote cluster while a second client -
   in the same source cluster - may have been forced to terminate its



Armitage                     Informational                      [Page 8]

RFC 2191                         VENUS                    September 1997