RFC 2443

A Distributed MARS Service Using SCSP

📅 published November 1998, from ietf

RFC 2443: A Distributed MARS Service Using SCSP 💖

Okay bestie, here's the header tea 🫖 RFC 2443 is called A Distributed MARS Service Using SCSP. The authors are J. Luciani from Bay Networks and A. Gallo from IBM, and it's dated November 1998. The category is Experimental 🧪. The header doesn't list anything it obsoletes or updates, so it's not replacing or touching any other RFC 🙈

Status of this Memo ✨

This doc says it specifies an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 🗣️ For the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Copyright Notice 🎀

Abstract 🦋

This doc describes a way to distribute a MARS service inside a LIS[1] 🌸 It uses the Server Cache Synchronization Protocol (SCSP)[2] to sync up the MARS Server databases inside a LIS. When SCSP is used to sync the caches of MARS Servers in a LIS, the LIS is what defines the boundary of an SCSP Server Group (SG) 👑

1. Introduction 🧚

Okay so the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they show up in this doc, are to be read as described in [5] 🫶

The MARS is an extended analog of the ATMARP Server introduced in [4] 💜 It gives you the connection and addressing services that layer 3 multicast services need over ATM 🔥 There are three basic pieces to the MARS model. First, the MARS Server, which manages layer 3 group membership info and hands it out to the LIS. Second, MARS Clients, which register with one MARS Server and query it for layer 3 multicast info. Third, MCS Clients, which register with one MARS Server and provide layer 3 multicast forwarding for a LIS ✨

Both MARS Clients and MCS Clients explicitly register with the MARS Server before they swap any layer 3 multicast info 💅 During registration, MARS Clients get placed on the Cluster Control VC (CCVC) and MCS Clients get placed on the Server Control VC (SCVC) 🦋 Both the CCVC and the SCVC are then used to push layer 3 multicast updates out to the clients in a LIS. Also during registration, every MARS Client gets a unique Cluster Member ID (CMI). That's what lets them tell reflected packets apart when MCS Clients are around 🌈

In the Distributed MARS Model there MAY be multiple MARS Servers in a given LIS. Any MARS Server in the LIS MUST be able to provide layer 3 multicast info about any multicast group in that LIS, so there MUST be a method for syncing multicast info across all the MARS Servers in the LIS 🔥

SCSP solves the general server synchronization and cache-replication problem for distributed databases, so SCSP MAY be applied to the MARS Server database sync problem inside a LIS 🎀 When SCSP is used to sync the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG) 💖

SCSP is split into two parts: the protocol independent part and the client/server protocol specific part 🍓 The protocol independent part is specified in [2], and this document specifies the client/server protocol specific part, where the MARS Server is the client/server protocol 🧁

2. Overview 🌟

All MARS Servers in a LIS are said to belong to a Server Group (SG) 👯‍♀️ An SG is identified by its SGID, which lives in a field inside every SCSP packet (no surprise there 🙄). Every SCSP packet also has a Protocol ID (PID) field. This PID field is set to 0x0003 to show that SCSP is syncing MARS Server databases and not some other protocol's databases (see Section B.2.0.1 of [2] for more details) 🔍 In general, PIDs for SCSP get assigned by IANA on request, as long as a client/server protocol specific specification has been written. For MARS Servers, that spec was written at the same time as SCSP, so PID=0x0003 got assigned in [2] ✨

SCSP puts no topological requirements on a MARS Server SG 💅 Obviously, though, the resulting graph of MARS Servers has to span the set of MARS Servers being synced. If you want more on the client/server protocol independent part of SCSP, you're encouraged to check out [2] 📚

When an SG is using SCSP for sync, a MARS Client or MCS Client registers with only one MARS Server, but it's allowed to pick any MARS Server in the SG for that registration 🦋 At registration time, the MARS Client or MCS Client gets added to that MARS Server's respective CCVC or SCVC. MARS Clients also get issued a unique CMI for the whole LIS. This document assumes that, at a minimum, each MARS Server in the SG is configured with its own unique range of CMIs to hand out to the clients that register with it. Using some external means to allocate CMIs to MARS Servers in an SG is possible, but it's beyond the scope of this document 🌸

