[comp.protocols.iso] ES-IS Resolved

cmilono@netcom.COM (Carlo Milono) (05/24/91)

In article <1991May23.111104.21693@sinix.UUCP> df15@sinix.UUCP (Herr Lackinger) writes:
>In article <1991May10.045134.21142@netcom.COM> cmilono@netcom.COM (Carlo Milono) writes:
>>
>> I am looking for the actual Pseudo-MAC addresses for a TP4 imnplementation
>>for the ES.IS-ES Group Multicast and the ES.IS-IS Group Multicast.  I 
>>understand that there was a TOP/NetBIOS discussion that got blessed by
>>the NIST on this regard, but have yet to find any paper documention on
>>this subject.  I need help!
>>
>>Here is what I found:
>>
>>IS-ES: 09002b000004
>>
>>but my router thinks differently!  I found it wants:
>>IS-ES: 030000000200 (cisco...)
>>
>EWOS Document 008 (ED008) states in 6.2.1.16 (Page 13)
>
>all ES: 1001 0000 0000 0000 1101 0100 0000 0000 0000 0010 0000 (09002b000004)
>all IS: 1001 0000 0000 0000 1101 0100 0000 0000 0000 1010 0000 (09002b000005)
>
>Heinz Rudolf  Siemens Nixdorf STO NC154

Ah, I have found several references that back-up these standards - ahem, 
however...I failed to mention (because I didn't think it was an issue)
that I was attempting to route over Token Ring, which uses FUNCTIONAL
Addresses rather than multicast.

I found references to the addresses in:

1988 NIST agreement (which reversed IS and ES addresses)
AT&T documentation (the addresses for csma come from their bank of numbers)
TOP/NetBIOS Working Group of the MAP/TOP committee

Basically, 'cisco' made a boo-boo in several ways:
1) all standards related to these addresses state that they must be
   CONFIGURABLE (PROMS do *not* count!)
2) in some cases, the 4th and 5th octets were reversed - in others it is
   inexplicable where they got the numbers.....

A fix is on the way (OH, how I wish I didn't have to deal with TR!).

-- 
+--------------------------------------------------------------------------+
|                   Carlo Milono                                           |
|    Personal:    cmilono@netcom.com   or   apple!netcom!cmilono           |
| Hobbes: "Life in the Great Suburban Outback is certainly fraught with    |
|          peril."                                                         |
| Calvin: "If you'd seen it, you'd have been scared too."                  |
+--------------------------------------------------------------------------+

mckellar@pinocchio.encore.com (Steve McKellar) (05/28/91)

In article <1991May24.031145.948@netcom.COM> cmilono@netcom.COM (Carlo Milono)
writes:

> Ah, I have found several references that back-up these standards - ahem, 
> however...I failed to mention (because I didn't think it was an issue)
> that I was attempting to route over Token Ring, which uses FUNCTIONAL
> Addresses rather than multicast.

um, could someone explain - or point to an explanation - of FUNCTIONAL
addresses? what they are, how they're used, etc. thanks.


steve mckellar

mitton@enet.dec.com (Dave Mitton) (05/29/91)

>From: mckellar@pinocchio.encore.com (Steve McKellar)
>Newsgroups: comp.protocols.iso,comp.protocols.iso.dev-environ
>Subject: Re: ES-IS Resolved (Token Ring!)
>Date: 28 May 91 14:34:30 GMT
>Reply-To: mckellar@pinocchio.encore.com (Steve McKellar)

>
>In article <1991May24.031145.948@netcom.COM> cmilono@netcom.COM (Carlo Milono)
>writes:
>
>> Ah, I have found several references that back-up these standards - ahem, 
>> however...I failed to mention (because I didn't think it was an issue)
>> that I was attempting to route over Token Ring, which uses FUNCTIONAL
>> Addresses rather than multicast.
>
>um, could someone explain - or point to an explanation - of FUNCTIONAL
>addresses? what they are, how they're used, etc. thanks.
>
>
>steve mckellar

Sure!
	A Functional Address is an 802.5/Token Ring unique concept.
It is a set of Locally Administered space Group (aka Multicast) addresses
of the form:  (using IBM big-endian format)

	11000000:00000000:0uuuuuuu:uuuuurrr:iiiiiiia:iiiaaiaa
        GL-----mbz--------F

where each of the lettered bits are intended to be used as a bit mask value
instead of a unique binary value.

The IEEE 802.5 std. does not further divide them, but the IBM Arch Specs
call out the lower bits as "Reserved to IBM" and the upper bits as "User
assignable".   I have indicated with "i" known IBM uses of FAs.  The
"a" bits are assigned by the standard to ring functions and bridging.


WRT to the cisco topic that started this discussion: 

	Current implementations of Token Ring data link chips are incapable of
receiving the assigned multicast addresses for ISO ES-IS,  therefore NIST
in cooperation with IBM has assigned Functional Address bits for use by ES-IS 
routers and end stations.
	This of course, creates another Token Ring to Ethernet interoperability
issue for bridges.

	Dave Mitton.
	Digital Equipment Corp.