Internet DRAFT - draft-pusateri-tokenring-lan


HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 10:58:06 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sun, 15 Nov 1992 04:39:00 GMT
ETag: "3dde51-20b9-2b05d464"
Accept-Ranges: bytes
Content-Length: 8377
Connection: close
Content-Type: text/plain

                                                             T. Pusateri
INTERNET DRAFT                                                Consultant
                                                           November 1992

            IP Multicast over Token-Ring Local Area Networks

Status of this Memo

   This document 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.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on,,,, or to learn the
   current status of any Internet Draft.


   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.


   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 RFC 1112 [1].  These
   group addresses, also referred to as Class D addresses, fall in the
   range from to  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.

Pusateri                                                        [Page 1]

RFC DRAFT                                                  November 1992


   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.

   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.  They are shown
   with the high order octet (octet 0) from top to bottom as they are
   transmitted but with the low order bit on the right (canonical
   order).  Each bit within an octet must be reversed before
   transmission on the media.  This format should be familiar to most
   members of the Internet community.

          |   |   |   |   |   |   |U/L|I/G|       octet 0

            7   6   5   4   3   2   1   0

          |   |   |   |   |   |   |   |   |       octet 1

          |   |   |   |   |   |   |   |FAI|       octet 2


          |   |   |   |   |   |   |   |   |       octet 5

Pusateri                                                        [Page 2]

RFC DRAFT                                                  November 1992

   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.

   If the I/G bit is set to 1 for a group address, 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
   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.

   There exists three methods 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 multi-
   casting 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).

Pusateri                                                        [Page 3]

RFC DRAFT                                                  November 1992

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 func-
   tional 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.


   The author would like to thank John Moy, Fred Baker, and Rob Enns for
   their review and constructive comments.

Author's  Address:

   Thomas J. Pusateri
   11820 Edgewater Ct.
   Raleigh, NC 27614


[1]  S. Deering, Host Extensions for IP Multicasting, Internet Working
     Group Request for Comments 1112.  Network Information Center, SRI
     International, Menlo Park, California, (Aug, 1989).

[2]  D. Katz, A Proposed Standard for the Transmission of IP Datagrams
     over FDDI Networks, Internet Working Group Request for Comments
     1188.  Network Information Center, SRI International, Menlo Park,
     California, (Oct, 1990).

[3]  IBM Token-Ring Network, Architecture Reference, Publication SC30-
     3374-02, Third Edition, (September, 1989).

Pusateri                                                        [Page 4]