IP Broadcast over ATM Networks
RFC 2226

Document Type RFC - Proposed Standard (October 1997; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2226 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           T. Smith
Request for Comments: 2226                               IBM Corporation
Category: Standards Track                                    G. Armitage
                                                     Lucent Technologies
                                                            October 1997

                     IP Broadcast over ATM Networks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Abstract

   This memo describes how the IP multicast service being developed by
   the IP over ATM working group may be used to support IP broadcast
   transmission. The solution revolves around treating the broadcast
   problem as a special case of multicast, where every host in the
   subnet or cluster is a member of the group.

   An understanding of the services provided by RFC 2022 is assumed.

1.  Introduction.

   The IETF's first step in solving the problems of running IP over
   Asynchronous Transfer Mode (ATM) technology is described in RFC 1577
   [1].  It provides for unicast communication between hosts and routers
   within Logical IP Subnets (LISs), and proposes a centralized ATM ARP
   Server which provides IP to ATM address resolution services to LIS
   members.

   Two classes of IP service were omitted - multicast and broadcast
   transmissions. Multicasting allows a single transmit operation to
   cause a packet to be received by multiple remote destinations.

Smith & Armitage            Standards Track                     [Page 1]
RFC 2226             IP Broadcast over ATM Networks         October 1997

   Broadcasting typically allows a single transmit operation to cause a
   packet to be received by all IP hosts that are members of a
   particular 'subnet'.

   To address the need for multicast support (represented by
   transmission to IP addresses in the Class D space), RFC 2022
   ("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] was
   created.  This memo creates an analog of the RFC 1577 ARP Server - a
   new entity known as the MARS (Multicast Address Resolution Server).
   The MARS operates as a centralized registry and distribution
   mechanism for mappings between IP multicast addresses and groups of
   ATM unicast addresses. Host behavior is also defined for establishing
   and managing point to multipoint VCs, based on the information
   returned by the MARS, when hosts wish to transmit packets to a
   multicast group.

   This memo aims to show how RFC 2022 may be used to emulate IP
   broadcast within Logical IP Subnets. While the broadcast technique
   does not align itself well with the underlying point-to-point nature
   of ATM, clearly, some applications will still wish to use IP
   broadcasts.  Client-server applications where the client searches for
   a server by sending out a broadcast is one scenario.  Routing
   protocols, most notably RIP, are other examples.

2.  Review of Unicast and Multicast.

   Both the unicast and multicast cases take advantage of the point-to-
   point and point-to-multipoint capabilities defined in the ATM Forum
   UNI 3.1 document [4].  A unicast IP address has a single ATM level
   destination.  Unicast transmissions occur over point to point Virtual
   Channels (VCs) between the source and destination. The ARP Server
   holds mappings between IP destination addresses and their associated
   ATM destination address. Hosts issue an ARP_REQUEST to the ARP Server
   when they wish to ascertain a particular mapping.  The ARP Server
   replies with either an ARP_REPLY containing the ATM address of the
   destination, or an ARP_NAK when the ARP Server is unable to resolve
   the address. If the request is successful the host establishes a VC
   to the destination interface. This VC is then used to forward the
   first (and subsequent) packets to that particular IP destination. RFC
   1577 describes in further detail how hosts are administratively
   grouped in to Logical IP Subnets (LISs), and how the ARP Server
   establishes the initial mappings for members of the LIS it serves.

   The basic host behavior for multicasting is similar - the sender must
   establish and manage a point to multipoint VC whose leaf nodes are
   the group's actual members. Under UNI 3.1 these VCs can only be
   established and altered by the source (root) interface.

Smith & Armitage            Standards Track                     [Page 2]
RFC 2226             IP Broadcast over ATM Networks         October 1997

   The MARS is an evolution of the ARP Server model, and performs two
Show full document text