summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1469.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1469.txt')
-rw-r--r--doc/rfc/rfc1469.txt227
1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1469.txt b/doc/rfc/rfc1469.txt
new file mode 100644
index 0000000..bd3425a
--- /dev/null
+++ b/doc/rfc/rfc1469.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group T. Pusateri
+Request for Comments: 1469 Consultant
+ June 1993
+
+
+ IP Multicast over Token-Ring Local Area Networks
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ This document specifies a method for the transmission of IP multicast
+ datagrams over Token-Ring Local Area Networks. Although an interim
+ solution has emerged and is currently being used, it is the intention
+ of this document to specify a more efficient means of transmission
+ using an assigned Token-Ring functional address.
+
+Introduction
+
+ IP multicasting provides a means of transmitting IP datagrams to a
+ group of hosts. A group IP address is used as the destination
+ address in the IP datagram as documented in STD 5, RFC 1112 [1].
+ These group addresses, also referred to as Class D addresses, fall in
+ the range from 224.0.0.0 to 239.255.255.255. A standard method of
+ mapping IP multicast addresses to media types such as ethernet and
+ fddi exist in [1] and RFC 1188 [2]. This document attempts to define
+ the mapping for an IP multicast address to the corresponding Token-
+ Ring MAC address.
+
+Background
+
+ The Token-Ring Network Architecture Reference [3] provides several
+ types of addressing mechanisms. These include both individual
+ (unicast) and group addresses (multicast). A special subtype of
+ group addresses are called functional addresses and are indicated by
+ a bit in the destination MAC address. They were designed for widely
+ used functions such as ring monitoring, NETBIOS, Bridge, and Lan
+ Manager frames. There are a limited number of functional addresses,
+ 31 in all, and therefore several unrelated functions must share the
+ 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 mapping
+ as ethernet and fddi for IP multicast to hardware multicast
+ addressing. However, current implementations of Token-Ring
+ controller chips cannot support this. To see why, we must first
+ examine the Destination MAC address format.
+
+Destination Address Format
+
+ The destination MAC address consists of six octets. In the following
+ diagram of a MAC address, the order of transmission of the octets is
+ from top to bottom (octet 0 to octet 5), and the order of
+ transmission of the bits within each octet is from right to left (bit
+ 0 to bit 7). This is the so-called "canonical" bit order for IEEE
+ 802.2 addresses. Addresses supplied to or received from token ring
+ interfaces are usually laid out in memory with the bits of each octet
+ in the opposite order from that illustrated, i.e., with bit 0 in the
+ 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. It
+ signifies whether the address is an individual address (0) or a group
+ address (1). This is comparable to the multicast bit in the DIX
+ Ethernet addressing format.
+
+ Bit position 1 of the high order octet, called the U/L bit, specifies
+ whether the address is universally administered (0) or locally
+ administered (1). Universally administered addresses are those
+ 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 be
+ a universally administered group address. If the I/G bit is 1 and the
+ U/L bit is a 1, the address may be either a local administered group
+ address or a functional address. This distinction is determined by
+
+
+
+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 a
+ functional address. And if the FAI bit is 1, this indicates a
+ locally administered group address.
+
+ Different functional addresses are made by setting one of the
+ 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, and
+ 5. It is not possible to create more functional addresses by setting
+ more than one of these bits at a time.
+
+ Three methods exist for mapping between an IP multicast address and a
+ hardware address. These include:
+
+ 1. The all rings broadcast address
+
+ 2. The assigned functional address
+
+ 3. The existing IEEE assigned IP Multicast group addresses
+
+ In order to insure interoperability, all systems supporting IP
+ multicasting on each physical ring must agree on the hardware address
+ to be used. Therefore, the method used should be configurable on a
+ given interface. Bridges may provide a means to translate between
+ 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, systems
+ that support (2) MUST also support (1). And systems that support (3)
+ MUST also support (2) and therefore (1). In the absence of
+ configuration information, the default should be to use the assigned
+ functional address (2).
+
+IP Multicast Functional Address
+
+ Because there is a shortage of Token-Ring functional addresses, all
+ IP multicast addresses have been mapped to a single Token-Ring
+ 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 be
+ noted that since there are only 31 possible functional addresses,
+ there may be other protocols that are assigned this functional
+ address as well. Therefore, just because a frame is sent to the
+ functional address 03-00-00-20-00-00 does not mean that it is an IP
+ multicast frame.
+
+
+
+
+
+
+
+Pusateri [Page 3]
+
+RFC 1469 IP Multicast over Token-Ring LANs June 1993
+
+
+Acknowledgments
+
+ The author would like to thank John Moy, Fred Baker, Steve Deering,
+ and Rob Enns for their review and constructive comments.
+
+References
+
+ [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 IP
+ 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 Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Thomas J. Pusateri
+ Consultant
+ 11820 Edgewater Ct.
+ Raleigh, NC 27614
+
+ EMail: pusateri@cs.duke.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pusateri [Page 4]
+ \ No newline at end of file