RFC1469 IP Multicast over Token-Ring Local Area Networks

1469 IP Multicast over Token-Ring Local Area Networks. T. Pusateri. June 1993. (Format: TXT=8189 bytes) (Status: HISTORIC)

日本語訳
RFC一覧

参照

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






















一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ドメイン指定受信設定のURL

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る