As per Relevance of the word multicast, we have this rfc below:
Network Working Group T.
Request for Comments: 2226 IBM
Category: Standards Track G.
Lucent
October 1997
IP Broadcast over ATM
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This memo describes how the IP multicast service being developed
the IP over ATM working group may be used to support IP
transmission. The solution revolves around treating the
problem as a special case of multicast, where every host in
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
Asynchronous Transfer Mode (ATM) technology is described in RFC 1577
[1]. It provides for unicast communication between hosts and
within Logical IP Subnets (LISs), and proposes a centralized ATM
Server which provides IP to ATM address resolution services to
members
Two classes of IP service were omitted - multicast and
transmissions. Multicasting allows a single transmit operation
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
packet to be received by all IP hosts that are members of
particular 'subnet'.
To address the need for multicast support (represented
transmission to IP addresses in the Class D space), RFC 2022
("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2]
created. This memo creates an analog of the RFC 1577 ARP Server -
new entity known as the MARS (Multicast Address Resolution Server).
The MARS operates as a centralized registry and
mechanism for mappings between IP multicast addresses and groups
ATM unicast addresses. Host behavior is also defined for
and managing point to multipoint VCs, based on the
returned by the MARS, when hosts wish to transmit packets to
multicast group
This memo aims to show how RFC 2022 may be used to emulate
broadcast within Logical IP Subnets. While the broadcast
does not align itself well with the underlying point-to-point
of ATM, clearly, some applications will still wish to use
broadcasts. Client-server applications where the client searches
a server by sending out a broadcast is one scenario.
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
UNI 3.1 document [4]. A unicast IP address has a single ATM
destination. Unicast transmissions occur over point to point
Channels (VCs) between the source and destination. The ARP
holds mappings between IP destination addresses and their
ATM destination address. Hosts issue an ARP_REQUEST to the ARP
when they wish to ascertain a particular mapping. The ARP
replies with either an ARP_REPLY containing the ATM address of
destination, or an ARP_NAK when the ARP Server is unable to
the address. If the request is successful the host establishes a
to the destination interface. This VC is then used to forward
first (and subsequent) packets to that particular IP destination.
1577 describes in further detail how hosts are
grouped in to Logical IP Subnets (LISs), and how the ARP
establishes the initial mappings for members of the LIS it serves
The basic host behavior for multicasting is similar - the sender
establish and manage a point to multipoint VC whose leaf nodes
the group's actual members. Under UNI 3.1 these VCs can only
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
key functions. The first function is the maintenance of a list
ATM addresses corresponding to the members for each group. This
is created by a host registration process which involves two
- a MARS_JOIN which declares that a host wishes to join the
group(s), and a MARS_LEAVE which indicates that a host wishes
leave the specified group(s).
MARS_JOIN and MARS_LEAVE messages are also redistributed to
members of the group so that active senders may dynamically
their point to multipoint VCs accordingly
The other major function is the retrieval of group membership
MARS (analogous to the ARP Server providing unicast
mappings). When faced with the need to transmit an IP packet with
Class D destination address, a host issues a MARS_REQUEST to
MARS. If the group has members the MARS returns a MARS_
(possibly in multiple segments) carrying a set of ATM addresses.
host then establishes an initial point to multipoint VC using
ATM addresses as the leaf nodes. If the MARS had no mapping it
return a MARS_NAK
(RFC 2022 also discusses how the MARS can arrange for Class D
to be supported by either multicast servers, or meshes of point
multipoint VCs from host to host. However, from the host'
perspective this is transparent, and is not central to
discussion of IP broadcast support.)
This memo describes how a host may utilize the registration and
management functions in an existing MARS based IP/ATM network
emulate IP broadcasts
3. Broadcast as a special case of Multicast
Many of the problems that occur when implementing a
solution also occur in when implementing a multicast solution.
fact, broadcast may be considered a special case of multicast.
is, broadcast is a multicast group whose members include all
in the LIS
There are two broadcast groups which this memo addresses
1) 255.255.255.255 - "All ones"
2) x.z - CIDR-prefix (subnet) directed
Smith & Armitage Standards Track [Page 3]
RFC 2226 IP Broadcast over ATM Networks October 1997
Broadcast (1) is sometimes referred to as a limited broadcast to
physical network. Broadcast (2) can be thought of as the
broadcast for subnets or networks in the old paradigm. As
in [6] and [7], the notion of subnets and networks is being
with a more efficient utilization of the routing address space
as Classless Inter-Domain Routing. The CIDR-prefix (x) is
combination of IP address and subnet mask that denotes the
number. The host portion of the address (z) is all ones. One
note that while these broadcasts have different scopes at the IP
network layer, they have precisely the same scope at the link
-- namely that all members of the LIS will receive a copy
These addresses may be used in two environments
o Broadcasting to all members of a given LIS
a priori knowledge of a host's IP address
subnet mask are known (e.g. the CIDR-prefix
broadcast).
o Broadcasting to all members of a physical
without knowledge of a host's IP address
subnet mask (e.g. the all ones broadcast).
On a broadcast medium like Ethernet, these two environments result
the same physical destination. That is, all stations on that
will receive the broadcast even if they are on different
subnets, or are non-IP stations. With ATM, this may not be the case
Because ATM is non-broadcast, a registration process must take place
And if there are stations that register to some broadcast groups,
not others, then the different broadcast groups will have
memberships. The notion of broadcast becomes inconsistent
One case that requires the use of the all ones broadcast is that
the diskless boot, or bootp client, where the host boots up, and
not know its own IP address or subnet mask. Clearly, the host
not know which subnet it belongs to. So, to send a broadcast to
bootp server, the diskless workstation must use the group
contains no subnet information, i.e. the 255.255.255.255
group. Carrying the example a little further, the bootp server
after receiving the broadcast, can not send either a directed
nor a subnet directed broadcast to respond to the
workstation. Instead, the bootp server must also use
255.255.255.255 group to communicate with the client
While the all ones broadcast is required at the IP layer, it also
relevance at the link layer when deciding which broadcast group
register with in MARS. In other words, a bootp client wishing
register for a link layer broadcast, can only register
Smith & Armitage Standards Track [Page 4]
RFC 2226 IP Broadcast over ATM Networks October 1997
255.255.255.255 in the MARS address space because the client's
is unknown at the time. Given that some applications must use
all ones address in MARS for their broadcast group, and that we
to minimize the number of broadcast groups used by LIS members,
all ones group in MARS MUST be used by all members of the LIS
registering to receive broadcast transmissions. The VCC used
transmitting any broadcast packet will be based on the
registered in the MARS under the 255.255.255.255 address position
This VCC will be referred to as the "broadcast channel" through
remainder of this memo
4. The MARS role in broadcast
Many solutions have been proposed, some of which are listed
Appendix A. This memo addresses a MARS solution which appears to
the best job of solving the broadcast problem
There are a number of characteristics of the MARS architecture
should be kept intact. They include
o MARS contains no knowledge of subnet prefixes and subnet masks
Each group address registered with MARS is managed independently
o A MARS may only serve one LIS. This insures that
broadcast group 255.255.255.255 is joined by hosts from
LIS, keeping its scope bound to conventional interpretation
o The Multicast Server (MCS) described in [2] may be used to
the broadcast groups defined in this memo without modification
The MCS will reduce the number of channels used by the network
The MARS needs no additional code or special algorithms to handle
resolution of IP broadcast addresses. It is simply a general
that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings,
imposes no constraints on the type and length of the '
address'. Whether the hosts view it as Class D or 'broadcast' (
even IP) is purely a host side issue
It is likely that end points will want to use the IP
emulation described here in order to support boot time location
the end point's IP address. This leads to the observation that
MARS should NOT expect to see both the IP source and ATM
address fields of the MARS_JOIN filled in. This is reasonable,
only the ATM source address is used when registering the end point
a group member
The MARS architecture is sufficient to insure the integrity of
broadcast group list without any modification
Smith & Armitage Standards Track [Page 5]
RFC 2226 IP Broadcast over ATM Networks October 1997
5. Host Requirements for Broadcast
The following list of bullets describes additional characteristics
a MARS-compliant host. These characteristics are required to
advantage of the broadcast function
o A host must register as a MARS client
o A host, soon after registration MUST issue a MARS_JOIN to
all ones broadcast address (i.e. 255.255.255.255) with
mar$flags.layer3grp reset
o When transmitting packets, the host should map all IP
broadcasts to the VCC (broadcast channel) created and
based on the all ones entry in MARS
o A host MUST monitor the MARS_JOIN/MARS_LEAVE
for 255.255.255.255 to keep the broadcast channel current
o A broadcast channel should be torn down after a period
inactivity. The corresponding timeout period MAY be
with a minimum value of one minute, and a
default value of 20 minutes
One should note that while every member participating in
broadcast MUST be a member of the all ones group, not all
will choose to transmit broadcast information. Some members
only elect to receive broadcast information passively. Therefore,
a LIS with n stations, there may be less than n channels
at each station for broadcast information. Further reductions may
gained by adding a Multicast Server (MCS) to the
environment which could reduce the number of VCs to two (
incoming, one outgoing), or one for a station that only wishes
listen
It is well understood that broadcasting in this environment may
the resources of the network and of the hosts that use it
Therefore, an implementer MAY choose to provide a mechanism
retracting the host's entry in the broadcast group after it has
established or prior to joining the group. The MARS_LEAVE is used
request withdrawal from the group if the host wishes to
broadcast reception after it has joined the group. The
behavior SHALL be to join the all ones broadcast group in MARS
Smith & Armitage Standards Track [Page 6]
RFC 2226 IP Broadcast over ATM Networks October 1997
6. Implications of IP broadcast on ATM level resources
RFC 2022 discusses some of the implications of large multicast
on the allocation of ATM level resources, both within the network
within end station ATM interfaces
The default mechanism is for IP multicasting to be achieved
meshes of point to multipoint VCs, direct from source host to
members. Under certain circumstances system administrators may, in
manner completely transparent to end hosts, redirect
traffic through ATM level Multicast Servers (MCSs). This may
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
when it is active. For this reason it will probably be the
multicast group to have one or more ATM MCSs assigned to support it
However, there is nothing unique about an MCS assigned to support
broadcast traffic, so this will not be dealt with further in
memo. RFC 2022 contains further discussion on the
application of multiple MCSs to provide fault-tolerant architectures
7. Further discussion
A point of discussion on the ip-atm forum revolved around "
configuration" and "diskless boot". This memo describes a
solution that requires the use of the MARS. Therefore, at a minimum
the ATM address of the MARS must be manually configured into
diskless workstation. Suggestions such as universal channel numbers
and universal ATM addresses have been proposed, however, no
has been reached
Another topic for discussion is multiprotocol support. MARS
designed for protocol independence. This memo specifically
the IP broadcast case, identifying which addresses are most
in the IP address space. However, the principles apply to any
3 protocol. Further work should be performed to identify
addresses for other layer 3 protocols
Finally, there has been support voiced for a link layer
that would be independent of the layer 3 protocol. Such a
may provide a simpler set of rules through which
applications may be used. In addition, some solutions also
for more efficient use of VCCs
Smith & Armitage Standards Track [Page 7]
RFC 2226 IP Broadcast over ATM Networks October 1997
Security
This memo addresses a specific use of the MARS architecture
components to provide the broadcast function. As such, the
implications are no greater or less than the implications of
any of the other multicast groups available in the multicast
range. Should enhancements to security be required, they would
to be added as an extension to the base architecture in RFC 2022.
The apparent simplicity of this memo owes a lot to the
provided in [2], which itself is the product of much discussion
the IETF's IP-ATM working group mailing list. Grenville
worked on this document while at Bellcore
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
December 1993.
[2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based
Networks", RFC 2022, November 1995.
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[4] ATM Forum, "ATM User-Network Interface Specification
3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
[5] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E.
A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
February 1995.
[6] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter
Domain Routing (CIDR): an Address Assignment and
Strategy", RFC 1519, September 1993.
[7] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[8] Bradner, S., "Key words for use in RFCs to Indicate
Levels, BCP 14, RFC 2119, March 1997.
Smith & Armitage Standards Track [Page 8]
RFC 2226 IP Broadcast over ATM Networks October 1997
Authors'
Timothy J.
Network Routing Systems
International Business Machines Corporation
N21/664
P.O.Box 12195
Research Triangle Park, NC 27709
Phone: (919) 254-4723
EMail: tjsmith@vnet.ibm.
Grenville
Bell Labs, Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ, 07733
EMail: gja@lucent.
Smith & Armitage Standards Track [Page 9]
RFC 2226 IP Broadcast over ATM Networks October 1997
Appendix A. Broadcast
Throughout the development of this memo, there have been a number
alternatives explored and discarded for one reason or another.
appendix documents these alternatives and the reason that they
not chosen
A.1 ARP Server Broadcast Solutions
The ARP Server is a good candidate to support broadcasting. There
an ARP Server for every LIS. The ARP Server contains the entire
membership. These are fundamental ingredients for the
function
A.1.1 Base Solution without modifications to ARP Server
One may choose as an existing starting point to use only what
available in RFC 1577. That is, a host can easily calculate
range of members in its LIS based on its own IP address and
mask. The host can then issue an ARP Request for every member of
LIS. With this information, the host can then set up point-to-
connections with all members, or can set up a point-to-
connection to all members. There you have it, the poor man'
broadcast
While this solution is very straight forward, it suffers from
number of problems
o The load on the ARP Server is very large. If all stations
a LIS choose to implement broadcasting, the initial surge of
Requests will be huge. Some sort of slow start sequence would
needed
o The amount of resource required makes this a non-
solution. The authors believe that broadcasting will require
MCS to reduce the number of channel resources required to
each broadcast 'group'. Using the ARP Server in this manner
not allow an MCS to be transparently introduced. (Basic RFC1577
interfaces also do not implement the extended LLC/
encapsulation required to safely use more than one MCS).
o The diskless boot solution can not function in this
because it may be unable to determine which subnet to which
belongs
Smith & Armitage Standards Track [Page 10]
RFC 2226 IP Broadcast over ATM Networks October 1997
A.1.2 Enhanced ARP Server solution
This solution is similar to the base solution except that it
some of the (MARS) multicast solution and embeds it in the
Server. The first enhancement is to add the MARS_MULTI command
the set of opcodes that the ARP Server supports. This would allow
host to issue a single request, and to get back the list of
in one or more MARS_REPLY packets. Rather than have a
mechanism, the ARP Server could simply use the list of members
have already been registered. When a request comes in for the
broadcast address, the ARP Server would aggregate the list, and
the results to the requester
This suffers from two drawbacks
1) Scalability with regard to number of VCs is still an issue
One would eventually need to add in some sort of
server solution to the ARP Server
2) The diskless boot scenario is still broken. There is
way for a station to perform a MARS_MULTI without
knowing its IP address and subnet mask
The diskless boot problem could be solved by adding to the ARP
a registration process where anyone could register to
255.255.255.255 address. These changes would make the ARP
look more and more like MARS
A.2 MARS Solutions
If we wish to keep the ARP Server constant as described in RFC 1577,
the alternative is to use the Multicast Address Resolution
(MARS) described in [2].
MARS has three nice features for broadcasting
1) It has a generalized registration approach which
for any address to have a group of entities registered
So, if the subnet address is not known, a host
register for an address that is known (e.g. 255.255.255.255).
2) The command set allows for lists of members to be
in a single MARS_MULTI packet. This reduces traffic
3) MARS contains an architecture for dealing with
scalability issues. That is, Multicast Servers (MCSs
may be used to set up the point-to-multipoint
Smith & Armitage Standards Track [Page 11]
RFC 2226 IP Broadcast over ATM Networks October 1997
and reduce the number of channels that a host needs
set up to one. Hosts wishing to broadcast will
send the packet to the MCS who will then forward it
all members of the LIS
A.2.1. CIDR-prefix (Subnet) Broadcast solution
One of the earliest solutions was to simply state that
support would be implemented by using a single multicast group in
class D address space -- namely, the CIDR-prefix (subnet)
address group. All members of a LIS would be required to register
this address, and use it as required. A host wishing to use
the 255.255.255.255 broadcast, or the network broadcast
would internally map the VC to the subnet broadcast VC. The all
and network broadcast addresses would exist on MARS, but would
unused
The problem with this approach goes back to the diskless
problem. Because the workstation may not know which subnet
belongs to, it doesn't know which group to register with
A.2.2. All one's first, subnet broadcast
This solution acknowledges that the diskless boot problem requires
generic address (one that does not contain CIDR-prefix (subnet
information) to register with and to use until subnet knowledge
known. In essence, all stations first register to
255.255.255.255 group, then as they know their subnet information
they could optionally de-register from the all one's group
register to the CIDR-prefix (subnet) broadcast group
This solution would appear to solve a couple of problems
1) The bootp client can function if the server
registered to the all one's group continuously
2) There will be less traffic using the all ones
because the preferred transactions will be on
subnet broadcast channel
Unfortunately the first bullet contains a flaw. The server
continually be registered to two groups -- the all ones group and
subnet broadcast group. If this server has multiple processes
are running different IP applications, it may be difficult for
link layer to know which broadcast VC to use. If it always uses
all ones, then it will be missing members that have
themselves from the all ones and have registered to the
broadcast. If it always uses the subnet broadcast group,
Smith & Armitage Standards Track [Page 12]
RFC 2226 IP Broadcast over ATM Networks October 1997
diskless boot scenario gets broken. While making the decision at
link layer may require additional control flows be built into
path, it may also require the rewriting of application software
In some implementations, a simple constant is used to indicate to
link layer that this packet is to be transmitted to the
"MAC" address. The assumption is that the physical network
and the logical protocol broadcast are one and the same. As
out earlier, this is not the case with ATM. Therefore
would need to specifically identify the subnet broadcast
address to take advantage of the smaller group
These problems could be solved in a number of ways, but it
thought that they added unnecessarily to the complexity of
broadcast solution
Appendix B. Should MARS Be Limited to a Single LIS
RFC 2022 explicitly states that a network administrator MUST
that each LIS is served by a separate MARS, creating a one-to-
mapping between cluster and a unicast LIS. But, it also
that relaxation of this restriction MAY occur after future
warrants it. This appendix discusses some to the
implications to broadcast should this restriction be removed
The most obvious change would be that the notion of a cluster
span more than one LIS. Therefore, the broadcast group
255.255.255.255 would contain members from more than one LIS
It also should be emphasized that the one LIS limitation is not
restriction of the MARS architecture. Rather, it is only enforced
an administrator chooses to do so
Smith & Armitage Standards Track [Page 13]
RFC 2226 IP Broadcast over ATM Networks October 1997
Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implmentation may be prepared, copied,
andand distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Smith & Armitage Standards Track [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
