As per Relevance of the word pusateri, we have this rfc below:
Network Working Group T.
Request for Comments: 1469
June 1993
IP Multicast over Token-Ring Local Area
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This document specifies a method for the transmission of IP
datagrams over Token-Ring Local Area Networks. Although an
solution has emerged and is currently being used, it is the
of this document to specify a more efficient means of
using an assigned Token-Ring functional address
IP multicasting provides a means of transmitting IP datagrams to
group of hosts. A group IP address is used as the
address in the IP datagram as documented in STD 5, RFC 1112 [1].
These group addresses, also referred to as Class D addresses, fall
the range from 224.0.0.0 to 239.255.255.255. A standard method
mapping IP multicast addresses to media types such as ethernet
fddi exist in [1] and RFC 1188 [2]. This document attempts to
the mapping for an IP multicast address to the corresponding Token
Ring MAC address
The Token-Ring Network Architecture Reference [3] provides
types of addressing mechanisms. These include both
(unicast) and group addresses (multicast). A special subtype
group addresses are called functional addresses and are indicated
a bit in the destination MAC address. They were designed for
used functions such as ring monitoring, NETBIOS, Bridge, and
Manager frames. There are a limited number of functional addresses
31 in all, and therefore several unrelated functions must share
same functional address
Pusateri [Page 1]
RFC 1469 IP Multicast over Token-Ring LANs June 1993
It would be most desirable if Token-Ring could use the same
as ethernet and fddi for IP multicast to hardware
addressing. However, current implementations of Token-
controller chips cannot support this. To see why, we must
examine the Destination MAC address format
Destination Address
The destination MAC address consists of six octets. In the
diagram of a MAC address, the order of transmission of the octets
from top to bottom (octet 0 to octet 5), and the order
transmission of the bits within each octet is from right to left (
0 to bit 7). This is the so-called "canonical" bit order for
802.2 addresses. Addresses supplied to or received from token
interfaces are usually laid out in memory with the bits of each
in the opposite order from that illustrated, i.e., with bit 0 in
high-order (leftmost) position within the octet
7 6 5 4 3 2 1 0
---------------------------------
| | | | | | |U/L|I/G| octet 0
---------------------------------
| | | | | | | | | octet 1
---------------------------------
| | | | | | | |FAI| octet 2
---------------------------------
| | | | | | | | | octet 3
---------------------------------
| | | | | | | | | octet 4
---------------------------------
| | | | | | | | | octet 5
---------------------------------
The low order bit of the high order octet is called the I/G bit.
signifies whether the address is an individual address (0) or a
address (1). This is comparable to the multicast bit in the
Ethernet addressing format
Bit position 1 of the high order octet, called the U/L bit,
whether the address is universally administered (0) or
administered (1). Universally administered addresses are
specified by a standards organization such as the IEEE
If the I/G bit is set to 1 and the U/L bit is 0, the address must
a universally administered group address. If the I/G bit is 1 and
U/L bit is a 1, the address may be either a local administered
address or a functional address. This distinction is determined
Pusateri [Page 2]
RFC 1469 IP Multicast over Token-Ring LANs June 1993
the Functional Address Indicator (FAI) bit located in bit position 0
of octet 2. If the FAI bit is 0, the address is considered
functional address. And if the FAI bit is 1, this indicates
locally administered group address
Different functional addresses are made by setting one of
remaining 31 bits in the address field. These bits include the 7
remaining bits in octet 2 as well as the 8 bits in octets 3, 4,
5. It is not possible to create more functional addresses by
more than one of these bits at a time
Three methods exist for mapping between an IP multicast address and
hardware address. These include
1. The all rings broadcast
2. The assigned functional
3. The existing IEEE assigned IP Multicast group
In order to insure interoperability, all systems supporting
multicasting on each physical ring must agree on the hardware
to be used. Therefore, the method used should be configurable on
given interface. Bridges may provide a means to translate
different methods for each physical ring that is being bridged
Method (3) is recommended but due to hardware limitations of Token
Ring controller chips, may not be possible. In this case, Method (2)
is preferred over Method (1). For backward compatibility,
that support (2) MUST also support (1). And systems that support (3)
MUST also support (2) and therefore (1). In the absence
configuration information, the default should be to use the
functional address (2).
IP Multicast Functional
Because there is a shortage of Token-Ring functional addresses,
IP multicast addresses have been mapped to a single Token-
functional address. In canonical form, this address is 03-00-00-20-
00-00. In non-canonical form, it is C0-00-00-04-00-00. It should
noted that since there are only 31 possible functional addresses
there may be other protocols that are assigned this
address as well. Therefore, just because a frame is sent to
functional address 03-00-00-20-00-00 does not mean that it is an
multicast frame
Pusateri [Page 3]
RFC 1469 IP Multicast over Token-Ring LANs June 1993
The author would like to thank John Moy, Fred Baker, Steve Deering
and Rob Enns for their review and constructive comments
[1] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, Stanford University, August 1989.
[2] Katz, D., "A Proposed Standard for the Transmission of
Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET
October 1990.
[3] IBM Token-Ring Network, Architecture Reference, Publication SC30-
3374-02, Third Edition, (September, 1989).
Security
Security issues are not discussed in this memo
Author's
Thomas J.
11820 Edgewater Ct
Raleigh, NC 27614
EMail: pusateri@cs.duke.
Pusateri [Page 4]
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
