home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1469.txt < prev    next >
Text File  |  1996-05-07  |  8KB  |  126 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        T. Pusateri Request for Comments: 1469                                    Consultant                                                                June 1993 
  8.  
  9.              IP Multicast over Token-Ring Local Area Networks 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Abstract 
  16.  
  17.    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. 
  18.  
  19. Introduction 
  20.  
  21.    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. 
  22.  
  23. Background 
  24.  
  25.    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. 
  26.  
  27.  
  28.  
  29.  
  30.  
  31. Pusateri                                                        [Page 1] 
  32.  RFC 1469           IP Multicast over Token-Ring LANs           June 1993 
  33.  
  34.     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. 
  35.  
  36. Destination Address Format 
  37.  
  38.    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. 
  39.  
  40.             7   6   5   4   3   2   1   0 
  41.  
  42.           ---------------------------------           |   |   |   |   |   |   |U/L|I/G|       octet 0           ---------------------------------           |   |   |   |   |   |   |   |   |       octet 1           ---------------------------------           |   |   |   |   |   |   |   |FAI|       octet 2           ---------------------------------           |   |   |   |   |   |   |   |   |       octet 3           ---------------------------------           |   |   |   |   |   |   |   |   |       octet 4           ---------------------------------           |   |   |   |   |   |   |   |   |       octet 5           --------------------------------- 
  43.  
  44.    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. 
  45.  
  46.    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. 
  47.  
  48.    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 
  49.  
  50.  
  51.  
  52. Pusateri                                                        [Page 2] 
  53.  RFC 1469           IP Multicast over Token-Ring LANs           June 1993 
  54.  
  55.     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. 
  56.  
  57.    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. 
  58.  
  59.    Three methods exist for mapping between an IP multicast address and a    hardware address. These include: 
  60.  
  61.       1.   The all rings broadcast address 
  62.  
  63.       2.   The assigned functional address 
  64.  
  65.       3.   The existing IEEE assigned IP Multicast group addresses 
  66.  
  67.    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). 
  68.  
  69. IP Multicast Functional Address 
  70.  
  71.    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. 
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79. Pusateri                                                        [Page 3] 
  80.  RFC 1469           IP Multicast over Token-Ring LANs           June 1993 
  81.  
  82.  Acknowledgments 
  83.  
  84.    The author would like to thank John Moy, Fred Baker, Steve Deering,    and Rob Enns for their review and constructive comments. 
  85.  
  86. References 
  87.  
  88.    [1] Deering, S., "Host Extensions for IP Multicasting", STD 5,        RFC 1112, Stanford University, August 1989. 
  89.  
  90.    [2] Katz, D., "A Proposed Standard for the Transmission of IP        Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET,        October 1990. 
  91.  
  92.    [3] IBM Token-Ring Network, Architecture Reference, Publication SC30-        3374-02, Third Edition, (September, 1989). 
  93.  
  94. Security Considerations 
  95.  
  96.    Security issues are not discussed in this memo. 
  97.  
  98. Author's  Address 
  99.  
  100.    Thomas J. Pusateri    Consultant    11820 Edgewater Ct.    Raleigh, NC 27614 
  101.  
  102.    EMail: pusateri@cs.duke.edu 
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  Pusateri                                                        [Page 4] 
  125.  
  126.