Browse Prior Art Database

Multicast Server Architectures for MARS-based ATM multicasting (RFC2149)

IP.com Disclosure Number: IPCOM000002705D
Original Publication Date: 1997-May-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 15 page(s) / 39K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Talpade: AUTHOR [+2]

Abstract

A mechanism to support the multicast needs of layer 3 protocols in general, and IP in particular, over UNI 3.0/3.1 based ATM networks has been described in RFC 2022. Two basic approaches exist for the intra-subnet (intra-cluster) multicasting of IP packets. One makes use of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the other uses a shared point to multipoint tree rooted on a Multicast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 8% of the total text.

Network Working Group R. Talpade

Request for Comments: 2149 M. Ammar

Category: Informational Georgia Institute of Technology

May 1997

Multicast Server Architectures for MARS-based ATM multicasting

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

A mechanism to support the multicast needs of layer 3 protocols in

general, and IP in particular, over UNI 3.0/3.1 based ATM networks

has been described in RFC 2022. Two basic approaches exist for the

intra-subnet (intra-cluster) multicasting of IP packets. One makes

use of a mesh of point to multipoint VCs (the 'VC Mesh' approach),

while the other uses a shared point to multipoint tree rooted on a

Multicast Server (MCS). This memo provides details on the design and

implementation of an MCS, building on the core mechanisms defined in

RFC 2022. It also provides a mechanism for using multiple MCSs per

group for providing fault tolerance. This approach can be used with

RFC 2022 based MARS server and clients, without needing any change in

their functionality.

1 Introduction

A solution to the problem of mapping layer 3 multicast service over

the connection-oriented ATM service provided by UNI 3.0/3.1, has been

presented in [GA96]. A Multicast Address Resolution Server (MARS) is

used to maintain a mapping of layer 3 group addresses to ATM

addresses in that architecture. It can be considered to be an

extended analog of the ATM ARP Server introduced in RFC 1577

([ML93]). Hosts in the ATM network use the MARS to resolve layer 3

multicast addresses into corresponding lists of ATM addresses of

group members. Hosts keep the MARS informed when they need to join

or leave a particular layer 3 group.

The MARS manages a "cluster" of ATM-attached endpoints. A "cluster"

is defined as

"The set of ATM interfaces choosing to participate in direct ATM

connections to achieve multicasting of AALSDUs between themselves."

In practice, a cluster is the set of endpoints that choose to use the

same MARS to register their memberships and receive their updates

from.

A sender in the cluster has two options for multicasting data to the

group members. It can either get the list of ATM addresses

constituting the group from the MARS, set up a point-to-multipoint

virtual circuit (VC) with the group members as leaves, and then

proceed to send data out on it. Alternatively, the source can make

use of a proxy Multicast Server (MCS). The source transmits data to

such an MCS, which in turn uses a point-to-multipoint VC to get the

data to the group members.

The MCS approach has been briefly introduced in [GA96]. This memo

presents a detailed description of MCS ...