Re: Multicast IP and FDDI

Steve Deering <deering@pescadero.stanford.edu> Fri, 02 February 1990 04:54 UTC

Received: from merit.edu by NRI.NRI.Reston.VA.US id aa03210; 1 Feb 90 23:54 EST
Received: Thu, 1 Feb 90 23:56:17 EST from Pescadero.Stanford.EDU by merit.edu (5.59/1.6)
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA03534; Thu, 1 Feb 90 20:56:12 PDT
Date: Thu, 01 Feb 1990 20:24:00 -0000
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: Multicast IP and FDDI
To: Dave Katz <katz@merit.edu>
Cc: fddi@merit.edu
Message-Id: <90/02/01
In-Reply-To: Dave Katz's message of Wed, 31 Jan 90 005033 EST
Status: O

>	My preference would be for this information to be in the Multicast
>	RFCs instead (with inclusion by reference, as now).

I don't think that's the right approach.  The multicast RFC specifies
the subnetwork-independent aspects of IP multicasting.  It specifies an
Ethernet mapping as an *example*, but cannot be expected to specify the
subnetwork specifics for all possible subnetworks.  That is supposed to
be the role of the various IP-over-<whatever> documents, such as
IP-over-FDDI.

Granted, there are several different types of LAN that use Ethernet/802.2
style addresses, all of which should use the same multicast mapping.
That means there will be some duplication among the IP-over-<whatever>
documents for those LANs, but that doesn't seem particular serious to
me.  They already duplicate other info.

>	If this isn't feasible, then I would like to boil it down to a
>	sentence or two pointing out the canonical ordering.

Seems to me it would be better to give too much detail rather than too
little, given the potential for confusion created by the FDDI bit-order
mess.  But if you insist, here's a more compact version:

	The mapping from IP multicast address to FDDI group address
	is done in canonical bit order.  For example, the IP multicast
	address 224.255.0.2 maps to the canonical FDDI group address
	01-00-5E-7F-00-02.

Steve