One document matched: draft-smith-ipatm-bcast-00.txt
Internet-Draft Timothy J. Smith,
IBM Corporation.
Grenville Armitage,
Bellcore.
April 28th, 1995
IP Broadcast over ATM Networks.
<draft-smith-ipatm-bcast-00.txt>
Status of this Memo
This document was submitted to the IETF IP over ATM WG. Publication
of this document does not imply acceptance by the IP over ATM WG of
any ideas expressed within. Comments should be submitted to the ip-
atm@matmos.hpl.hp.com mailing list.
Distribution of this memo is unlimited.
This memo is an internet draft. Internet Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its
Working Groups. Note that other groups may also distribute working
documents as Internet Drafts.
To learn the current status of any Internet-Draft, please check the
"lid-abstracts.txt" listing contained in the Internet-Drafts shadow
directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
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 draft-ietf-ipatm-ipmc-
04.txt 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
Smith, Armitage Expires October 28th, 1995 [Page 1]
Internet Draft April 28th, 1995
[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.
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), the Internet-
Draft draft-ietf-ipatm-ipmc-04.txt ("Support for Multicast over UNI
3.1 based ATM Networks") [2] was created. This draft 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 draft-ietf-ipatm-ipmc-04.txt 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
Smith, Armitage Expires October 28th, 1995 [Page 2]
Internet Draft April 28th, 1995
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.
The MARS is an evolution of the ARP Server model, and performs two
key functions. The first function is the maintenance of a list of
ATM addresses corresponding to the members for each group. This list
is created by a host registration process which involves two messages
- a MARS_JOIN which declares that a host wishes to join the specified
group(s), and a MARS_LEAVE which indicates that a host wishes to
leave the specified group(s).
MARS_JOIN and MARS_LEAVE messages are also redistributed to all
members of the group so that active senders may dynamically adjust
their point to multipoint VCs accordingly.
The other major function is the retrieval of group membership from
MARS (analogous to the ARP Server providing unicast address
mappings). When faced with the need to transmit an IP packet with a
Class D destination address, a host issues a MARS_REQUEST to the
MARS. If the group has members the MARS returns a MARS_MULTI
(possibly in multiple segments) carrying a set of ATM addresses. The
host then establishes an initial point to multipoint VC using these
ATM addresses as the leaf nodes. If the MARS had no mapping it would
return a MARS_NAK.
(draft-ietf-ipatm-ipmc-04.txt also discusses how the MARS can arrange
for Class D groups to be supported by either multicast servers, or
meshes of point to multipoint VCs from host to host. However, from
the host's perspective this is almost completely transparent, and is
not central to this discussion of IP broadcast support.)
This memo describes how a host may utilize the registration and group
management functions in an existing MARS based IP/ATM network to
emulate IP broadcasts.
3. Broadcast as a special case of Multicast.
One possible solution to the broadcast problem would be for a host
that wants to broadcast to issue an ARP Request for each possible IP
address in a LIS. This is of course the brute force method.
Essentially, the ARP Server's ARP table is copied over to the host
Smith, Armitage Expires October 28th, 1995 [Page 3]
Internet Draft April 28th, 1995
one entry at a time.
A better solution would be to treat an IP broadcast address as a
multicast group that includes all members of the cluster (e.g. LIS)
served by a MARS. In this scenario, the host would send a
MARS_REQUEST to the MARS with the subnet IP broadcast address as the
target. The host can then create a point-to-multipoint tree based on
the ATM address returned by the MARS in a MARS_MULTI, and forward any
datagrams through it that are destined to the IP broadcast address.
The MARS needs no additional code or special algorithms to handle the
resolution of IP broadcast addresses. It is simply a general database
that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and
imposes no constraints on the type and length of the 'Protocol
address'. Whether the hosts view it as Class D or 'broadcast' (or
even IP) is purely a host side issue. This level of generality may
lead to different implementations choosing to register to different
"broadcast" addresses. For example, a host with an IP address of
128.250.76.23 and a subnet mask of 255.255.255.0, could register to
255.255.255.255 (limited broadcast to this network), 128.250.255.255
(directed broadcast, also to this network), or 128.250.76.255 (this
subnet) as his broadcast group. In theory, any of these three groups
would yield the same point-to-multipoint channel topology. And if
hosts wishing to perform the same broadcast, choose to use different
broadcast groups, the resulting number of channels could triple.
Therefore, the default registration group MUST be the IP subnet
broadcast address (in the above example, 128.250.76.255).
Note that a host or router wishing to use one of the other broadcast
addresses such as 255.255.255.255 should still use the IP subnet
broadcast address in his MARS_REQUEST or internally map the subnet
broadcast channel to these other broadcast variations.
To ensure the MARS has information to return when it receives a
MARS_REQUEST for an IP broadcast address, all hosts in the cluster
MUST issue a MARS_JOIN for the appropriate IP subnet broadcast
address that they wish to be associated with. This MARS_JOIN should
be issued during boot time. The host's IP/ATM interface code should
be written to allow a JoinLocalGroup on a broadcast address to be
mapped to the appropriate MARS_JOIN. However, the transmission of an
associated IGMP Report (which is the normal consequence of a
JoinLocalGroup) should be suppressed.
At a minimum each IP/ATM interface should issue a JOIN for the LIS
broadcast address (e.g. each host with an interface on the LIS
128.250.76 would issue a JOIN for 128.250.76.255). If the network is
not subnetted, then the network broadcast address should be used
(e.g. each host with an interface on the LIS (and network number)
Smith, Armitage Expires October 28th, 1995 [Page 4]
Internet Draft April 28th, 1995
128.250 would issue a JOIN for 128.250.255.255).
Minimum holding times should be implemented as described in [5] to
minimize tariff fees, and to avoid thrashing. However, there may
need to be some additional work to define their operation with
point-to-multipoint trees.
4. Implications of IP broadcast on ATM level resources.
draft-ietf-ipatm-ipmc-04.txt discusses some of the implications of
large multicast groups on the allocation of ATM level resources, both
within the network and within end station ATM interfaces.
The default mechanism is for IP multicasting to be achieved using
meshes of point to multipoint VCs, direct from source host to group
members. Under certain circumstances system administrators may, in a
manner completely transparent to end hosts, redirect multicast
traffic through ATM level multicast servers. This may be performed on
an individual group basis.
It is sufficient to note here that the IP broadcast 'multicast group'
will constitute the largest consumer of VCs within your ATM network
when it is active. For this reason it will probably be the first
multicast group to have one or more ATM multicast servers assigned to
support it. However, there is nothing unique about multicast servers
assigned to support IP broadcast traffic, so this will not be dealt
with further in this memo. draft-ietf-ipatm-ipmc-04.txt contains
further discussion on how multiple multicast servers might be
configured to share the load and provide redundancy in the case of
one server failing.
(Current discussion in the ip-atm working group on encapsulation
mechanisms to solve the problem of reflected packets returning from
multicast servers are outside the scope of this memo. Here we simply
assume the underlying multicast service works.)
5. Further discussion.
Another point that has been discussed in the ip-atm forum, but is not
resolved by this memo, is the issue of "auto configuration" or
"diskless boot". This memo describes a broadcast solution that
requires the use of the MARS. Therefore, at a minimum, the ATM
address of the MARS must be manually configured into a diskless
workstation. Suggestions such as universal channel numbers, and
universal ATM addresses have been proposed, however, no agreement has
been reached.
Smith, Armitage Expires October 28th, 1995 [Page 5]
Internet Draft April 28th, 1995
Security Considerations
This memo does not address security issues.
Acknowledgments
The apparent simplicity of this memo owes a lot to the services
provided in [2], which itself is the product of much discussion on
the IETF's IP-ATM working group mailing list.
Author's Address
Timothy J. Smith
International Business Machines Corporation
Network Routing Systems
N21/664
P.O.Box 12195
Research Triangle Park, NC 27709
Phone: (919) 254-4723
EMail: tjsmith@vnet.ibm.com
Grenville Armitage
Internetworking Research Group,
MRE 2P340, 445 South Street,
Morristown, NJ, 07960
Phone: (201) 829 2635
Email: gja@thumper.bellcore.com
Smith, Armitage Expires October 28th, 1995 [Page 6]
Internet Draft April 28th, 1995
References
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, December 1993.
[2] G. Armitage, "Support for Multicast over UNI 3.1 based ATM
Networks", Internet-Draft, IP over ATM Working Group, draft-ietf-
ipatm-ipmc-04.txt, February 1995.
[3] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
Stanford University, August 1989.
[4] ATM Forum, "ATM User-Network Interface Specification Version
3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
[5] M. Perez, F. Liaw, D. Grossman, A. Mankin, E. Hoffman, A. Malis,
"ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
Smith, Armitage Expires October 28th, 1995 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 23:29:37 |