When a MARS Client or MCS Client successfully registers with a MARS Server in the SG, that MARS Server propagates the registration info to its peer MARS Servers. The same propagation happens for any later group membership info it learns from the clients. The peer MARS Server then updates its group membership database and, if needed, propagates the info out its own CCVC or SCVC 🔥

If a MARS Server fails, all peer MARS Servers in the SG MUST flush the client/group membership info they learned from the failed MARS Server 💀 The clients that were on the failed MARS Server's CCVC and SCVC migrate to the next available MARS Server, as specified in Section 5.3 of [1] 🏃‍♀️ When a client detects that its MARS has failed, it steps to the next backup MARS Server and tries to register with that server. If registration succeeds, the client re-joins all of its previous group memberships. If registration fails, the process keeps repeating until it finds a working MARS Server 🧚

Figuring out the operational state of MARS Servers in an SG means each MARS Server has to send out an "alive" or "heartbeat" message 💓 It's similar to the MARS Redirect message sent out on the CCVC or SCVC for MARS Clients. The difference is that this message only goes to MARS Servers in the SG, and from here on it's called the MARS Server Redirect Entry 🦋

To detect that a MARS Server failure has happened, each server MUST update its MARS Server Redirect Entry state at least every 2 minutes, and it is RECOMMENDED that it's updated every 1 minute ⏱️ If a receiver misses two consecutive MARS Server Redirect Entry updates from a given MARS Server in the SG, all the membership info learned from that server gets flushed 🫠 The MARS Server Redirect Entry state is also used to build the MARS_REDIRECT_MAP messages sent out on the CCVC for each MARS Server in the SG 🗺️ The ordering of the servers in the list is based on the MARS Servers' SCSP Sender ID. The MARS_REDIRECT_MAP lists the MARS Servers learned from MARS Server Redirect Entry updates first, in ascending order by SCSP Sender ID, and then any externally configured or learned backup MARS Servers come after them 💜

If a MARS Client or MCS Client fails and gets unexpectedly removed from the CCVC or SCVC, the MARS Server MUST notify its peer SG members with a proxy deregister for that client 🚨 When a peer SG member gets a proxy deregister request, all membership info for the deregistering client MUST be removed 🧹 Any clients sending multicast data to the failed client should also notice that this client was unexpectedly removed, which in turn makes the sending client revalidate the multicast group's current membership, as outlined in Section 5.1.5.1 of [1] 🫶

3. Format of the CSA Record MARS Specific Part ✨

