Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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
 of the underlying link layer technology. A revised definition
    The set of NBMA interfaces chosing to participate in direct NBMA
    connections to achieve multicasting of packets between themselves.
 The term 'Cluster Member' continues to refer to an endpoint that is
 currently using a specific MARS for multicast support.  The potential
 scope of a cluster may be the entire membership of a LIS, while the
 actual scope of a cluster depends on which LIS members are actually
 registered with the cluster's MARS at any given time.
 Section 3.4 of [2] provided a set of mneumonics for the signalling
 functions available to AAL Users. These mneumonics are then used in
 the remainder of [2] to indicate link layer events to which MARS
 entities might react. Recast from the perspective of an NBMA based
 MARS entity, the descriptions would now read:
    The following generic signalling functions are presumed to be
    available to local MARS entities:
    L_CALL_RQ     Establish a pt-pt call to a specific endpoint.
    L_MULTI_RQ    Establish pt-mpt call to a specific endpoint.
    L_MULTI_ADD   Add new leaf node to previously established pt-mpt
    L_MULTI_DROP  Remove specific leaf node from established pt-mpt
    L_RELEASE     Release pt-pt call, or all Leaves of a pt-mpt call.

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

    The signalling exchanges and local information passed between MARS
    entity and NBMA signalling entity with these functions are outside
    the scope of this document.
    The following indications are assumed to be available to MARS
    entities, generated by by the local NBMA signalling entity:
    L_ACK           Succesful completion of a local request.
    L_REMOTE_CALL   A new call has been established to the MARS
    ERR_L_RQFAILED  A remote NBMA endpoint rejected an L_CALL_RQ,
                    L_MULTI_RQ, or L_MULTI_ADD.
    ERR_L_DROP      A remote NBMA endpoint dropped off an existing
    ERR_L_RELEASE   An existing call was terminated.
    The signalling exchanges and local information passed between MARS
    entity and NBMA signalling entity with these functions are outside
    the scope of this document.

4. Open Issues.

 The trade offs between VC Mesh and Multicast Server modes may look
 quite different for each NBMA technology. This will be especially
 true in the area of VC (or equivalent) resource consumption in the
 NICs of hosts, routers, and endpoints supporting MARSs or MCSs. The
 use of VC mesh mode is most vulnerable to NBMA technologies that are
 signalling intensive or resource challenged.
 Sizing of Clusters (and hence LISes) will also be affected by a given
 NBMA network's ability to support lots of pt-mpt calls.
 Additionally, you cannot have more members in a cluster than you can
 have leaf nodes on a pt-mpt call, without hacking the MARS model [6].
 On going developments in server synchronisation protocols for
 distributed RFC 2022 implementations are expected to be applicable to
 non-ATM NBMA networks.
 Quality of service considerations are outside the scope of this
 document. They will be very specific to each NBMA technology's
 capabilities. Related work is being pursued outside the ION Working
 If the NBMA network offers some sort of native multipoint to
 multipoint service then use of the MARS model may not be optimal.
 Such situations require further analysis.

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

Security Considerations

 This memo is informational, and specifies no protocol for deployment.
 No specific non-ATM NBMA network technologies or security
 characteristics are discussed. Should enhancements to security be
 required, they shall be added as an extension to the base
 architecture in RFC 2022, or described in documents explicitly
 proposing use of RFC 2022 over specific NBMA technologies.


 This memo was substantially developed while the author was with Bell
 Communications Research (Bellcore).

Author's Address

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


 [1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
 1112, Stanford University, August 1989.
 [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
 Networks.", RFC 2022, November 1996.
 [3] Luciani, J., et. al., "NBMA Next Hop Resolution Protocol (NHRP)",
 Work in Progress.
 [4] ATM Forum, "ATM User-Network Interface Specification Version
 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
 [5] ATM Forum, "ATM User Network Interface (UNI) Specification
 Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,
 NJ, June 1995.
 [6] Armitage, G., "Issues affecting MARS Cluster Size", RFC 2121,
 March 1997.

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

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an

Armitage Informational [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2269.txt · Last modified: 1998/01/22 23:11 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki