IP Broadcast over ATM Networks
Extracted elements (18)
ARP Server-based broadcast solutions were rejected because they lack a registration mechanism that supports diskless boot (the client cannot determine its subnet to calculate LIS membership), and they cannot transparently introduce a Multicast Server (MCS) to reduce VC resource consumption.
IP broadcast is treated as a special case of multicast where every host in the LIS is a member of the group, reusing the MARS infrastructure without requiring modifications to MARS itself.
MARS requires no additional code or special algorithms for IP broadcast resolution because it is a general database holding {Protocol address, ATM addresses} mappings with no constraints on the protocol address type; broadcast vs. multicast is purely a host-side distinction.
MARS should NOT expect both IP source and ATM source address fields of MARS_JOIN to be filled in, since diskless boot hosts registering for broadcast may not yet know their IP address; only the ATM source address is needed for group membership.
The all ones broadcast group (255.255.255.255) is chosen as the single broadcast group for all LIS members rather than subnet-directed broadcast, because diskless boot clients do not know their subnet and therefore cannot register with a subnet-specific group.
The alternative 'all ones first, subnet broadcast second' approach was rejected because servers would need to be registered to two groups simultaneously, creating ambiguity at the link layer about which broadcast VC to use, requiring application software rewrites.
A MARS MUST serve only one LIS to ensure that the 255.255.255.255 broadcast group is joined only by hosts from one LIS, keeping its scope bound to conventional broadcast interpretation; RFC 2022 permits relaxing this restriction after future research.
Diskless boot (bootp) clients must use 255.255.255.255 in MARS because they do not know their subnet; the bootp server must also respond using 255.255.255.255 since it cannot send a directed or subnet-directed broadcast to a client without a known IP address.
The Multicast Server (MCS) described in RFC 2022 may be used without modification to service the broadcast groups defined in this memo, potentially reducing the number of VCs per host to two (one incoming, one outgoing).
A broadcast channel timeout period MAY be specified with a minimum value of one minute and a RECOMMENDED default value of 20 minutes, after which an inactive broadcast channel should be torn down.
A host MUST monitor the MARS_JOIN/MARS_LEAVE messages for 255.255.255.255 to keep the broadcast channel current.
A host, soon after MARS registration, MUST issue a MARS_JOIN to the all ones broadcast address (255.255.255.255) with the mar$flags.layer3grp reset.
All members of a LIS MUST use the all ones broadcast group (255.255.255.255) in MARS when registering to receive broadcast transmissions, to ensure consistency and support diskless boot clients that cannot determine their subnet.
The default behavior SHALL be to join the all ones broadcast group in MARS; a host MAY provide a mechanism for retracting its entry in the broadcast group.
MARS_JOIN and MARS_LEAVE messages are redistributed to all current group members so that active senders can dynamically adjust their point-to-multipoint VCs to add or remove leaf nodes.
The 'broadcast channel' is the point-to-multipoint VCC established and maintained based on the membership list of the 255.255.255.255 address entry in MARS, used for transmitting all IP layer broadcast packets.
Two broadcast groups are defined: (1) 255.255.255.255 'all ones' limited broadcast, and (2) x.z CIDR-prefix directed broadcast where x is the subnet number and z is all ones. Both have identical link-layer scope within a LIS.
The security implications of IP broadcast over ATM using MARS are no greater or less than those of using any other multicast group in the MARS multicast address range. Any required security enhancements would need to be added as extensions to the base RFC 2022 architecture.