Support for Multicast over UNI 3.0/3.1 based ATM Networks
Extracted elements (27)
The MARS increments the Cluster Sequence Number (CSN) on every transmission over ClusterControlVC, even when no database change has occurred, so that cluster members can detect missed transmissions (not just missed changes). This allows detection of any gap in receipt of ClusterControlVC traffic, triggering proactive revalidation rather than relying on detecting stale state.
VC meshes provide better data-path throughput and lower end-to-end latency than MCS-based approaches by eliminating intermediate AAL_SDU reassembly, but consume more VC resources (O(senders) VCs per group member) and generate O(senders) signalling events per membership change. MCSs reduce resource consumption to 2 VCs per endpoint and a single signalling event per membership change, but introduce a 'reflected packet' problem requiring additional per-AAL_SDU detection overhead.
For the purposes of the MARS protocol, UNI 3.0 and UNI 3.1 provide equivalent multicast support. Differences between the two specifications in required signalling elements are covered in RFC 1755. Both restrict multicasting to point-to-multipoint unidirectional VCs where only the root may add or remove leaf nodes.
The unique LLC/SNAP codepoint for MARS (PID 0x00-03 from the IANA OUI) differs from ATMARP, allowing MARS and ARP Server functionality to be implemented within a common entity sharing a single client-server VC if the implementor chooses. MARS clients use the source address fields to identify their own messages returned by the MARS.
Cluster members MUST provide only a single <min,max> pair in each JOIN/LEAVE message they issue, but MUST be capable of processing multiple <min,max> pairs received from the MARS. The set of pairs MUST be ordered as an ascending sequence of non-overlapping address blocks (max(N) < min(N+1)).
Each outgoing multicast VC MUST have a configurable inactivity timer; when it expires an L_RELEASE is issued and the group no longer has an active path. The timer SHOULD be no less than 1 minute, with a RECOMMENDED default of 20 minutes.
For L_MULTI_RQ/L_MULTI_ADD failures with UNI cause codes 49, 51, 37, or 41 (resource/QoS unavailable or temporary failure), the request MUST be retried after a random delay of 5–10 seconds, doubling on each subsequent failure. For other failure causes the ATM address is dropped from the group membership set. The VC MAY be considered 'up' before all failed L_MULTI_ADDs have been re-issued.
MARS_JOIN and MARS_LEAVE messages MUST be retransmitted at intervals no shorter than 5 seconds (default 10 seconds) until a copy is received back from the MARS (identified by matching mar$op, mar$flags.register, mar$flags.sequence, mar$pnum, source ATM address, and first <min,max> pair, with mar$flags.copy=1). After 5 retransmissions without acknowledgment, the failure MUST be treated as a MARS failure triggering MARS reconnection.
Network administrators MUST ensure that each Logical IP Subnet (LIS) is served by a separate MARS, creating a one-to-one mapping between cluster and unicast LIS. Relaxation of this restriction MAY only occur after future research on the interaction between existing layer 3 multicast routing protocols and unicast subnet boundaries.
The Cluster Sequence Number (CSN) is tracked via an unsigned 32-bit Host Sequence Number (HSN). On receipt of any message carrying mar$msn, the endpoint computes Seq.diff = mar$msn - HSN using unsigned 32-bit arithmetic; if Seq.diff is neither 0 nor 1, the endpoint MUST revalidate all open multicast group VCs.
The mar$afn field SHALL be 0x000F for all MARS messages defined in this document. Where a protocol has an assigned number in the mar$pro.type space (excluding 0x80), the short form MUST be used when transmitting MARS messages.
The mar$chksum field carries a standard IP checksum over the entire MARS message (excluding LLC/SNAP header), computed with the field set to zero. Receivers MUST only validate the checksum when the received mar$chksum is non-zero; messages with mar$chksum of 0 are always considered valid. Implementors MAY choose to ignore the checksum since AAL5 provides a 32-bit CRC.
To become a cluster member an endpoint MUST register with the MARS by sending a MARS_JOIN with mar$flags.register=1. Upon successful registration the MARS assigns a 16-bit Cluster Member Identifier (CMI) returned in mar$cmi; the cluster member MUST note this value for future use. Registration also causes the MARS to add the endpoint as a leaf node of ClusterControlVC.
Upon receiving a MARS_MIGRATE (mar$op=13), each cluster member MUST close the existing outgoing VC for the group specified in mar$tpa (via L_RELEASE) and establish a new outgoing VC using the ATM addresses carried in the MARS_MIGRATE message as the new group membership set.
When an ERR_L_DROP is received, the associated ATM endpoint MUST be removed from the locally held set for that VC, and after a random period of 1–10 seconds the VC_revalidate flag MUST be set true. When ERR_L_RELEASE is received the entire leaf set is cleared and the VC is shut down.
When the MARS returns no mapping (MARS_NAK) or the client is the only group member, the client MUST delay sending a new MARS_REQUEST for that group for no less than 5 seconds and no more than 10 seconds. If a sequence jump is detected in a multi-part MARS_MULTI the host MUST wait for the final part, discard all results, and repeat the MARS_REQUEST. A timer MUST flag failure of the last MARS_MULTI with a default of 10 seconds.
A Cluster is defined as the set of ATM interfaces choosing to participate in direct ATM connections for multicasting AAL_SDUs between themselves, all sharing a common MARS. Each cluster has a ClusterControlVC (point-to-multipoint VC from MARS to all cluster members) and, when MCSs are in use, a ServerControlVC (point-to-multipoint VC to all registered MCSs).
The Multicast Address Resolution Server (MARS) is an extended analog of the RFC 1577 ARP Server that maintains {layer 3 multicast group address, ATM.1, ATM.2, ..., ATM.n} mappings and distributes group membership updates to cluster members over a point-to-multipoint ClusterControlVC. It supports both VC mesh and Multicast Server (MCS) forwarding models on a per-group basis.
The Security Considerations section (section 65 of the document) is present but the document text was truncated before that section. The MARS architecture has inherent trust assumptions: cluster members rely on the MARS for correct group membership information, and a compromised MARS could redirect multicast traffic or deny service by returning incorrect ATM addresses or manipulating the ClusterControlVC.
Each outgoing multipoint VC has a boolean VC_revalidate flag. The flag is set true at a random time 1–10 seconds after triggering events (ERR_L_DROP on a leaf node, or CSN jump detection); it is checked before each packet transmission and cleared upon completing a MARS_REQUEST-based reconciliation of the group membership against the currently open VC leaf set. Packet transmission continues on the VC during revalidation to minimize disruption.
All MARS control messages MUST be LLC/SNAP encapsulated using codepoints [0xAA-AA-03][0x00-00-5E][0x00-03] followed by the MARS control message, where 0x00-00-5E is the IANA OUI and 0x00-03 is the PID. This codepoint differs from ATMARP, allowing co-residency on the same VC.
ATM address type/length fields (mar$shtl, mar$sstl, mar$thtl, mar$tstl) are 8-bit fields coded as: bit 7 reserved (must be 0), bit 6 indicates address format (0 = ATM Forum NSAP, 1 = native E.164), bits 0–5 give the address length in octets. A zero length means the address is null and no space is allocated in the message.
Every MARS control message begins with a fixed header: mar$afn (16-bit address family), mar$pro (56-bit protocol identification), mar$hdrrsv (24-bit reserved), mar$chksum (16-bit IP checksum), mar$extoff (16-bit extensions offset), mar$op (16-bit operation code), mar$shtl (8-bit source ATM number type/length), mar$sstl (8-bit source ATM subaddress type/length). The overall message structure is [Fixed header][Mandatory fields][Addresses][Supplementary TLVs].
MARS_JOIN (mar$op=4) and MARS_LEAVE (mar$op=5) share the same format, carrying: mar$pnum (16-bit count of <min,max> group address pairs), mar$flags (16-bit: bit 15=layer3grp, bit 14=copy, bit 13=register, bit 12=punched, bits 0–7=sequence; bits 8–11 reserved and MUST be zero), mar$cmi (16-bit Cluster Member ID), mar$msn (32-bit CSN set by MARS), and N variable-length <mar$min.i, mar$max.i> address pairs.
MARS_MULTI (mar$op=2) carries: mar$tnum (16-bit count of returned ATM address pairs), mar$seqxy (16-bit: leading bit x is end-of-reply flag, remaining 15 bits y are sequence number starting at 1), and mar$msn (32-bit MARS Sequence Number). Multiple target ATM address pairs {mar$tha.i, mar$tsa.i} follow the fixed fields.
MARS_REQUEST (mar$op=1) carries the multicast group address in mar$tpa with null target hardware address (mar$thtl and mar$tstl both zero). In IPv4 environments mar$pro=0x800 and mar$tpln MUST be 4; source fields MUST carry the issuing client's ATM number and subaddress. MARS_NAK is the MARS_REQUEST returned with mar$op=6, all other fields unchanged.
The mar$pro field is subdivided into mar$pro.type (16-bit, covering NLPIDs 0x00–0xFF, reserved 0x0100–0x03FF, ATM Forum 0x0400–0x04FF, Ethertypes 0x0600–0xFFFF) and mar$pro.snap (40-bit optional SNAP extension). When mar$pro.type == 0x80 the long form with SNAP extension is used; otherwise mar$pro.snap MUST be zero on transmit and ignored on receive.