okay so bestie, CSA Records in SCSP carry a "Client/Server Protocol Specific Part" 💅 that holds the stuff that is NOT protocol independent for a given server's cache entry 🦋. here's the layout:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Hardware Type          |        Protocol Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SNAP                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SNAP      |   Unused      |    Version    |   State       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Flags              |       Cluster Member ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source Protocol Address             (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM Address                  (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM SubAddress               (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Minimum Multicast Group Address     (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Maximum Multicast Group Address     (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hardware Type

This tells you the type of "link layer" addresses being carried 🌸. The value is the ATM Forum 'address family number' specified in [3], which is 15 decimal (0x000F). It's the mar$afn field defined in [1].

Protocol Type

This is the protocol type number for the protocol using MARS from [3] 🧚. IPv4 is 0x0800. It's the mar$pro.type field from [1].

Protocol SNAP

This is the optional protocol SNAP extension to the protocol type. It's the mar$pro.snap field from [1] ✨.

Version Number

here's the version breakdown, bestie 🎀:

0                    MARS Specific part of the CSA record.
0x01                 Reserved for NHRP.
0x02 - 0xEF          Reserved for future use by the IETF.
0xF0 - 0xFE          Allocated for use by the ATM Forum.
0xFF                 Experimental/Local use.

Version Number for this document MUST be set to 0x00 💖.

State

the State values are:

1 MARS Server Redirect Entry.
2 MCS Serve/Register request.
3 MARS Client Join/Register request.
4 MARS Client Leave/Deregister request.
5 MCS Unserve/Deregister request.

Any other State value should cause the CSA to be discarded 🙈.

Flags

the Flags field holds several flags and is similar to the mar$flags field from [1] 🦋:

mar$flags
   Bit 15   - mar$flags.layer3grp
   Bit 13   - mar$flags.register
   Bit 0-7  - mar$flags.sequence

All remaining bits are reserved and MUST be zero. The mars$flags.sequence field only has local significance to the Local Server (LS) 🫶.

Cluster Member CMI

This field holds the CMI, which uniquely identifies each endpoint within a LIS. It's the mar$cmi field from [1] 💜.

Src Addr Len

This field holds the length of the Source Protocol Address field. For IPv4, the value is 4 if an address is specified. A null (non-existent) address MUST be coded as zero length, and no space gets allocated for it in the message body. It's the mar$spln field from [1] 🍓.

Group Addr Len

This field holds the length of the Group Protocol Address field. For IPv4, the value is 4 if an address is specified. A null (non-existent) address MUST be coded as zero length, and no space gets allocated for it in the message body. It's the mar$tpln field from [1] 🌈.

ATM Addr T/L

This field holds the type and length of the Source ATM Address field. The type and length encoding is described in Section 5.1.2 of [1] 🎀.

ATM SubAddr T/L

This field holds the type and length of the Source ATM SubAddress field. The type and length encoding is described in Section 5.1.2 of [1] 💅.

Source Protocol Address

This is the internetwork address for the source of an address binding in a MARS server cache entry. If it's null, no storage will be allocated. It's the mar$spa field from [1] ✨.

Source ATM Address

This is the Source's ATM address for an address binding in a MARS server cache entry. If it's specified, the address is E.164 or an ATM Forum NSAPA. It's the mar$sha field from [1] 🦋.

Source ATM SubAddress

This is the Source's ATM subaddress for an address binding in a MARS server cache entry. If it's specified, the subaddress is an ATM Forum NSAPA. If it's null, no storage will be allocated. It's the mar$ssa field from [1] 🌸.

Minimum Multicast Group Address

This is the internetwork address of the lower bound on the range of multicast group addresses for the address binding in a MARS server cache entry. If it's null, no storage will be allocated. It's the mar$min.N field from [1] 🧚.

Maximum Multicast Group Address

This is the internetwork address of the upper bound on the range of multicast group addresses for the address binding in a MARS server cache entry. If it's null, no storage will be allocated. It's the mar$max.N field from [1] 👑.

4. Values for SCSP Protocol Independent Part ✨

okay now we get to the protocol independent side 🫶. the next sections give values for fields of the SCSP Protocol Independent Part of the various SCSP messages 💖.

4.1 Values for the SCSP "Mandatory Common Part"

Protocol ID = 0x0003
Sender ID Len = 0x04
Recvr ID Len = 0x04

See Section B.2.0.1 of [2] for a detailed description of these fields 🌈.

4.2 Values for the SCSP "CSAS Record"

Cache Key Len = 0x04
Orig ID Len = 0x04

See Section B.2.0.2 of [2] for a detailed description of these fields 🦋.

5. Detailed State Descriptions ✨

5.1 MARS Server Redirect Entry.

okay this one is the big deal 👑. The MARS Server Redirect Entry is how you figure out the operational state of a MARS Server in the SG 🔥. Each server MUST update its MARS Server Redirect Entry state at least every 2 minutes, and it is RECOMMENDED that it gets updated every 1 minute 💅.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Hardware Type          |        Protocol Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SNAP                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SNAP      |   Unused      |    Version    |   State       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Flags              |       Cluster Member ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM Address                  (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM SubAddress               (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hardware Type

This value is the ATM Forum 'address family number' specified in [3], which is 15 decimal (0x000F) 🌸.

Protocol Type

This is the protocol type number for the protocol using MARS from [3]. IPv4 is 0x0800 🧚.

Protocol SNAP

This is the optional protocol SNAP extension to the protocol type. It's the mar$pro.snap field from [1] ✨.

Version Number

Version Number for this document MUST be set to 0x00 💖.

State

The State value is coded as 1 decimal for a MARS Server Redirect Entry 🦋.

The Flags, Cluster Member ID, Src Addr Len, and Group Addr Len fields are unused and set to zero 🙈.

The ATM Addr T/L, ATM SubAddr T/L, Source ATM Address, and Source ATM SubAddress fields define the ATM address for the source of the MARS Server Redirect Entry in the SG 🫶. The coding for these fields is the same as described in Section 3 of this document 🎀.

Failure to receive two consecutive MARS Server Redirect Entry updates from a given MARS Server in the SG will cause all membership information learned from that server to be flushed 💀. When a valid MARS Server Redirect Entry update is received, the source of that update gets placed into the table of backup MARS Servers sent in the MARS_REDIRECT_MAP message 👑.

the ordering matters here bestie 🔥. The MARS_REDIRECT_MAP lists the MARS Servers learned via MARS Server Redirect Entry updates first, in ascending order based on the SCSP Sender ID. After those come any externally configured or learned backup MARS Servers 🌈.

The format of the MARS_REDIRECT_MAP can be found in Section 5.4.3 of [1] 💜.

5.2. MCS Serve/Register request ✨

okay bestie, so the MCS Serve/Register request is how an MCS Client's registering or servicing of specific groups gets passed around the SG domain 📣 it's basically a cousin of the MARS_MSERV request from Sections 6.2.2 and 6.2.3 of [1] 💅. when a MARS Server in the SG successfully adds a new MCS Client to its SCVC, or adds MCS support for a specific group, it MUST send a MCS Serve/Register request to the SG 🫶. also, an MCS Client can only register with one MARS Server in the SG, periodt 💜

Here's the layout, so you can see how it's all packed together 🎀

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Hardware Type          |        Protocol Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SNAP                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SNAP      |   Unused      |    Version    |   State       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Flags              |       Cluster Member ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source Protocol Address             (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM Address                  (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM SubAddress               (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Minimum Multicast Group Address     (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Maximum Multicast Group Address     (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hardware Type 🌸 this is the ATM Forum 'address family number' from [3], which is 15 decimal (0x000F).

Protocol Type 🧚 this is the protocol type number for the protocol using MARS from [3]. (IPv4 is 0x0800, obviously 💖)

Protocol SNAP ✨ this one's optional. It's the protocol SNAP extension to the protocol type, and it's the mar$pro.snap field from [1].

Version Number 🦋 the Version Number for this document MUST be set to 0x00.

State 🍓 the State value is coded as 2 decimal for an MCS Serve/Register request.

Flags 🔥 the flags field holds several flags, and they look like this:

   mar$flags
      Bit 15   - mar$flags.layer3grp
      Bit 13   - mar$flags.register
      Bit 0-7  - mar$flags.sequence

The mar$flags.register bit MUST be set the same as in the originating MARS_MSERV request. The mar$flags.layer3grp bit MUST be zero, and the mar$flags.sequence bits are of local significance only to the LS. ngl this is giving very precise energy 💅

Cluster Member CMI 🌈 this field holds the CMI assigned by the MARS Server that processed the MARS_MSERV request. It uniquely identifies the MCS Client in the MARS server cache 🫶

Src Addr Len 🎀 this is the length of the Source Protocol Address field. For IPv4, the value is 4 if an address is specified. A null (non-existent) address MUST be coded as zero length, and no space gets allocated for it in the message body 🙈

Group Addr Len 🦋 this is the length of the Group Protocol Address field. If the register bit in the flags field is set to 1 in the request, this field MUST be zero. If the register bit is zero in the flags field, the value of this field for IPv4 is 4 ✨

ATM Addr T/L 💜 this field has the type and length of the Source ATM Address field for the MCS Client that originated the MARS_MSERV request. The type and length encoding is described in Section 3.

ATM SubAddr T/L 🧚 same vibe as ATM Addr T/L, but for the Source ATM SubAddress field of the MCS Client that originated the MARS_MSERV request. The type and length encoding is described in Section 3.

Source Protocol Address 🌸 this is the internetwork address for the source of an address binding in a MARS server cache entry. If Src Addr Len is set to zero, no storage will be allocated.

Source ATM Address 💅 this is the MCS Client's ATM address of an address binding in a MARS server cache entry. The address is E.164 or ATM Forum NSAPA.

Source ATM SubAddress 🍓 this is the MCS Client's ATM subaddress of an address binding in a MARS server cache entry. The subaddress, if specified, is an ATM Forum NSAPA. If null, no storage will be allocated.

Minimum Multicast Group Address 🌈 this is the internetwork address of the lower bound on the range of multicast group addresses for the address binding in a MARS server cache entry. If Group Addr Len is set to zero, no storage will be allocated.

Maximum Multicast Group Address 👑 this is the internetwork address of the upper bound on the range of multicast group addresses for the address binding in a MARS server cache entry. If Group Addr Len is set to zero, no storage will be allocated.

okay so the big takeaway 🚨 an MCS Client can only register with one MARS Server in the SG, and it's only placed on the SCVC for the MARS Server it's registered with. no sharing, no double dipping 💀

When an MCS Client Serve/Register request specifying a group address is received by a MARS Server, it MUST create a cache entry associated with this client. On top of adding the cache entry, it MUST send out a MARS_MIGRATE message on its CCVC 🦋. this is needed so that clients using a mesh topology can migrate to a server based topology 🫶. details about the MARS_MIGRATE message are in Section 5.1.6 of [1] 📖💖

5.3. MARS Client Join/Register request ✨

Okay bestie, the MARS Client Join/Register request is how a MARS Server tells the rest of the SG domain that MARS Clients are registering or joining specific group ranges 💅. It's basically a cousin of the MARS_JOIN request from Sections 5.2.1 to 5.2.3 of [1] 🦋. When a MARS Server in the SG successfully registers a new MARS Client, or a registered client joins a specific group address range, that MARS Server MUST send a MARS Client Join/Register request to the SG 🫶. A MARS Client can only register with one MARS Server in the SG, and it only gets placed on that server's CCVC 💜.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Hardware Type          |        Protocol Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SNAP                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SNAP      |   Unused      |    Version    |   State       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Flags              |       Cluster Member ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Src Addr Len  | Group Addr Len| ATM Addr T/L  |ATM SubAddr T/L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source Protocol Address             (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM Address                  (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source ATM SubAddress               (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Minimum Multicast Group Address     (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Maximum Multicast Group Address     (variable length)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the field rundown, bestie 🎀:

Hardware Type: This value is the ATM Forum 'address family number' specified in [3] as 15 decimal (0x000F).
Protocol Type: This field is the protocol type number for the protocol using MARS from [3]. (IPv4 is 0x0800).
Protocol SNAP: This field is the optional protocol SNAP extension to protocol type. This is the mar$pro.snap field from [1].
Version Number: Version Number for this document MUST be set to 0x00.
State: State value is coded as 3 decimal for a MARS Client Join/Register request.
Flags: The flags field is used to contain several flags:

mar$flags
   Bit 15   - mar$flags.layer3grp
   Bit 13   - mar$flags.register
   Bit 0-7  - mar$flags.sequence

The mars$flags.layer3grp and mar$flags.register bits MUST be set the same as in the originating MARS_JOIN request. The mar$flags.sequence bits are of local significance only to the LS.

Cluster Member CMI: This field contains the CMI assigned by the MARS Server which processed the MARS_JOIN request and uniquely identifies the MARS Client in the MARS server cache.
Src Addr Len: This field contains the length of the Source Protocol Address field. For IPv4, the value is 4 if an address is specified. A null (non-existent) address MUST be coded as zero length, and no space allocated for it in the message body.
Group Addr Len: This field contains the length of the Group Protocol Address field. If the register bit in the flags field is set to 1 in the request this field MUST be zero. If the register bit is zero in the flags field the value of this field for IPv4 is 4.
ATM Addr T/L: This field contains the type and length of the Source ATM Address field for the MARS Client that originated the MARS_JOIN request. The type and length encoding is described in Section 3.
ATM SubAddr T/L: This field contains the type and length of the Source ATM SubAddress field for the MARS Client that originated the MARS_JOIN request. The type and length encoding is described in Section 3.
Source Protocol Address: This is the internetwork address for the source of an address binding in a MARS server cache entry. If Src Addr Len is set to zero no storage will be allocated.
Source ATM Address: This is the MARS Client's ATM address of an address binding in a MARS server cache entry. The address is E.164 or ATM Forum NSAPA.
Source ATM SubAddress: This is the MARS Client's ATM subaddress of an address binding in a MARS server cache entry. The subaddress, if specified, is an ATM Forum NSAPA. If null, no storage will be allocated.
Minimum Multicast Group Address: This is the internetwork address of the lower bound on the range of multicast group addresses for the address binding in a MARS server cache entry. If Group Addr Len is set to zero no storage will be allocated.
Maximum Multicast Group Address: This is the internetwork address of the upper bound on the range of multicast group addresses for the address binding in a MARS server cache entry. If Group Addr Len is set to zero no storage will be allocated.

An MARS Client can only register with one MARS Server in the SG and is only placed on the CCVC for the MARS Server for which it is registered with. If the mar$flags.layer3grp is set to 1 than the Minimum and Maximum Multicast Group Addresses MUST be equal for IPv4 🌸.

When a MARS Client Join/Register request is sent with the mar$flags.register bit set to 1, all of the servers in the SG will create a cache entry for this client using the information in the request 🧚.

When a registered MARS Client issues a MARS_JOIN for a specific group address range, a MARS Client Join/Register request MUST be sent to the servers in the SG. The actions taken by each server in the SG depend on previous group membership actions and MCS supported groups.

Each MARS Server MUST perform the necessary redistribution and hole punching algorithms before propagating this request to the CCVC and SCVC on each server. The redistribution and hole punching algorithms used for propagating join requests to the CCVC are the same as defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating MARS_JOIN request is a duplicate of a previously joined range or contains no group address range, then a MARS Client Join/Register MUST NOT be sent to the SG 🙈.

The redistribution and hole punching algorithms used for propagating join requests as MARS_SJOIN request on a SCVC is the same as Section 6.2.4 except for the following. Only the MARS Servers which contain the registered MCS Clients for the target group ranges should propagate this information to their SCVCs 🍓.

5.4. MARS Client Leave/Deregister request 👋

The MARS Client Leave/Deregister request is the opposite vibe 🥀. It's used to propagate the deregistering or leaving of specific group ranges by registered MARS Clients within the SG domain. It's similar to the MARS_LEAVE request defined in Sections 5.2.1 to 5.2.3 of [1]. When a MARS Server in the SG successfully deregisters a registered MARS Client, or a registered client leaves a specific group address range it had joined, the MARS Server MUST send a MARS Client Leave/Deregister request to the SG. If a registered MARS Client is unexpectedly removed from the CCVC, the MARS Server MUST act as a proxy and send a MARS Client Leave/Deregister request to the SG 💀.

The format and meanings of the fields in a MARS Client Leave/Deregister request are the same as in Section 5.3, except the State is coded as 4 decimal for a MARS Client Leave/Deregister request.

When a MARS Client Leave/Deregister request is sent with the mar$flags.register bit set to 1, all of the servers in the SG receiving this update MUST purge all cache entries for this client 🧹.

When a registered MARS Client issues a MARS_LEAVE for a specific group address range, a MARS Client LEAVE/Deregister request MUST be sent to the servers in the SG. The actions taken by each server in the SG depend on previous group membership actions and MCS supported groups.

Each MARS Server MUST perform the necessary redistribution and hole punching algorithms before propagating this request to the CCVC and SCVC on each server. The redistribution and hole punching algorithms used for propagating leave requests to the CCVC are the same as defined in Sections 6.1.2 and 6.2.4 of [1]. If the originating MARS_LEAVE request does not correspond to a previously joined range or contains no group address range, then a MARS Client Leave/Deregister MUST NOT be sent to the SG 🥺.

The redistribution and hole punching algorithms used for propagating leave requests as MARS_SLEAVE requests on a SCVC is the same as Section 6.2.4 except for the following. Only the MARS Servers which contain the registered MCS Clients for the target group ranges should propagate this information to their SCVCs 💅.

5.5. MCS Unserve/Deregister request 🌈

The MCS Unserve/Deregister request is used to propagate the deregistering or unservicing of specific groups by a registered MCS Client within the SG domain. It's similar to a MARS_MUNSERV request defined in Section 6.2.2 and 6.2.3 of [1] 🎀. When a MARS Server in the SG successfully deregisters a registered MCS Client, or a registered MCS Client stops serving a specific group address range it had been serving, the MARS Server MUST send a MCS Unserve/Deregister request to the SG. If a registered MCS Client is unexpectedly removed from the SCVC, the MARS Server owning the SCVC MUST act as a proxy and send a MCS Unserve/Deregister request to the SG 🫣.

The format and meanings of the fields in a MCS Unserve/Deregister request are the same as in Section 5.2, except the State is coded as 5 decimal for a MCS Unserve/Deregister request.

When a MCS Client Unserve/Deregister request is sent with the mar$flags.register bit set to 1, all of the servers in the SG receiving this update MUST purge all cache entries for this client.

When a registered MCS Client issues a MARS_MUNSERV for a specific group address range being served, a MCS Client Unserve/Deregister request MUST be sent to the servers in the SG. The members of the SG that receive this update must then clear the cache entry associated with this MCS Client.

In addition to clearing one or more cache entries associated with receiving a MCS Client Unserve/Deregister request, each MARS Server in the SG MUST send out a MARS_LEAVE message on its CCVC in order for clients to change back to a mesh topology 🦋✨.

6. Security Considerations 🔐

Okay bestie, security time, and this part is serious 💀 There is no mechanism to encrypt the CSA Record MARS Specific Part of the messages exchanged between servers. 😭 BUT the SCSP Protocol Independent part [2] has base SCSP security features that can be used to protect against attacks, so it's not all doom 🫶

Any SCSP MARS is susceptible to Denial of Service (DOS) attacks, so it's not immune 🙈 A rogue MARS Client can flood its Server with MARS packets. This is a base MARS problem, as currently defined by [1]. A rogue host can also flood its neighboring SCSP MARS with SCSP packets. HOWEVER, if the authentication option is used, the SCSP MARS databases will not become corrupted, because the bogus packets get tossed out when the authentication check fails ✨ Main character energy for the authentication option, honestly 👑

Because SCSP MARS uses a pairwise authentication model, any information received from a properly authenticated server is trusted and propagated throughout the server group 🌈 That's the whole vibe, but it also means the risk spreads. If the security of any SCSP MARS server is compromised, the entire database becomes vulnerable to corruption originating from that compromised server. 💀 So protect every single server, periodt 💅

References 📚

[1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[2] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "Server Cache Synchronization Protocol", RFC 2334, April 1998.
[3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
[4] Laubach, M., "Classic IP and ARP over ATM", RFC 1577, January 1994.
[5] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.

Acknowledgments 🫶

The authors want to give a big shoutout to Grenville Armitage for his previous distributed MARS work 🦋 They also thank the members of the ION working group of the IETF, whose review and discussion of this document has been invaluable 💜 Literal legends.

Authors' Addresses 💌

James V. Luciani
Bay Networks, Inc.
3 Federal Street, BL3-04
Billerica, MA  01821

Phone: +1-508-916-4734
EMail: luciani@baynetworks.com


Anthony M. Gallo
IBM, Networking Hardware Division
Dept. M6LA/B664
P.O. Box 12195
Research Triangle Park, NC 27709

Phone: +1-919-254-9889
EMail: gallo@raleigh.ibm.com

This document and translations of it may be copied and furnished to others. 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. The one catch is that the above copyright notice and this paragraph must be 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. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's 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. The verbatim disclaimer, because legal text gets no vibe check 🙈

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

ietf: rfc2443 1998-11
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 2443

RFC 2443: A Distributed MARS Service Using SCSP 💖

Status of this Memo ✨

Copyright Notice 🎀

Abstract 🦋

1. Introduction 🧚

2. Overview 🌟

3. Format of the CSA Record MARS Specific Part ✨

Hardware Type

Protocol Type

Protocol SNAP

Version Number

State

Flags

Cluster Member CMI

Src Addr Len

Group Addr Len

ATM Addr T/L

ATM SubAddr T/L

Source Protocol Address

Source ATM Address

Source ATM SubAddress

Minimum Multicast Group Address

Maximum Multicast Group Address

4. Values for SCSP Protocol Independent Part ✨

4.1 Values for the SCSP "Mandatory Common Part"

4.2 Values for the SCSP "CSAS Record"

5. Detailed State Descriptions ✨

5.1 MARS Server Redirect Entry.

Hardware Type

Protocol Type

Protocol SNAP

Version Number

State

5.2. MCS Serve/Register request ✨

5.3. MARS Client Join/Register request ✨

5.4. MARS Client Leave/Deregister request 👋

5.5. MCS Unserve/Deregister request 🌈

6. Security Considerations 🔐

References 📚

Acknowledgments 🫶

Authors' Addresses 💌

Full Copyright Statement ©️