Using the MARS Model in non-ATM NBMA Networks
RFC 2269

Document Type RFC - Informational (January 1998; 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 2269 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      G. Armitage
Request for Comments: 2269                         Lucent Technologies
Category: Informational                                   January 1998

             Using the MARS Model in non-ATM NBMA Networks

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   Initially developed for IP over ATM, the RFC 2022 (MARS) model is
   also applicable to other NBMA networks that provide the equivalent of
   switched, point to multipoint connections. This short document is
   intended to state the obvious equivalences, and explain the less
   obvious implications. No changes to the MARS model per se are
   suggested or required. RFC 2022 is not required over NBMA networks
   that offer Ethernet-like group addressing functionality.

1. Introduction

   Most network layer models, like the one described in STD 5, RFC 1112
   [1] for IP multicasting, assume sources may send their packets to an
   abstract 'multicast group addresses'.  Link layer support for such an
   abstraction is assumed to exist, and is provided by technologies such
   as Ethernet.

   Some NBMA networks (e.g. ATM using UNI3.0 or UNI3.1 signaling [4,5])
   do not support a multicast (or group) address abstraction. In these
   environments multicasting is typically supported through point to
   multipoint calls (or emulated with multiple point to point calls).
   The MARS model (RFC 2022) [2] was originally developed by the IP over
   ATM working group, and so uses ATM-centric descriptive language.  For
   completeness this memo explains how RFC 2022 can be applied to other
   NBMA technologies.

Armitage                     Informational                      [Page 1]
RFC 2269          MARS Model in non-ATM NBMA Networks       January 1998

2.  RFC 2022's basic assumptions.

   Section 3 of [2] describes the basic assumptions that the MARS model
   makes about the services available from the link layer network (using
   ATM as the specific case).  In summary these are:

      The ATM model broadly describes an 'AAL User' as any entity that
      establishes and manages VCs and underlying AAL services to
      exchange data.  An IP over ATM interface is a form of 'AAL User'

      The most fundamental limitations of UNI 3.0/3.1's multicast
      support are:

         Only point to multipoint, unidirectional VCs may be

         Only the root (source) node of a given VC may add or remove
         leaf nodes.

      Leaf nodes are identified by their unicast ATM addresses.

   Given this point to multipoint call service, the MARS document goes
   on to describe two architectures for emulating multipoint to
   multipoint IP multicasting - the VC Mesh, and the Multicast Server.
   In either case it was assumed that IP/ATM interfaces (whether in
   routers or hosts) are allowed to originate and manage outgoing point
   to multipoint calls without network operator intervention or manual

   The MARS document also specifies that AAL5 be used for all SVCs,
   implying a requirement that the underlying link service supports the
   atomic exchange of PDUs.

3.  Generalising the MARS model.

   Any NBMA service that offers an equivalent to (or superset of) the
   ATM point to multipoint call service can use the MARS model directly.
   It must be possible to transmit atomic data units bi-directionally
   with point to point calls, and unidirectionally (from root to leaves)
   on point to multipoint calls.

   A MARS is an entity known by its NBMA address.

   A MARS Client is an entity known by its NBMA address.

   An MCS (where needed) is an entity known by its NBMA address.

Armitage                     Informational                      [Page 2]
RFC 2269          MARS Model in non-ATM NBMA Networks       January 1998

   The MARS control messages defined in sections 4 onwards of the MARS
   document are shown carrying ATM addresses.  Using different mar$afn
   (Address Family) values in the fixed header of MARS control messages
   allows MARS entities to indicate they are carrying other types of
   NBMA addresses (as done in NHRP [3]).  As for NHRP, the
   interpretation of the 'sub-address' fields shall be in the context of
   the address family selected (which means it will often simply be

   In all cases where {IP, ATM.1, ATM.2, ...} mappings are referred to,
   they may be interpreted as {IP, NBMA.1, NBMA.2, ...} in the context
   of whatever NBMA network you are deploying MARS.

   The MARS Cluster is defined in [2] as:

      The set of ATM interfaces chosing to participate in direct ATM
      connections to achieve multicasting of AAL_SDUs between

   It is trivial to observe that the cluster definition is independent
Show full document text