RFC 2149

Multicast Server Architectures for MARS-based ATM multicasting 💖

RFC 2149 🎀 ~ "Multicast Server Architectures for MARS-based ATM multicasting"

Authors: R. Talpade and M. Ammar, from Georgia Institute of Technology 🧚

Category: Informational ✨ (it's giving "here's some info," not "this is a standard")

Date: May 1997 🌸

Obsoletes / Updates: nothing is listed in this header 🙈

---

Status of This Memo ✨

okay so this memo is just here to give the Internet community some info 💅 It does not define an Internet standard of any kind, and it can be shared with literally anyone 🦋

Abstract 🌈

so layer 3 protocols (IP especially!) need multicast support over UNI 3.0/3.1 based ATM networks, and that was already described in RFC 2022 💜 There are two main ways to do multicasting inside an IP subnet (or "cluster"). One is the 'VC Mesh' approach, which is a mesh of point to multipoint VCs. The other is a shared point to multipoint tree rooted on a Multicast Server (MCS) 🔥

This memo gets into how an MCS is designed and built, building on the core stuff from RFC 2022 🫶 It also shows how to use multiple MCSs per group for fault tolerance, which is so smart 👑 The best part is that this works with RFC 2022 based MARS servers and clients without changing their functionality at all ✨

1. Introduction ✨

okay so a solution for mapping layer 3 multicast over the connection-oriented ATM service from UNI 3.0/3.1 was already presented in [GA96] 🦋 That architecture uses a Multicast Address Resolution Server (MARS) to keep track of which layer 3 group addresses map to which ATM addresses 💖 You can think of it as an extended version of the ATM ARP Server from RFC 1577 ([ML93]) 🧚 ATM hosts ask the MARS to turn layer 3 multicast addresses into lists of ATM addresses for group members. And when a host needs to join or leave a layer 3 group, it lets the MARS know 🌸

The MARS manages a "cluster" of ATM-attached endpoints 🎀 Here's the official definition:

"The set of ATM interfaces choosing to participate in direct ATM connections to achieve multicasting of AALSDUs between themselves."

ngl, in practice a cluster is just the group of endpoints that all pick the same MARS to register their memberships with and get their updates from 💅

So a sender in the cluster has two options for multicasting to the group members 👑 Option one: it asks the MARS for the list of ATM addresses in the group, sets up a point-to-multipoint virtual circuit (VC) with those members as leaves, and then starts sending data on it 🔥 Option two: it uses a proxy Multicast Server (MCS) instead. The source sends its data to the MCS, and the MCS uses a point-to-multipoint VC to get the data to the group members 🦋

The MCS approach was briefly introduced in [GA96] 🌈 This memo goes deeper into the MCS architecture and proposes a simple mechanism for running multiple MCSs for fault tolerance 💜 We're assuming you already understand IP multicasting over UNI 3.0/3.1 ATM networks from [GA96], and that you have access to it 🫶

Here's how the doc is laid out, bestie 🧚 Section 2 covers the interactions with the local UNI 3.0/3.1 signaling entity that get used later on (originally described in [GA96]). Section 3 presents an MCS architecture and how it talks to the MARS 🌸 Section 4 explains how an MCS actually works 🎀 Section 5 covers using multiple MCSs for the same layer 3 group and the mechanism needed to make that work ✨ And Appendix A compares the VC Mesh approach with the MCS approach 👑

to be continued... (part 1 of 4 💖 more coming, don't you dare leave me on read 😭)

2. Interaction with the local UNI 3.0/3.1 signaling entity 🦋

so the following generic signaling functions are presumed to be available to local AAL Users 💅

LCALL-RQ - Establish a unicast VC to a specific endpoint.
LMULTI-RQ - Establish multicast VC to a specific endpoint.
LMULTI-ADD - Add new leaf node to previously established VC.
LMULTI-DROP - Remove specific leaf node from established VC.
LRELEASE - Release unicast VC, or all Leaves of a multicast VC.

and these indications are assumed to be available to AAL Users too, generated by the local UNI 3.0/3.1 signaling entity (I'm literally obsessed with how these are named) 🌈

LACK - Succesful completion of a local request.
LREMOTE-CALL - A new VC has been established to the AAL User.
ERRL-RQFAILED - A remote ATM endpoint rejected an LCALLRQ,
                      LMULTIRQ, or L-MULTIADD.
ERRL-DROP - A remote ATM endpoint dropped off an existing VC.
ERRL-RELEASE - An existing VC was terminated.

3. MCS Architecture 🧚

okay the MCS is basically a proxy server 💖 It multicasts data it gets from a source out to the group members in the cluster 🌸 Every multicast source sends its data to the specified MCS for that group. Then the MCS forwards that data over a point to multipoint VC it maintains to the group members in the cluster 🎀 So each multicast source keeps just one point-to-multipoint VC going to its designated MCS for the group 🦋 And the designated MCS terminates one point-to-multipoint VC from each cluster member that's multicasting to the layer 3 group. Each group member is a leaf of the point-to-multipoint VC that starts at the MCS 👑

[GA96] has a brief intro to the possible MCS architectures 💜 Its main contribution for the MCS approach is spelling out how the MARS talks to the MCS. The next section lists the control messages the MARS and MCS swap ✨

3.1. Control Messages exchanged by the MCS and the MARS 🔥

the MARS and the MCS exchange the following control messages 🫶

operation code                Control Message

      1                       MARS_REQUEST
      2                       MARS_MULTI
      3                       MARS_MSERV
      6                       MARS_NAK
      7                       MARS_UNSERV
      8                       MARS_SJOIN
      9                       MARS_SLEAVE
     12                       MARS_REDIRECT_MAP

ok so MARSMSERV and MARS-UNSERV are identical in format to the MARSJOIN message 🌈 MARSSJOIN and MARS-SLEAVE are also identical in format to MARSJOIN. Because of that, their formats (and the formats of MARSREQUEST, MARS-MULTI, MARSNAK and MARSREDIRECT-MAP) are described in [GA96] 💅 Their usage is covered in section 4. All control messages are LLC/SNAP encapsulated, as described in section 4.2 of [GA96] 🦋 (The "mar$" notation used in this doc is borrowed from [GA96] and just points to a specific field in the control message 🧚) Data messages get reflected by the MCS without any modification 💖

3.2. Association with a layer 3 group 🎀

the simplest MCS architecture takes incoming AALSDUs from the multicast sources and sends them out over the point-to-multipoint VC to the group members 🌸 But the MCS can only service one layer 3 group with this design, because it has no way to tell apart traffic meant for different groups 💜 So each layer 3 MCS-supported group gets its own designated MCS 🫶

that said, it's desirable to save resources by using the same MCS for multiple groups ✨ You can do that by adding a little bit of layer 3 specific processing into the MCS 👑 Then the MCS can look inside the received AALSDUs and figure out which layer 3 group they're destined for 🔥 A single MCS instance can register its ATM address with the MARS for multiple layer 3 groups, and it manages multiple point-to-multipoint VCs, one per group 🦋 This capability is part of the MCS architecture, and so is the option of having multiple MCSs per group (section 5) 🌈

4. Working of MCS 💅

okay this is the big one 😭 An MCS MUST NOT share its ATM address with any other cluster member (MARS or otherwise) 🔥 However, it may share the same physical ATM interface (even with other MCSs or the MARS), as long as each logical entity has a different ATM address 🫶 This section describes how the MCS works and how it interacts with the MARS and the other cluster members 🌸

4.1. Usage of MARSMSERV and MARS-UNSERV 🧚

4.1.1. Registration (and deregistration) with the MARS 💖

the ATM address of the MARS MUST be known to the MCS by out-of-band means at startup 🎀 One possible approach is for the network administrator to specify the MARS address on the command line when starting the MCS 🦋 When it starts up, the MCS MUST open a point-to-point control VC (MARSVC) with the MARS. All traffic from the MCS to the MARS MUST be carried over the MARSVC 🌈 The MCS MUST register with the MARS using the MARS-MSERV message on startup. To register, a MARSMSERV MUST be sent by the MCS to the MARS over the MARSVC 💜 When the MARS receives this MARS-MSERV, it adds the MCS to the ServerControlVC 👑 The ServerControlVC is maintained by the MARS with all MCSs as leaves, and it's used to disseminate general control messages to all the MCSs ✨ The MCS MUST terminate this VC, and it MUST expect a copy of the MCS registration MARSMSERV on the MARS-VC from the MARS 🔥

an MCS can deregister by sending a MARSUNSERV to the MARS 🫶 A copy of this MARSUNSERV MUST be expected back from the MARS 🌸 After that, the MCS gets dropped from the ServerControlVC 🧚

no protocol specific group addresses are included in MCS registration MARSMSERV and MARS-UNSERV 💖 The mar$flags.register bit MUST be set, the mar$cmi field MUST be set to zero, the mar$flags.sequence field MUST be set to zero, and the source ATM address MUST be included. A null source protocol address MAY be specified in these MARSMSERV and MARS-UNSERV 🎀 Everything else is set as described in section 5.2.1 of [GA96] (you can think of the MCS as a cluster member while reading that section 🦋) The MCS MUST keep retransmitting (section 4.1.3) the MARSMSERV/MARS-UNSERV over the MARSVC until it gets a copy back 🌈

if there's a failure to open the MARSVC, or an error on it, follow the reconnection procedure outlined in section 4.5.2 💜

4.1.2. Registration (and deregistration) of layer 3 groups 👑

the MCS can register with the MARS to support particular group(s) 🔥 To register groups X through Y, a MARSMSERV with a <min, max> pair of <X, Y> MUST be sent to the MARS 💅 The MCS MUST expect a copy of the MARSMSERV back from the MARS. If no copy is received, follow the retransmission strategy outlined in section 4.1.3 🫶

the MCS MUST similarly use MARSUNSERV if it wants to withdraw support for a specific layer 3 group 🌸 A copy of the group MARSUNSERV MUST be received, and if it isn't, the retransmission strategy in section 4.1.3 is to be followed 🧚

last bit for this part: the mar$flags.register bit MUST be reset, and the mar$flags.sequence field MUST be set to zero, in the group MARSMSERV and MARS-UNSERV 💖 Everything else is set as described in section 5.2.1 of [GA96] (the MCS can be considered a cluster member while reading that section 🎀) ✨

4.1.3. Retransmission of MARSMSERV and MARS-UNSERV ✨

okay so transient problems can literally make control messages vanish 💀, which is why the MCS needs to retransmit MARSMSERV/MARS-UNSERV at regular intervals whenever it doesn't get a copy back from the MARS 🔁. The interval should be no shorter than 5 seconds, and 10 seconds is the recommended default 🎀. A maximum of 5 retransmissions are permitted before a failure gets logged 📝. This MUST be considered a MARS failure, which SHOULD kick off the MARS reconnection mechanism in section 4.5.2 🔌.

so what counts as a "copy"? 👀 It's a received message where these fields match the MARSMSERV/MARS-UNSERV that got sent before:

• mar$op
• mar$flags.register
• mar$pnum
• Source ATM address
• first <min, max> pair

and a valid copy MUST also have these field values:

• mar$flags.punched = 0
• mar$flags.copy = 1

if either of those isn't true, the message MUST be dropped without resetting the MARSMSERV/MARS-UNSERV timer 🙅‍♀️. And there MUST be only one MARSMSERV or MARS-UNSERV outstanding at a time, no double-booking allowed 💅.

4.1.4. Processing of MARSMSERV and MARS-UNSERV 🧚

heads up, the MARS sends copies of group MARSMSERV and MARS-UNSERV out on the ServerControlVC 📡, so MCSs other than the one that originated them get to see them too 👀. This section is all about how those other MCSs handle it.

If a MARSMSERV shows up for a layer 3 group the MCS doesn't support, it MUST be used to track the Server Sequence Number (section 4.5.1) and then silently dropped 🫥. Not your group, not your problem, but you still gotta keep count 🔢.

If a MARSMSERV shows up for a layer 3 group the MCS does support, the MCS learns that another MCS is supporting the same group 🤝. This possibility (multiple MCSs per group) is baked into this version of the MCS approach and is discussed in section 5 ✨.

4.2. Usage of MARSREQUEST and MARS-MULTI 📥

okay so as section 5.1 explains, the MCS finds out at startup whether it's an active or an inactive MCS 🫶. After successful registration with the MARS, an MCS that's been designated inactive for a particular group MUST NOT register to support that group with the MARS 🚫. It instead proceeds as in section 5.4. The active MCS for a group has some special processing too, which we describe over there 👑. The rest of section 4 walks through how a single active MCS works, and section 5 covers what the active MCS does when there are multiple MCSs 💖.

once the active MCS registers to support a layer 3 group, it uses MARSREQUEST and MARS-MULTI to grab group membership info from the MARS 📦. Those messages also show up during the revalidation phase (section 4.5) and when there's no outgoing VC for a received layer 3 packet (section 4.3) ✨.

when registering to support a particular layer 3 group, the MCS MUST send a MARSREQUEST to the MARS 📨. The mechanism for retrieving group membership, plus the format of MARSREQUEST and MARS-MULTI, is in section 5.1.1 and 5.1.2 of [GA96] respectively 📖. The MCS MUST use this mechanism for sending (and retransmitting) the MARSREQUEST and processing the returned MARSMULTI(/s) 🔁. The MARS-MULTI MUST be received correctly, and the MCS MUST use it to initialize its knowledge of group membership 🧠.

on a successful reception of a MARSMULTI, the MCS MUST attempt to open the outgoing point-to-multipoint VC using the mechanism described in section 5.1.3 of [GA96], if any group members exist 🌈. The MCS however MUST start transmitting data on this VC after it has opened it successfully with at least one of the group members as a leaf, and after it has attempted to add all the group members at least once 🎯.

4.3. Usage of outgoing point-to-multipoint VC 🦋

cluster members that are sources for MCS-supported layer 3 groups send (encapsulated) layer 3 packets to the designated MCSs 📬. An MCS that gets them from cluster members has to send them out over the specific point-to-multipoint VC for that layer 3 group 💌. That VC gets set up as described in the previous section. BUT it's possible that no group members exist right now, so no VC gets set up 😬. So an MCS may have no outgoing VC to forward received layer 3 packets on, in which case it MUST initiate the MARSREQUEST and MARS-MULTI sequence described in the previous section 🔄. This new MARSMULTI could contain new members whose MARSSJOIN the MCS never received (and the loss might not be detected, since there's no traffic on the ServerControlVC) 👻.

if an MCS learns there are no group members (a MARSNAK received from the MARS), it MUST delay sending out a new MARSREQUEST for that group for a period no less than 5 seconds and no more than 10 seconds ⏳.

layer 3 packets received from cluster members while no outgoing point-to-multipoint VC exists for that group MUST be silently dropped after following the guidelines in the previous paragraphs 🫠. This might result in some layer 3 packets being lost until the VC is set up.

each outgoing point-to-multipoint VC has a revalidate flag associated with it 🚩. This flag MUST be checked whenever a layer 3 packet is sent out on that VC. No action is taken if it is not set. If it is set, the packet is sent out, the revalidation procedure (section 4.5.3) MUST be initiated for this group, and the flag MUST be reset 🔁.

in case of an error on a point-to-multipoint VC, the MCS MUST initiate revalidation procedures for that VC as described in section 4.5.3 🚨. Once a point-to-multipoint VC has been set up for a particular layer 3 group, the MCS MUST hold the VC open and mark it as the outgoing path for any subsequent layer 3 packets sent for that group address 🔒. A point-to-multipoint VC MUST NOT have an activity timer associated with it ⏱️🚫. It stays up at all times, unless the MCS explicitly stops supporting that layer 3 group, or no more leaves exist on the VC, which causes it to shut down 🌙.

the VC is kept up despite no traffic to reduce the delay suffered by MCS-supported groups 🐢. If the VC got shut down on absence of traffic, the VC reestablishment procedure (needed when new traffic for the group shows up) would make the initial delay even longer 😩. That could be potentially higher than the VC mesh approach anyway, since the MCS case needs two VCs (source to MCS, then MCS to group) while the VC mesh approach needs just one (source to group) 🕸️. This approach of keeping the VC from the MCS open even with no traffic is experimental 🧪. A decision either way can only be made after gaining experience (through implementation or simulation) about the implications of keeping the VC open 📊.

if the MCS supports multiple layer 3 groups, it MUST follow the procedure outlined in the four previous subsections for each group that it is an active MCS for 👯. Each incoming data AALSDU MUST be examined to determine its recipient group before it gets forwarded onto the appropriate outgoing point-to-multipoint VC 🎁.

4.3.1. Group member dropping off a point-to-multipoint VC 👋

an ERRL-DROP might show up during the life of a point-to-multipoint VC 📉, meaning a leaf node has ended its participation at the ATM level. The ATM endpoint tied to that ERRL-DROP MUST be removed from the locally held set for the VC 🗑️. The revalidate flag on the VC MUST be set after a random interval of 1 through 10 seconds ⏲️.

if an ERRL-RELEASE is received for a VC, the whole set gets cleared and the VC is considered completely shut down 💀. A new VC for this layer 3 group only gets established when new traffic for the group arrives (as described in section 4.3) 🌸.

4.4. Processing of MARSSJOIN and MARS-SLEAVE 💌

the MARS sends out equivalent MARSSJOIN/MARS-SLEAVE on the ServerControlVC whenever it gets MARSJOIN/MARS-LEAVE from cluster members 📣. The MCSs keep track of group membership updates through these messages 👀. The format of these messages is identical to MARSJOIN and MARS-LEAVE, which are described in section 5.2.1 of [GA96] 📜. For now, just know they carry the ATM address of the node joining/leaving the group(/s), the group(/s) being joined or left, and a Server Sequence Number from the MARS 🔢.

when a MARSSJOIN refers to (or encompasses) a layer 3 group (or groups) supported by the MCS, the following action MUST be taken:

• The new member's ATM address is extracted from the MARSSJOIN.
• An L-MULTIADD is issued for the new member for each of those referred groups which have an outgoing point-to-multipoint VC.
• An LMULTI-RQ is issued for the new member for each of those referred groups which have no outgoing VCs.

🧾✨

when a MARSSLEAVE refers to (or encompasses) a layer 3 group (or groups) supported by the MCS, the following action MUST be taken. The leaving member's ATM address is extracted. An LMULTI-DROP is issued for the member for each of the referred groups which have an outgoing point-to-multipoint VC 👋.

there's a possibility of the above requests (LMULTI-RQ or LMULTIADD or LMULTI-DROP) failing 😬. The UNI 3.0/3.1 failure cause must be returned in the ERRL-RQFAILED signal from the local signaling entity to the AAL User. If the failure cause is not 49 (Quality of Service unavailable), 51 (user cell rate not available - UNI 3.0), 37 (user cell rate not available - UNI 3.1), or 41 (Temporary failure), the endpoint's ATM address is dropped from the locally held view of the group by the MCS. Otherwise, the request MUST be re-attempted with increasing delay (initial value between 5 to 10 seconds, with delay value doubling after each attempt) until it either succeeds or the multipoint VC is released or a MARSSLEAVE is received for that group member. If the VC is open, traffic on the VC MUST continue during these attempts 🔁.

MARSSJOIN and MARS-SLEAVE are processed differently if multiple MCSs share the members of the same layer 3 group (section 5.4). MARSSJOIN and MARSSLEAVE that do not refer to (or encompass) supported groups MUST be used to track the Server Sequence Number (section 4.5.1), but are otherwise ignored 🫧.

4.5. Revalidation Procedures 🔄

the MCS has to initiate revalidation procedures in case of certain failures or errors 🚨.

4.5.1 Server Sequence Number

Okay so the MCS has to keep track of the Server Sequence Number (SSN) in everything it gets on the ServerControlVC from the MARS. ✨ The MARS puts it in the mar$msn field of every message it sends to MCSs, except MARSNAK. 💅 If the SSN suddenly jumps, that means the MCS missed the message(s) in between, which is literally the worst. 😭 So the MCS sets the revalidate flag on all its outgoing point-to-multipoint VCs, but only after a random delay of between 1 and 10 seconds. The randomness is the iconic part 🦋: it stops every MCS from flooding the MARS at the same moment when something bigger has gone wrong.

There's one exception. If a sequence number jump shows up while a new group's VC is being set up (so a MARSMULTI arrived fine, but its mar$msn shows that some earlier MARS traffic on ClusterControlVC got lost), then every open VC, EXCEPT the one being set up, MUST have its revalidate flag set at a random interval between 1 and 10 seconds from when the jump was spotted. 🎀 The VC being set up counts as already validated in this situation, so it doesn't get the flag.

Each MCS keeps its own 32 bit MCS Sequence Number (MSN) to track the SSN. 🌸 Every time a message with a mar$msn field comes in, the MCS does this:

Seq.diff = mar$msn - MSN

mar$msn -> MSN

(.... process MARS message ....)

if ((Seq.diff != 1) && (Seq.diff != 0))
      then (.... revalidate group membership information ....)

Also, the mar$msn in a single MARSMULTI doesn't update the MSN until every part of that MARSMULTI (if there's more than one) has arrived. 🧚 If the mar$msn changes partway through a MARSMULTI series, the MARS-MULTI gets thrown out, as described in section 5.1.1 of [GA96]. The MCS sets its MSN to zero on startup, and it picks up the current SSN once the copy of the registration MARSMSERV comes back from the MARS. 💜

4.5.2 Reconnecting to the MARS

Every MCS is set up with the ATM address of at least one MARS at startup. 🍓 An MCS MAY also keep a table of ATM addresses, where each one is an alternative MARS to try if the current one fails. That table is ordered from most to least preferred.

An MCS decides it's having trouble talking to a MARS if any of these happen:

• It fails to establish a point-to-point VC with the MARS.
• MARSREQUEST gets no response (no MARSMULTI or MARS-NAK comes back).
• ServerControlVC fails.
• MARSMSERV or MARSUNSERV don't result in their respective copies being received.

Reconnecting works like section 5.4 in [GA96], with MCS-specific actions added in where they're needed. 🔥

4.5.3 Revalidating a point-to-multipoint VC

The revalidation flag on a point-to-multipoint VC gets checked whenever a layer 3 packet is about to go out on that VC. 👑 Revalidation MUST be started for any point-to-multipoint VC with its revalidate flag set when a layer 3 packet is being sent on it. That means busier groups get revalidated faster than quiet ones, which is very fair. ✨ The revalidation MUST NOT disrupt normal traffic on the VC being revalidated.

Here's how it goes. The MCS sends a fresh MARSREQUEST for the VC being revalidated. It compares the returned set of members with the set it already has locally. New members get LMULTI-ADDs, which MUST be issued, and members that no longer exist get LMULTI-DROPs, which MUST be issued. Then the revalidate flag MUST be reset for the VC. 🫶

---

5 Multiple MCSs for a layer 3 group

Having just one MCS for a layer 3 group is risky 💀, because it becomes a single point of failure and a bottleneck for groups with lots of active senders. So having multiple MCSs per group is the goal, for fault tolerance. Load sharing is NOT part of this document, though, since it would make the protocol way more complicated. 🙈

5.1 Outline

This protocol gets fault tolerance by running multiple MCSs for the same group. 🦋 A standby MCS takes over when the MCS that was supporting the group fails. The MCS currently supporting a group is called the active MCS, and the one or more standbys are called inactive MCSs. At any given instant there is only one active MCS for each MCS-supported group. The protocol uses HELLO messages, as described in [LA96].

To keep things simple, a few operational guidelines need to be followed. These get enforced through out-of-band means that aren't specified in this document and can be left to the implementation. 💅

• The set of one or more MCSs (called "mcslist") that support a particular IP Multicast group is decided ahead of time and never changes. This set MUST be known to each MCS in the set at startup, and every MCS in the set has to use the same ordering. One way to do this is to keep the set of ATM addresses of the MCSs in a file, with an identical copy on each MCS in the set. 📁
• All MCSs in "mcslist" have to start up together, and the first MCS in "mcslist" has to be the last one to start. 🌈
• A failed MCS cannot be started up again. 💀

5.2 Discussion of Multiple MCSs in operation

When an MCS starts, it works out where it sits in "mcslist". ✨ If it isn't first in the list, it does NOT register to support the group with the MARS. If it is first in the set, it DOES register to support the group.

So the first MCS becomes the active MCS and supports the group the way section 4 describes. 👑 The active MCS also opens a point-to-multipoint VC (HelloVC) to the other MCSs in the set (the inactive MCSs), and starts sending HELLO messages on it every fixed interval (HelloInterval seconds). Each inactive MCS keeps a timer to track when it last got a HELLO message. If an inactive MCS doesn't get one within HelloInterval* DeadFactor seconds (HelloInterval and DeadFactor have the same values at every MCS), or if the HelloVC gets closed, it decides the active MCS has failed and tries to elect a new one. 😭 The election process is covered in section 5.5.

If an MCS gets elected as the new active one, it registers to support the group with the MARS, and it starts sending HELLO messages to the remaining inactive MCSs. 🧚

5.3 Inter-MCS control messages

HELLO messages do two jobs: the heartbeat mechanism and the election process. 🫶 The format is based on the one described in [LA96]. The Hello message type code is 5.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Len    |    Recvr Len  | State | Type  |    unused     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         HelloInterval         |          DeadFactor           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        IP Multicast address                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sender ATM address (variable length)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Receiver ATM address (variable length)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sender Len This field holds the length, in octets, of the Sender ATM address. 📏

Recvr Len This field holds the length, in octets, of the Receiver ATM address. 📏

State There are currently two states: No-Op (0x00) and Elected (0x01). A candidate MCS uses this field to say whether it was successfully elected. 🗳️

Type This is the code for the message type. 🏷️

HelloInterval This advertises the time between consecutive Hello Messages sent by an active MCS. If the time between Hello messages goes past the HelloInterval, the inactive MCS considers the Hello to be late. ⏰

DeadFactor This is a multiplier for the HelloInterval. If an inactive MCS doesn't get a Hello message within HelloInterval*DeadFactor from an active MCS that advertised the HelloInterval, the inactive MCS MUST consider that active MCS to have failed. ☠️

IP Multicast address This tells you which group the HELLO message is for. It's useful when MCSs can support more than one group. 🎯

Sender ATM address This is the protocol address of the server sending the Hello. 📮

Receiver ATM address This is the protocol address of the server that's supposed to Reply to the Hello. If the sender doesn't know this address, it sets the field to zero. (This happens in the HELLO messages the active MCS sends to the inactive ones, since they're multicast and not sent to one specific receiver.) 🌟

5.4 The Multiple MCS protocol ✨

okay so, as we said in 5.1, every MCS supporting the same IP Multicast group MUST be started up together 🫶 The set of MCSs (mcslist) MUST be handed to each MCS in the set at startup. Once the group is registered with the MARS, the first MCS in the set MUST open a point-to-multipoint VC (HelloVC) with the rest of the mcslist as leaves, and that's how it becomes the active MCS 👑 It MUST send HELLO messages every HelloInterval seconds on this VC. The HELLO message from the active MCS MUST have Receiver Len set to zero and State set to "Elected", with the other fields filled in properly. The Receiver ATM address field doesn't exist in this HELLO message 🙈 The starting values of HelloInterval and DeadFactor MUST be the same at every MCS at startup. The active MCS can change them by putting new values in the HELLO messages it sends. The active MCS MUST support the group as described in Section 4, no exceptions bestie 💅

The other MCSs in mcslist work out who the first MCS is from the list. They MUST NOT register to support the group with the MARS, and they become inactive MCSs 🌸 When an inactive MCS starts up, it waits for HELLO messages from the active MCS. The inactive MCS MUST terminate the HelloVC. It MUST keep a timer running ⏱️ If that timer goes past HelloInterval*DeadFactor seconds without a HELLO from the active MCS, it figures the active MCS died and starts the election described in 5.5 💀 If a HELLO does show up in time, the inactive MCS doesn't do anything else except restart the timer. The inactive MCSs MUST set their HelloInterval and DeadFactor values to whatever the active MCS puts in its HELLO messages 🎀

Now for an MCS supporting multiple groups. It MUST register for the groups where it's the first MCS, and it MUST NOT register for any others 🧚 A MARSMSERV with several <min, max> pairs can be used to register multiple disjoint sets of groups. Support MUST be provided for using one mcslist across more than one group. This is for the case where one MCS is meant to support several groups while other MCSs act as backups 🔥 It also means you don't need a separate mcslist for every group the same set of MCSs supports, which is honestly so much less work.

If the active MCS fails, a new MCS takes over the role as described in 5.5. The remaining inactive MCSs then wait for HELLO messages from this new active MCS, same as the previous paragraph explained 🦋

5.5 Failure handling 💔

5.5.1 Failure of active MCS

okay, so the inactive MCSs catch the active MCS dying when no HELLO shows up within HelloInterval*DeadFactor seconds, or when the HelloVC gets closed 😭 Then the next MCS in mcslist becomes the candidate MCS. It MUST open a point-to-multipoint VC to the remaining inactive MCSs (HelloVC) and send a HELLO on it with State set to No-Op. The rest of the message is formatted the way we covered earlier 🫶

When an inactive MCS gets a HELLO from a candidate MCS, it MUST open a point-to-point VC to that candidate. It MUST send a HELLO message back, with the Sender and Receiver fields set properly (not zero) and State set to No-Op ✨ If an inactive MCS gets a HELLO from a non-candidate MCS, it just ignores it. If the inactive MCS doesn't hear a HELLO from the candidate with State set to "Elected" within HelloInterval seconds, it MUST retransmit the HELLO 🔁 If no HELLO with State set to "Elected" reaches the inactive MCSs within HelloInterval*DeadFactor seconds, the next MCS in mcslist is treated as the candidate MCS. Heads up: the election phase uses the default values of HelloInterval and DeadFactor 🍓

The candidate MCS MUST wait HelloInterval*DeadFactor seconds to receive HELLO messages from the inactive MCSs. During that window it MUST transmit HELLO messages with State set to No-Op every HelloInterval seconds 💜 If it hears from at least half of the remaining inactive MCSs in that time, it decides it's elected and takes on the active MCS role 👑 Then it registers the group with the MARS and starts sending HELLO messages every HelloInterval seconds with State set to "Elected" on the HelloVC that already exists. The new active MCS can change the HelloInterval and DeadFactor values if it wants, and tell the inactive MCSs about it in the HELLO message 🌈

5.5.2 Failure of inactive MCS

if an inactive MCS drops off the HelloVC, the active MCS MUST try to add that MCS back to the VC three times, with HelloInterval*DeadFactor seconds between attempts 🔄 If even the third try fails, the inactive MCS is considered dead 🥀

An MCS, active or inactive, MUST NOT be started up once it has failed. Failed MCSs can only come back through manual intervention, and only after you shut down all the MCSs and restart them together 🛑

5.6 Compatibility with future MARS and MCS versions

future versions of MCSs are expected to use an enhanced MARS for load sharing and fault tolerance ([TA96]) 🔮 The MCS architecture in this document is compatible with the enhanced MARS and with future MCS versions. Why? Because the active MCS is the only one that talks to the MARS about the group. So the active MCS only hears from the enhanced MARS about the subset of the group it's supposed to support 💅 That means MCSs following this document work with a [GA96] based MARS, and with an enhanced MARS too ✨

6 Summary 📝

this document describes the architecture of an MCS. It also gives a mechanism for running multiple MCSs per group for fault tolerance 🫶 This approach works with [GA96] based MARS servers and clients, with no changes needed to their functionality. It uses the HELLO packet format from [LA96] for the heartbeat messages 💖

7 Acknowledgements 🎀

we want to shout out Grenville Armitage (Bellcore) for reviewing the document and suggesting ways to simplify the multiple MCS functionality 🙌 Joel Halpern (Newbridge) helped clarify the multiple MCS problem 🧠 Anthony Gallo (IBM RTP) pointed out security issues that this document doesn't adequately address. Arvind Murching (Microsoft) flagged a potential show stopper in section 4.1.2 😱

8 Authors' Address 🖋️

Rajesh Talpade
College of Computing
Georgia Institute of Technology
Atlanta, GA 30332-0280

Phone: (404)-894-6737
Email: taddy@cc.gatech.edu
Mostafa H. Ammar
College of Computing
Georgia Institute of Technology
Atlanta, GA 30332-0280

Phone: (404)-894-3292
Email:  ammar@cc.gatech.edu

9 References 📚

• [GA96] Armitage, G.J., "Support for Multicast over UNI 3.0/3.1 based ATM networks", RFC 2022, November 1996.
• [BK95] Birman, A., Kandlur, D., Rubas, J., "An extension to the MARS model", Work in Progress.
• [LM93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-Packard Laboratories, December 1993.
• [LA96] Luciani, J., G. Armitage, and J. Halpern, "Server Cache Synchronization Protocol (SCSP) - NBMA", Work in Progress.
• [TA96] Talpade, R., and Ammar, M.H., "Multiple MCS support using an enhanced version of the MARS server.", Work in Progress.