Issues affecting MARS Cluster Size
RFC 2121

Document Type RFC - Informational (March 1997; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2121 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      G. Armitage
Request for Comments: 2121                                    Bellcore
Category: Informational                                     March 1997

                   Issues affecting MARS Cluster Size

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.


   IP multicast over ATM currently uses the MARS model [1] to manage the
   use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope
   of any given MARS services is the MARS Cluster - typically the same
   as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are
   usually architected with unicast routing and forwarding issues
   dictating the sizes of individual LISes. However, as IP multicast is
   deployed as a service, the size of a LIS will only be as big as a
   MARS Cluster can be. This document provides a qualitative look at the
   issues constraining a MARS Cluster's size, including the impact of VC
   limits in switches and NICs, geographical distribution of cluster
   members, and the use of VC Mesh or MCS modes to support multicast

1. Introduction

   A MARS Cluster is the set of IP/ATM interfaces that are willing to
   engage in direct, ATM level pt-mpt SVCs to perform IP multicast
   packet forwarding [1]. 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.

   The definition of Cluster 'size' can mean two things - the number of
   MARS Clients using a given MARS, and the geographic distribution of
   MARS Clients. The number of MARS Clients in a Cluster impacts on the
   amount of state information any given client may need to store while
   managing  outgoing  pt- mpt SVCs. It also impacts on the average rate
   of JOIN/LEAVE traffic that is propagated by the MARS on
   ClusterControlVC, and the number of pt-mpt VCs that may need
   modification each time a MARS_JOIN or MARS_LEAVE appears on

Armitage                     Informational                      [Page 1]
RFC 2121           Issues affecting MARS Cluster Size         March 1997

   The geographic distribution of clients affects the latency between a
   client issuing a MARS_JOIN, and it finally being added onto the pt-
   mpt VCs of the other MARS Clients transmitting to the specified
   multicast group. (This latency is made up of both the time to
   propagate the MARS_JOIN, and the delay in the underlying ATM cloud's
   reaction to the subsequent ADD_PARTY messages.)

   When architecting an IP/ATM network it is important to understand the
   worst case scaling limits applicable to your Clusters. This document
   provides a primarily qualitative look at the design choices that
   impose the most dramatic constraints on Cluster size. Since the focus
   is on worst-case scenarios, most of the analysis will assume
   multicast groups that are VC Mesh based and have all cluster members
   as sources and receivers. Engineering using the worst-case boundary
   conditions, then applying optimisations such as Multicast Servers
   (MCS), provides the Cluster with a margin of safety.  It is hoped
   that more detailed quantitative analysis of Cluster sizing limits
   will be prompted by this document.

   Section 2 comments on the VC state requirements of the MARS model,
   while Sections 3 and 4 identify the group change processing load and
   latency characteristics of a cluster as a function of its size.
   Section 5 looks at how Multicast Routers (both conventional and
   combination router/switch architectures) increase the scale of a
   multicast capable IP/ATM network. Finally, Section 6 discusses how
   the use of Multicast Servers (MCS) might impact on the worst case
   Cluster size limits.

2. VC state limitations.

   Two characteristics of ATM NICs and switches will limit the number of
   members a Cluster may contain. They are:

      The maximum number of VCs that can be originated from, or
      terminate on, a port (VCmax).

      The maximum number of leaf nodes supportable by a root node

   We'll assume that the MARS node has similar VCmax and LEAFmax values
   as Cluster members.  VCmax affects the Cluster size because of the

      The MARS terminates a pt-pt control VC from each cluster member,
      and originates a VC for ClusterControlVC and ServerControlVC.

Armitage                     Informational                      [Page 2]
RFC 2121           Issues affecting MARS Cluster Size         March 1997

      When a multicast group is VC Mesh based, a group member terminates
Show full document text