rfc2191.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 676 行 · 第 1/3 页

   shortcut on the remote cluster's Mrouter. The first client obviously
   needs to know about group membership changes in the remote cluster,
   whilst the second client does not. Propagating these JOIN/LEAVE
   messages on ClusterControlVC in the source cluster will not work -
   the MARS for the source cluster will need to explicitly send copies
   of the JOIN/LEAVE messages only to those MARS Clients whose prior SVC
   establishment phase indicates they need them. Propagation of messages
   to indicate a VC Mesh to MCS transition within clusters may also need
   to take account of the leaf node limitations of MARS Clients. The
   scaling characteristics of this problem are left to the readers
   imagination.

   It was noted in the previous section that a VENUS domain could be
   limited to ensure there are never more MARS Clients than any one
   client's leaf node limit. This would certainly avoid the need to for
   complicated MARS_JOIN/LEAVE propagation mechanisms. However, it begs
   the question of how different the VENUS domain then becomes from a
   single, large MARS Cluster.

4. What is the value in bypassing Mrouters?

   This is a good question, since the whole aim of developing a shortcut
   connection mechanism is predicated on the assumption that bypassing
   IP level entities is always a "win". However, this is arguably not
   true for multicast.

   The most important observation that should be made about shortcut
   connection scenarios is that they increase the exposure of any given
   IP/ATM interface to externally generated SVCs. If there are a
   potential 1000 senders in a VENUS Domain, then you (as a group
   member) open yourself up to a potential demand for 1000 instances of
   your re-assembly engine (and 1000 distinct incoming SVCs, when you
   get added as a leaf node to each sender's pt-mpt SVC, which your
   local switch port must be able to support).

   It should be no surprise that the ATM level scaling limits applicable
   to a single MARS Cluster [4] will also apply to a VENUS Domain. Again
   we're up against the question of why you'd bypass an Mrouter. As
   noted in [4] Mrouters perform a useful function of data path
   aggregation - 100 senders in one cluster become 1 pt-mpt SVC out of
   the Mrouter into the next cluster along the tree. They also hide MARS
   signaling activity - individual group membership changes in one
   cluster are hidden from IP/ATM interfaces in surrounding clusters.
   The loss of these benefits must be factored into any network designed
   to utilize multicast shortcut connections.






Armitage                     Informational                      [Page 9]

RFC 2191                         VENUS                    September 1997


   (For the sake of completeness, it must be noted that extremely poor
   mismatches of IP and ATM topologies may make Mrouter bypass
   attractive if it improves the use of the underlying ATM cloud. There
   may also be benefits in removing the additional re-
   assembly/segmentation latencies of having packets pass through an
   Mrouter. However, a VENUS Domain ascertained to be small enough to
   avoid the scaling limits in [4] might just as well be constructed as
   a single large MARS Cluster. A large cluster also avoids a
   topological mismatch between IP Mrouters and ATM switches.)

5. Relationship to Distributed MARS protocols.

   The ION working group is looking closely at the development of
   distributed MARS architectures. An outline of some issues is provided
   in [5,6]. As noted earlier in this document the problem space looks
   very similar that faced by our hypothetical VENUS Domain. For
   example, in the load-sharing distributed MARS model:

      - The Cluster is partitioned into sub-clusters.

      - Each Active MARS is assigned a particular sub-cluster, and uses
      its own sub-ClusterControlVC to propagate JOIN/LEAVE messages to
      members of its sub-cluster.

      - The MARS_REQUEST from any sub-cluster member must return
      information from all the sub-clusters, so as to ensure that all a
      group's members across the cluster are identified.

      - Group membership changes in any one sub-cluster must be
      immediately propagated to all the other sub-clusters.

   There is a clear analogy to be made between a distributed MARS
   Cluster, and a VENUS Domain made up of multiple single-MARS Clusters.
   The information that must be shared between sub-clusters in a
   distributed MARS scenario is similar to the information that must be
   shared between Clusters in a VENUS Domain.

   The distributed MARS problem is slightly simpler than that faced by
   VENUS:

      - There are no Mrouters (IDMR nodes) within the scope of the
      distributed Cluster.

      - In a distributed MARS Cluster an MCS supported group uses the
      same MCS across all the sub-clusters (unlike the VENUS Domain,
      where complete generality makes it necessary to cope with mixtures
      of MCS and VC Mesh based Clusters).




Armitage                     Informational                     [Page 10]

RFC 2191                         VENUS                    September 1997


6. Conclusion.

   This document has described a hypothetical multicast shortcut
   connection scheme, dubbed "Very Extensive NonUnicast Service"
   (VENUS).  The two phases of multicast support - SVC establishment,
   and SVC management - are shown to be essential whether the scope is a
   Cluster or a wider VENUS Domain. It has been shown that once the
   potential scope of a pt-mpt SVC at establishment phase has been
   expanded, the scope of the SVC management mechanism must similarly be
   expanded. This means timely tracking and propagation of group
   membership changes across the entire scope of a VENUS Domain.

   It has also been noted that there is little difference in result
   between a VENUS Domain and a large MARS Cluster. Both suffer from the
   same fundamental scaling limitations, and both can be arranged to
   provide shortcut of unicast routing boundaries. However, a completely
   general multi-cluster VENUS solution ends up being more complex. It
   needs to deal with bypassed Mrouter boundaries, and dynamically
   changing group membership densities along multicast distribution
   trees established by the IDMR protocols in use.

   No solutions have been presented. This document's role is to provide
   context for future developments.

Acknowledgment

   This document was prepared while the author was with the
   Internetworking Research group at Bellcore.

Security Considerations

   This memo addresses specific scaling issues associated with the
   extension of the MARS architecture beyond that described in RFC 2022.
   It is an Informational memo, and does not mandate any additional
   protocol behaviors beyond those described in RFC 2022.  As such, the
   security implications are no greater or less than the implications
   inherent in RFC 2022.  Should enhancements to security be required,
   they would need to be added as an extension to the base architecture
   in RFC 2022.












Armitage                     Informational                     [Page 11]

RFC 2191                         VENUS                    September 1997


Author's Address

   Grenville Armitage
   Bell Labs, Lucent Technologies.
   101 Crawfords Corner Rd,
   Holmdel, NJ, 07733
   USA

   EMail: [e-mail]


References

   [1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-
   Packard Laboratories, December 1993.

   [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
   Networks.", Bellcore, RFC 2022, November 1996.

   [3] Luciani, J., et al, "NBMA Next Hop Resolution Protocol (NHRP)",
   Work in Progress, February 1997.

   [4] Armitage, G., "Issues affecting MARS Cluster Size", Bellcore, RFC
   2121, March 1997.

   [5] Armitage, G., "Redundant MARS architectures and SCSP", Bellcore,
   Work in Progress, November 1996.

   [6] Luciani, J., G. Armitage, J. Jalpern, "Server Cache
   Synchronization Protocol (SCSP) - NBMA", Work in Progress, March 1997.

   [7] Rekhter, Y., D. Farinacci, " Support for Sparse Mode PIM over
   ATM", Cisco Systems, Work in Progress, April 1996.


















Armitage                     Informational                     [Page 12]