home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1400s / rfc1469.txt < prev    next >
Text File  |  1993-06-14  |  8KB  |  227 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        T. Pusateri
  8. Request for Comments: 1469                                    Consultant
  9.                                                                June 1993
  10.  
  11.  
  12.             IP Multicast over Token-Ring Local Area Networks
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC specifies an IAB standards track protocol for the Internet
  17.    community, and requests discussion and suggestions for improvements.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document specifies a method for the transmission of IP multicast
  25.    datagrams over Token-Ring Local Area Networks.  Although an interim
  26.    solution has emerged and is currently being used, it is the intention
  27.    of this document to specify a more efficient means of transmission
  28.    using an assigned Token-Ring functional address.
  29.  
  30. Introduction
  31.  
  32.    IP multicasting provides a means of transmitting IP datagrams to a
  33.    group of hosts.  A group IP address is used as the destination
  34.    address in the IP datagram as documented in STD 5, RFC 1112 [1].
  35.    These group addresses, also referred to as Class D addresses, fall in
  36.    the range from 224.0.0.0 to 239.255.255.255.  A standard method of
  37.    mapping IP multicast addresses to media types such as ethernet and
  38.    fddi exist in [1] and RFC 1188 [2].  This document attempts to define
  39.    the mapping for an IP multicast address to the corresponding Token-
  40.    Ring MAC address.
  41.  
  42. Background
  43.  
  44.    The Token-Ring Network Architecture Reference [3] provides several
  45.    types of addressing mechanisms.  These include both individual
  46.    (unicast) and group addresses (multicast).  A special subtype of
  47.    group addresses are called functional addresses and are indicated by
  48.    a bit in the destination MAC address.  They were designed for widely
  49.    used functions such as ring monitoring, NETBIOS, Bridge, and Lan
  50.    Manager frames.  There are a limited number of functional addresses,
  51.    31 in all, and therefore several unrelated functions must share the
  52.    same functional address.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Pusateri                                                        [Page 1]
  59.  
  60. RFC 1469           IP Multicast over Token-Ring LANs           June 1993
  61.  
  62.  
  63.    It would be most desirable if Token-Ring could use the same mapping
  64.    as ethernet and fddi for IP multicast to hardware multicast
  65.    addressing.  However, current implementations of Token-Ring
  66.    controller chips cannot support this. To see why, we must first
  67.    examine the Destination MAC address format.
  68.  
  69. Destination Address Format
  70.  
  71.    The destination MAC address consists of six octets.  In the following
  72.    diagram of a MAC address, the order of transmission of the octets is
  73.    from top to bottom (octet 0 to octet 5), and the order of
  74.    transmission of the bits within each octet is from right to left (bit
  75.    0 to bit 7).  This is the so-called "canonical" bit order for IEEE
  76.    802.2 addresses.  Addresses supplied to or received from token ring
  77.    interfaces are usually laid out in memory with the bits of each octet
  78.    in the opposite order from that illustrated, i.e., with bit 0 in the
  79.    high-order (leftmost) position within the octet.
  80.  
  81.             7   6   5   4   3   2   1   0
  82.  
  83.           ---------------------------------
  84.           |   |   |   |   |   |   |U/L|I/G|       octet 0
  85.           ---------------------------------
  86.           |   |   |   |   |   |   |   |   |       octet 1
  87.           ---------------------------------
  88.           |   |   |   |   |   |   |   |FAI|       octet 2
  89.           ---------------------------------
  90.           |   |   |   |   |   |   |   |   |       octet 3
  91.           ---------------------------------
  92.           |   |   |   |   |   |   |   |   |       octet 4
  93.           ---------------------------------
  94.           |   |   |   |   |   |   |   |   |       octet 5
  95.           ---------------------------------
  96.  
  97.    The low order bit of the high order octet is called the I/G bit. It
  98.    signifies whether the address is an individual address (0) or a group
  99.    address (1). This is comparable to the multicast bit in the DIX
  100.    Ethernet addressing format.
  101.  
  102.    Bit position 1 of the high order octet, called the U/L bit, specifies
  103.    whether the address is universally administered (0) or locally
  104.    administered (1). Universally administered addresses are those
  105.    specified by a standards organization such as the IEEE.
  106.  
  107.    If the I/G bit is set to 1 and the U/L bit is 0, the address must be
  108.    a universally administered group address. If the I/G bit is 1 and the
  109.    U/L bit is a 1, the address may be either a local administered group
  110.    address or a functional address. This distinction is determined by
  111.  
  112.  
  113.  
  114. Pusateri                                                        [Page 2]
  115.  
  116. RFC 1469           IP Multicast over Token-Ring LANs           June 1993
  117.  
  118.  
  119.    the Functional Address Indicator (FAI) bit located in bit position 0
  120.    of octet 2.  If the FAI bit is 0, the address is considered a
  121.    functional address.  And if the FAI bit is 1, this indicates a
  122.    locally administered group address.
  123.  
  124.    Different functional addresses are made by setting one of the
  125.    remaining 31 bits in the address field. These bits include the 7
  126.    remaining bits in octet 2 as well as the 8 bits in octets 3, 4, and
  127.    5. It is not possible to create more functional addresses by setting
  128.    more than one of these bits at a time.
  129.  
  130.    Three methods exist for mapping between an IP multicast address and a
  131.    hardware address. These include:
  132.  
  133.       1.   The all rings broadcast address
  134.  
  135.       2.   The assigned functional address
  136.  
  137.       3.   The existing IEEE assigned IP Multicast group addresses
  138.  
  139.    In order to insure interoperability, all systems supporting IP
  140.    multicasting on each physical ring must agree on the hardware address
  141.    to be used. Therefore, the method used should be configurable on a
  142.    given interface.  Bridges may provide a means to translate between
  143.    different methods for each physical ring that is being bridged.
  144.    Method (3) is recommended but due to hardware limitations of Token-
  145.    Ring controller chips, may not be possible. In this case, Method (2)
  146.    is preferred over Method (1).  For backward compatibility, systems
  147.    that support (2) MUST also support (1). And systems that support (3)
  148.    MUST also support (2) and therefore (1).  In the absence of
  149.    configuration information, the default should be to use the assigned
  150.    functional address (2).
  151.  
  152. IP Multicast Functional Address
  153.  
  154.    Because there is a shortage of Token-Ring functional addresses, all
  155.    IP multicast addresses have been mapped to a single Token-Ring
  156.    functional address. In canonical form, this address is 03-00-00-20-
  157.    00-00.  In non-canonical form, it is C0-00-00-04-00-00.  It should be
  158.    noted that since there are only 31 possible functional addresses,
  159.    there may be other protocols that are assigned this functional
  160.    address as well.  Therefore, just because a frame is sent to the
  161.    functional address 03-00-00-20-00-00 does not mean that it is an IP
  162.    multicast frame.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Pusateri                                                        [Page 3]
  171.  
  172. RFC 1469           IP Multicast over Token-Ring LANs           June 1993
  173.  
  174.  
  175. Acknowledgments
  176.  
  177.    The author would like to thank John Moy, Fred Baker, Steve Deering,
  178.    and Rob Enns for their review and constructive comments.
  179.  
  180. References
  181.  
  182.    [1] Deering, S., "Host Extensions for IP Multicasting", STD 5,
  183.        RFC 1112, Stanford University, August 1989.
  184.  
  185.    [2] Katz, D., "A Proposed Standard for the Transmission of IP
  186.        Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET,
  187.        October 1990.
  188.  
  189.    [3] IBM Token-Ring Network, Architecture Reference, Publication SC30-
  190.        3374-02, Third Edition, (September, 1989).
  191.  
  192. Security Considerations
  193.  
  194.    Security issues are not discussed in this memo.
  195.  
  196. Author's  Address
  197.  
  198.    Thomas J. Pusateri
  199.    Consultant
  200.    11820 Edgewater Ct.
  201.    Raleigh, NC 27614
  202.  
  203.    EMail: pusateri@cs.duke.edu
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Pusateri                                                        [Page 4]
  227.