RFC 2269

Using the MARS Model in non-ATM NBMA Networks

📅 published January 1998, from ietf

Using the MARS Model in non-ATM NBMA Networks ✨

okay bestie, here's the whole vibe check 🎀

  • RFC: 2269
  • Series: Network Working Group
  • Author: Grenville "G." Armitage, Lucent Technologies 🦋
  • Category: Informational
  • Date: January 1998
  • Obsoletes: nothing listed 🙈
  • Updates: nothing listed 🙈

Status of this Memo 📝

this memo is just giving info to the internet community 🌸 it is NOT a standard of any kind, and distribution is unlimited.

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

Abstract 💜

okay so MARS (the RFC 2022 model) was built for IP over ATM, but it's giving "works for other NBMA networks too" 💅 those networks just need to offer the equivalent of switched, point to multipoint connections. this short doc states the obvious equivalences and explains the sneakier implications 👀 no changes to the MARS model itself are suggested or required. and RFC 2022 isn't needed over NBMA networks that already offer Ethernet-like group addressing ✨

1. Introduction 🌈

most network layer models, like the one in STD 5, RFC 1112 [1] for IP multicasting, assume that sources can send packets to an abstract 'multicast group address' 🫶 the link layer is expected to support that abstraction, and Ethernet does it for us.

some NBMA networks (ATM with UNI3.0 or UNI3.1 signaling [4,5] is the main example) don't have a multicast or group address abstraction at all 😭 there, multicasting usually happens through point to multipoint calls, or gets emulated with a bunch of point to point calls. the MARS model (RFC 2022) [2] came from the IP over ATM working group, so it talks in very ATM-flavoured language. for completeness, this memo explains how RFC 2022 can be used with other NBMA technologies 🧚

2. RFC 2022's basic assumptions. 🎀

okay so Section 3 of [2] describes the basic assumptions MARS makes about what the link layer network provides (using ATM as the example). the summary:

ATM's model basically describes an 'AAL User' as any entity that sets up and manages VCs and the underlying AAL services to exchange data. an IP over ATM interface counts as a form of 'AAL User' 💖

UNI 3.0/3.1's multicast support has two biggest limitations:

  • only point to multipoint, unidirectional VCs can be set up.
  • only the root (source) node of a given VC can add or remove leaf nodes.

leaf nodes are identified by their unicast ATM addresses 🍓

given this point to multipoint call service, the MARS doc describes two architectures for emulating multipoint to multipoint IP multicasting: the VC Mesh and the Multicast Server 🦋 either way, it was assumed that IP/ATM interfaces (in routers or hosts) can start and manage outgoing point to multipoint calls without any network operator intervention or manual provisioning ✨

one more thing: the MARS doc also says AAL5 is used for all SVCs, which implies the underlying link service has to support atomic exchange of PDUs 🔥

3. Generalising the MARS model. 🌸

any NBMA service that offers an equivalent to (or a superset of) the ATM point to multipoint call service can use the MARS model directly 💅 it has to be possible to send atomic data units bi-directionally over point to point calls, and unidirectionally (from root to leaves) over 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. 🫶

the MARS control messages in sections 4 onwards of the MARS doc show ATM addresses. using different mar$afn (Address Family) values in the fixed header of MARS control messages lets MARS entities say they're carrying other kinds of NBMA addresses, which is what NHRP [3] does too 🧚 just like NHRP, the interpretation of the 'sub-address' fields is set by the address family you picked (so it'll often just be null).

wherever {IP, ATM.1, ATM.2, ...} mappings show up, you can read them as {IP, NBMA.1, NBMA.2, ...} for whatever NBMA network you're deploying MARS on 🌈

the MARS Cluster is defined in [2] like this:

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

it's trivial to see that the cluster definition doesn't depend on the underlying link layer tech 🙈 so the revised definition is:

The set of NBMA interfaces chosing to participate in direct NBMA
connections to achieve multicasting of packets between themselves.

'Cluster Member' still refers to an endpoint that's currently using a specific MARS for multicast support 💜 the potential scope of a cluster can be the entire membership of a LIS, but the actual scope depends on which LIS members are actually registered with that cluster's MARS at any given time.

Section 3.4 of [2] gave a set of mnemonics for the signalling functions available to AAL Users, and the rest of [2] uses them to show which link layer events MARS entities might react to 👀 recast from the view of an NBMA-based MARS entity, they 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
              call.
L_MULTI_DROP  Remove specific leaf node from established pt-mpt
              call.
L_RELEASE     Release pt-pt call, or all Leaves of a pt-mpt call.

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
                entity.
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
                call.
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 can look totally different for each NBMA tech 😤 this is especially true for VC (or equivalent) resource use in the NICs of hosts, routers, and endpoints running MARSs or MCSs. VC mesh mode is most at risk on NBMA techs that are signalling intensive or resource challenged 💀

the size of clusters (and therefore LISes) is also affected by how well a given NBMA network can handle lots of pt-mpt calls 🫠 plus, you cannot have more members in a cluster than you can have leaf nodes on a pt-mpt call, unless you hack the MARS model [6] 🙅‍♀️

ongoing developments in server synchronisation protocols for distributed RFC 2022 implementations are expected to work for non-ATM NBMA networks too 🧚

quality of service is outside the scope of this doc. it'll be super specific to each NBMA tech's capabilities, and related work is being pursued outside the ION Working Group 💅

and if the NBMA network offers some native multipoint to multipoint service, using the MARS model may not be optimal. those situations need further analysis 🔍

Security Considerations 🔐

this part is serious, bestie 😭🔐 this memo is informational and doesn't specify a protocol for deployment. no specific non-ATM NBMA network technologies or security characteristics are discussed. if security enhancements are needed, they shall be added as an extension to the base architecture in RFC 2022, or described in documents that explicitly propose using RFC 2022 over specific NBMA technologies.

Acknowledgments 🫶

this memo was mostly developed while the author was at Bell Communications Research (Bellcore) 🌷

Author's Address 📮

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

EMail: gja@lucent.com

References 📚

  • [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.
legal bits, kept word for word so nothing gets lost in translation 🙏

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

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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ✨

📦 where this page comes from