Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
obsoleted by
- rfc-2417 — Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
Extracted elements (26)
The MARS MIB is designed for use in conjunction with ATM-MIB (RFC 1695), MIB-II (RFC 1213), and optionally IF-MIB (RFC 1573) rather than being self-contained; this avoids duplicating ATM interface and IP address management objects already standardized in those MIBs.
The marsClientVcTable uses a compound index of (ipAdEntAddr, marsClientIndex, VPI, VCI, minGrpAddr, maxGrpAddr, partyAddr) so that point-to-multipoint VCs—where a single VPI/VCI is associated with multiple party ATM addresses—can be represented as multiple rows sharing the same VPI/VCI values.
The MIB module specification is both compliant with the SNMPv2 SMI and semantically identical to peer SNMPv1 definitions, enabling management by both SNMPv1 (RFC 1157) and SNMPv2 (RFC 1905) protocol implementations.
A row in marsClientTable, marsTable, or marsMcsTable cannot be made 'active' until all corresponding columns are appropriately configured and the agent has created a corresponding row in the associated statistics table (marsClientStatTable, marsStatTable, or marsMcsStatTable respectively).
Rows in marsClientVcTable and marsVcTable for which the VC type is 'svc(2)' cannot be modified or deleted; an SNMP management station must set the row to 'notInService' before modifying non-timer objects in other row types.
The marsClientRetranDelayTimer and marsClientRdmMulReqAddRetrTimer must each be set between 5 and 10 seconds inclusive; the marsClientJoinLeaveRetrInterval minimum is 5 seconds with a recommended default of 10 seconds, and marsClientJoinLeaveRetrLimit maximum is 5.
When a marsClientTable, marsTable, or marsMcsTable row is deleted, it is recommended that the agent or SNMP management station also delete any stale rows in associated tables (e.g., marsClientVcTable, marsVcTable) that reference the deleted row.
When marsClientRowStatus is 'active', the objects marsClientDefaultMarsAddr, marsClientHsn, marsClientRegistration, marsClientCmi, and marsClientDefaultMtu cannot be modified; similarly for corresponding locked fields in marsTable and marsMcsTable.
Multicast group address blocks are represented throughout the MIB as (MinGrpAddr, MaxGrpAddr) IpAddress pairs forming consecutive ranges; equal min and max values denote a single-group block. The marsMcGrpTable entries must be created before being referenced as indices by the host map or server map tables.
The marsClientBackupMarsTable stores backup MARS ATM addresses ordered by marsClientBackupMarsPriority (Unsigned32 0..65535, lower value = higher preference); addresses received via MARS_REDIRECT_MAP are inserted at the top of the list and take precedence over manually configured entries.
The marsClientCmi is a 16-bit Cluster Member Identifier (INTEGER 0..65535) assigned by the MARS to uniquely identify each endpoint attached to the cluster; the value is only valid after marsClientRegistration reaches the 'registered(3)' state.
The marsClientDefaultMtu and marsMcsDefaultMtu objects specify the default cluster MTU with a default value of 9180 bytes (INTEGER 1..65535, DEFVAL 9180); the actual per-VC MTU may differ because it is negotiated during ATM connection setup.
The marsClientHsn is a 32-bit Host Sequence Number (Unsigned32) initialized to zero at cluster member startup; it is updated to the current Cluster Sequence Number (CSN) when the client receives the echo of its own MARS_JOIN from the MARS, and is used to track MARS sequence numbering.
The marsClientStatTable and marsStatTable provide per-client and per-MARS Counter32 message counters covering all MARS control messages: MARS_REQUEST, MARS_JOIN, MARS_LEAVE, MARS_MULTI, MARS_NAK, MARS_MIGRATE, MARS_GROUPLIST_REQUEST/REPLY, MARS_REDIRECT_MAP, MARS_MSERV, MARS_UNSERV, MARS_SJOIN, and MARS_SLEAVE.
The marsClientVcCtrlType object classifies client VCs into: pointToPointVC(1) for bidirectional registration/query signaling to MARS, clusterControlVC(2) for asynchronous updates pushed from MARS to client, and pointToMultiPointVC(3) for multicast data transfer to group members or MCS.
The marsCsn object is a 32-bit Cluster Sequence Number (Unsigned32) incremented by the MARS on every ClusterControlVC message transmission; cluster members use it to detect message loss on ClusterControlVC and to monitor membership changes.
The marsHostMapTable caches IP multicast group address block (min/max IpAddress pair) to cluster member ATM address mappings; rows are classified as static (configured) or dynamic (learned from MARS group updates), and dynamic rows are protected from modification or deletion.
The marsMcGrpAddrUsage object classifies each MARS multicast address block as hostMap(1), serverMap(2), or hostServerMap(3), controlling which mapping tables (host map, server map, or both) reference that address block.
The marsServerMapTable caches IP multicast group address block (min/max IpAddress pair) to MCS ATM address mappings; rows are classified as static or dynamic, with dynamic rows protected from modification or deletion.
The marsSsn object is a 32-bit Server Sequence Number (Unsigned32) incremented by the MARS on every ServerControlVC message transmission; MCS instances use it to detect message loss on ServerControlVC and to monitor MCS membership changes.
The marsVcCtrlType object classifies MARS-side VCs into: pointToPointVC(1) for bidirectional registration from clients and MCS, clusterControlVC(2) for asynchronous updates to ATM clients, and serverControlVC(3) for asynchronous updates to MCS instances (present only when at least one MCS is in use).
The MIB is organized into three top-level object groups: marsClientObjects ({ marsMIB 1 }) for MARS clients, marsObjects ({ marsMIB 2 }) for MARS servers, and marsMcsObjects ({ marsMIB 3 }) for Multicast Servers (MCS), each containing multiple subordinate tables.
The MARS MIB module is registered as marsMIB at OID { snmpModules 17 }, defined via MODULE-IDENTITY for managing MARS clients, servers, and Multicast Servers (MCS) as described in RFC 2022.
The MIB defines numerous read-create objects that allow SNMP management stations to create, modify, and delete rows controlling MARS client registration, server configuration, multicast group membership mappings, VC parameters, and MCS registration; appropriate SNMPv2 access control must be applied to prevent unauthorized modification of these objects, which directly affect multicast forwarding behavior.
The marsClientRegistration object tracks client registration state through five values: notRegistered(1), registering(2), registered(3), reRegisteringFault(4) triggered by fault conditions, and reRegisteringRedirMap(5) triggered upon receipt of a MARS_REDIRECT_MAP directing the client to a different MARS.
The marsMcsRegistration object tracks MCS registration state through five values: notRegistered(1), registering(2), registered(3), reRegisteringFault(4) for fault-driven re-registration, and reRegisteringRedirMap(5) for re-registration after receiving MARS_REDIRECT_MAP directing the MCS to a different MARS.