Browse Prior Art Database

Issues affecting MARS Cluster Size (RFC2121)

IP.com Disclosure Number: IPCOM000002675D
Original Publication Date: 1997-Mar-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 12 page(s) / 17K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Armitage: AUTHOR

Related Documents

10.17487/RFC2121: DOI

Abstract

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 groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 13% of the total text.

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.

Abstract

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 groups.

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 ClusterControlVC.

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 ba...

Processing...
Loading...