Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!ucbvax!CISCO.COM!cire From: cire@CISCO.COM (cire|eric) Newsgroups: comp.protocols.tcp-ip Subject: DecNet on TR Message-ID: <8908100159.AA18417@ucbvax.Berkeley.EDU> Date: 10 Aug 89 00:27:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 85 I know this is perhaps blasphemous so I'll put on my asbestos suit. As far as I know the only media that DecNet currently runs over is serial lines and ethernet. Are there other media that DecNet is being implemented on? In particular are there other implementations of DecNet on Token Ring? I know that Sun has a Token Ring interface and Apple is working on one. Both of these folks have some form of potential relationship with DecNet. So there is some likelihood that it is being worked on. Cisco has a DecNet on Token Ring implementation and we would certainly like to have it play with the other kids on the block. I've run into a number of interesting little details that would need to be agreed on to accomplish this. 1) Ethernet DecNet interfaces set their hardware address to AA00.0400.xxxx (where xxxx is determined by area.node). This can not be used by Token Ring interfaces because it is a Token Ring non-specific address. One possibility is to bit swap all the bytes of the address. This is the recommended practice given by IEEE. So the address becomes 5500.2000.yyyy. Note that AA on ether and 55 on Token Ring are both Locally Administered addresses. This is important. The choice isn't particularly important as long as it is agreed on. One other significant detail on this choice is whether we want this stuff to operate reasonably over transparent Token Ring-Ethernet bridges. If so then the bit swap is probably the way to go. I say probably because there are significant technical details that would need to be solved for such an thing to exist. Primarily because of the bit ordering problems. These are significant. I'd recommend that we don't worry about Ether to Token Ring transparent bridging. 2) DecNet on Ethernet also uses two multicast address for talking to all Nodes and all Routers on this cable. All Token Ring hardware I've seen and all hardware based either on the IBM chipset or TI chipset only support a single multicast address (called the Group address, not to be confused with the Group bit). Common practice I've seen on Token Ring so far is to use what is called a Functional address. A Functional address is a bit significant address. Two bits would have to be chosen that don't conflict with other uses of the Functional addresses. Currently the following are the ones that seem to have gained some solidity: NOVELL C000.0080.0000 CLNS ESIS all IS C000.0010.0000 CLNS ESIS all ES C000.0008.0000 all Bridges C000.0000.0100 ** NETBIOS C000.0000.0080 Config Rpt. Server C000.0000.0010 * a.k.a. Lan Manager Ring Error Monitor C000.0000.0008 * Ring Parameter Srv C000.0000.0002 * Active Monitor C000.0000.0001 * * = from standard IEEE 802.5 ** = from draft standard IEEE 802.5D (for review only) Note that there isn't as far as I know any central authority that has responsibility for these bits other than some of the lower ones. Those have been set by IEEE and earlier IBM. The other bits appear to be up for grabs. Like the address in point 1 above, which two bits chosen need to be agreed on for interoperability. Comments? Also if there is a better place to post this kind of message please feel free to inform me. I would say this list has the largest readership of folks interested in interoperability issues that I know of. thanks for you time, -c cire|eric Eric B. Decker Token Ring Development cisco Systems - engineering Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941