Talk:DECnet

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by Networking task force.

http://it.slashdot.org/comments.pl?sid=155038&cid=12998126 http://it.slashdot.org/comments.pl?sid=155038&cid=12996714

Seems, that while Phase V was aimed to outperform Phase IV, results were doubtfull, if not just opposite :(

Quote from comp.os.vms Phase IV manuals

Gee, since phase IV is still used at plenty of sites. It's too bad it's considered "older". Why can't Compaq admit phase V is a bust and support the customers?

Isto Ylisirkka 08:01, 6 October 2005 (UTC)[reply]

MOP, layers, "proprietary"

MOP is not a network layer protocol. Its spec shows it in the "network management modules", which isn't really a layer (it's better viewed as something "to the side of" the regular stack.

DECnet was never viewed as an 8 layer model. It is a 7 layer model. I suspect the statement about "8 layers" is a misinterpretation of the picture in the Phase IV protocol specs; as I mentioned above, the "network management modules" shown in the structural model diagram isn't a layer in the OSI sense. In current terminology it would be part of the "control plane", and "to the side of" the data stack.

The use of the term "proprietary" is misleading. (See also Legitimacy of standards). While DECnet was developed by DEC, the specifications were available to all parties at no charge, and third party implementations were not just permitted but encouraged. Several companies did so, and for that matter there is at least one open source implementation (in Linux). Paul Koning 15:25, 23 March 2007 (UTC)[reply]

In particular, MOP is used by systems to request the download of an operating system from a server. So MOP is used before a system has DECnet loaded.

The confusion over network managment may come from a figure that was in some DEC documentation (it has the identifier TK-10223 in the lower right corner) showing layesrs in the implementation of the DECnet product. It shows network management routines in a network management layer, interfacing with the user layer NCP Utility and the network application layer session control module. It shows where the software is, not the layers of the model. In the model the "top" of network management "plane" is in the network application layer (the OSI model application layer).

Though the names are different, there is a one to one correspondence between DECnet IV and OSI model layers.

66.31.71.233 15:03, 25 October 2007 (UTC)[reply]

MOP has several purposes, one of which is download, which certainly happens before the OS is loaded. That doesn't matter, though. As far as DEC was concerned, the DECnet architecture is not just the transport and routing layers and all that, but also supporting components like MOP. They were all defined in the same organization (I worked there for some years and MOP was one of my responsibilities). Also, they were all controlled through a common mechanism -- NCP and the NICE protocol manage not just the main networking protocols but also the MOP services.

No, there is not a one to one correspondence between DECnet phase IV and the OSI reference model. The two models are similar but they don't line up like that. DECnet never included, and never wanted to include, a presentation layer. Paul Koning 18:00, 25 October 2007 (UTC)[reply]

Correct me if I'm wrong, but MOP is not based on DECnet, but talks directly on the ethernet. It has it's own protocol numbers assigned in ethernet. It don't have a object number assigned in DECnet, nor is it a named object. It isn't routed either. So, in which way is MOP a DECnet protocol? I'd say MOP is definitely in the same place as LAT. /Johnny Billquist (bqt@softjar.se) 212.112.174.82 (talk) 13:35, 8 April 2008 (UTC)[reply]

You're mixing up two things. "DECnet" is a collection of protocol specifications and products. A large part but not the only part of that is a WAN protocol stack similar to TCP/IP: the DECnet routing layer and NSP. But DECnet, as defined and described by DEC, also includes a number of other protocols that are not layered on the DECnet routing and transport layers. MOP is one such protocol. The Ethernet loopback protocol is another. They are all part of a collection of protocols developed and released together. Paul Koning (talk) 20:03, 8 April 2008 (UTC)[reply]

Router-less LAN operation?

The Ethernet implementation was unusual in that the software changed the physical address of the Ethernet interface on the network to AA-00-04-00-xx-yy where xx-yy reflected the DECnet network address of the host. This allowed router-less LAN operation because the LAN address could be deduced from the DECnet address

Changing the MAC address means that there is no need for a network-layer-address to link-layer-address mapping protocol, like ARP for IPv4. However this has nothing to do with routers. Royhills 12:22, 30 March 2007 (UTC)[reply]

That's partly true but there is more to the story than that. DECnet has hello messages, from which a network layer to data link layer address mapping table could be built. The "hiord" hack was implemented because of concern at the time that maintaining such a table would be too expensive. That probably was silly at the time, though perhaps plausible at least for PDP-11 based routers (which were the majority then). The other point, which does tie into the "routerless" issue, is that in DECnet only routers listen to "hello" messages; end nodes do not. So while routers could do the mapping between addresses, end nodes could not unless they also listen to hello messages and maintain a table of who is out there. The whole point of end nodes was to avoid having per-node state -- the very most we wanted to have was per-router state. After all, the smallest endnode implementation was RT-11, which would run comfortably on a 56 kbyte machine (that's for everything: DECnet, OS, application! Paul Koning 20:03, 30 March 2007 (UTC)[reply]

Hmm, no. Endnodes must also listen on hello messages, otherwise nothing would work. Endnodes listen to hello messages in order to find a router on the local ethernet, to which all messages should be sent. If several routers exist, the endnode will pick the one with the highest priority. So it don't keep any information on which one might be "closest" to whatever destination packets are going. So the endnodes keep it simple, but not *that* stupid, because that wouldn't work. One more detail, which I'm not sure if it was implemented on all architectures, but it definitely is in RSX, is that endnodes actually keeps tab of all machines on the local network, not just routers. Simple to do, and parts of this is required anyhow. The extra trick here is that if an RSX endnode wants to sent data to another machine, and it happens to be on the same segment, it will be sent directly to the destination without the use of a router. So the original comments stands (with modification). DECnet can work on ethernet without routers, but it's not really because of the layout of ethernet addresses, but because of the hello message scheme. The layout of the ethernet address is actually of rather limited use. What it helps, is that you don't need to store the whole MAC address to remember connectivity, but just the DECnet address. So it's a space saving device and nothing more. /Johnny Billquist 212.112.174.82 (talk) 13:35, 8 April 2008 (UTC)[reply]

There are two kinds of hello messages: hellos sent by the designated router (not by any other router) -- which are received by endnodes -- and hellos sent by endnodes -- which are received only by routers. So routers know all the endnodes, but endnodes do not know about other endnodes, only about routers. Note that the routers sort out who has the highest priority (the designated router) -- the endnodes don't know about router priority, they only hear from the winner.

An end node that wants to send a packet to another node does the following:

if there is a cache entry for the destination (which is created by incoming traffic from that address) send it according to the next hop of the cache entry
otherwise, if there is a designated router (a router hello has been received and hasn't timed out yet) send it there
otherwise, send it directly to the destination (using hiord plus the node address as destination Ethernet address)

So the key point is that endnodes know about exactly one router, plus some number of destination cache entries -- and furthermore, you can have routerless networks (single LAN network). Note that the destination cache is an optimization; the system works (at the cost of an extra hop some of the time) without the cache. Paul Koning (talk) 20:03, 8 April 2008 (UTC)[reply]

size?

How many nodes did it have in its heyday? Wasn't it one of the biggest world-wide networks in the 80s? Would be nice to have a diagram or some figures. Googling for "decnet size" only returns misspellings of "decent".--87.162.58.144 11:48, 28 August 2007 (UTC)[reply]

Your question seems to assume that "DECnet" is like "Internet" -- a single worldwide network. That is not the case. DECnet is (was) a product of DEC used by its customers to build networks for their use. Those would vary in size from a couple of nodes to many nodes.

I don't know how large the largest DECnet network was. It may be that the one used internally at DEC was, or it may be that others had bigger ones.

The internal DEC network certainly had thousands of nodes. I don't have any good records of what it looked like around the peak; does anyone else here? It certainly was using essentially all the available area numbers (63) and at least some of them were running low on node numbers. Come to think of it, I'm pretty sure that a utility known as "PMR" (Poor Man's Routing) was resurrected at some point to do the equivalent of NAT in the IP world. (Originally PMR was used to connect to nodes that didn't have Phase IV support.)

Paul Koning 14:27, 28 August 2007 (UTC)[reply]

One data point. In January of 1984 Eric Fair wrote that the DEC "Engineering Net" had "between 2000 and 2100 nodes". He also said "It is centrally controlled, semi-implicitly routed (they are converting from an explicit routing scheme)" which is a reference to PMR and the at that time incomplete transition to Phase IV.

It also mentions that DEC's internal network was at one time called the "Engineering Net" but that name was changed because it had become misleading. It was often called simply "E-net" but the official meaning you will find was "Easynet". I sent Google off to search for "dec enet" and "dec easynet".

Another data point: a 1992 book by John Slocum (the link is for a French translation) says that DEC's Easynet consists of "27,000 computers in 26 countries". And a 1990 interview in Network World (quoted in comp.arch says "DEC's Easynet: a 54,000 node internal network" Those numbers both look right to me as Easynet network sizes at various times when DEC was flourishing.

Paul Koning 14:46, 28 August 2007 (UTC)[reply]

DEC used more than 63 areas. To conserve adderess in each area, an area number was reserved for "hidden areas". A hidden area was only routed to the area it was directly connected to, so systems in other areas could not see it. This provided another 1023 addresses in each area. For example, a print server could be given an address in a hidden area, since people in other areas did not access to it.

The "E-net" was the Decnet network built and used by DEC Engineering. DECnet was used by other groups in the company but the networks were smaller and not interconnected. DECnet IV made it possible to interconnect them into one network which was called the "Easynet". This happened sometime in 1983.

66.31.71.233 12:58, 25 October 2007 (UTC)[reply]

Hidden areas is like NAT (though not as elegant). Yes, you're right, there were more than 63 areas in total. The addressing in the protocol of course is limited to 63 areas.

The original large DECnet network inside Digital was called the "Engineering Net". At some point it changed from an engineering resource into a corporate resource, so it needed a new neutral name. That name was "Easynet". "E-net" was never an official name, but the term was widely used at least in Engineering (where the name "Easynet" was considered a corporate intrusion into "our network"). Paul Koning 18:04, 25 October 2007 (UTC)[reply]

I included some of the above info in a new section, "Notable installations". -- HLachman (talk) 09:53, 19 August 2018 (UTC)[reply]

There is, ESnet, a US government run network with many DECnet hosts that would look similar to NSFnet, the beginning of the Internet. Many government and academic labs had one or the other, or both, and there were gateways to cross between them. You could e-mail from one to the other. Gah4 (talk) 19:27, 31 March 2020 (UTC)[reply]

ftp.digital.com

It seems that HP has retired the server that runs ftp.digital.com. The announcement can be found here: http://h18002.www1.hp.com/alphaserver/options/asgs1280/asgs1280_options.html

The ftp service is now inaccessible. The ftp.digital.com link at the bottom of this page should be replaced with another link that provides the same information if possible, or removed. Rilak (talk) 08:06, 28 February 2008 (UTC)[reply]

SPAN

Perhaps a mention of the DECNet based SPAN (Space Physics Analysis Network) is in order? --203.129.147.223 (talk) 01:38, 17 June 2008 (UTC)[reply]

I added the above in a new section, "Notable installations". -- HLachman (talk) 09:53, 19 August 2018 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on DECnet. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Corrected formatting/usage for http://sourceforge.net/apps/mediawiki/linux-decnet/index.php?title=Main_Page
Added archive https://web.archive.org/web/20110811153303/http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33 to https://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 22:35, 2 September 2017 (UTC)[reply]

addressing

Should there be mention of addressing, address space, and address size? I believe Phase IV is 32 bit addressing, but I don't see that anywhere. Gah4 (talk) 19:29, 31 March 2020 (UTC)[reply]

16 bit addresses in Phase IV, but you're right, that was not stated. Fixed. Paul Koning (talk) 14:42, 14 June 2023 (UTC)[reply]

Columbia University dead links

There are two dead links from Columbia University that I just fixed. This is strange, because the last successful crawl showed activity as recent as July 2022, yet the pages return a 404. I'm not sure what's going on here. Hamishmb (talk) 17:06, 3 August 2022 (UTC)[reply]

NB: Newly-dead but replaced links are: - https://www.columbia.edu/cu/computinghistory/ - https://www.columbia.edu/cu/computinghistory/dec20.html#networks

Replaced with: - https://web.archive.org/web/20220706001116/https://www.columbia.edu/cu/computinghistory/ - https://web.archive.org/web/20220707101822/https://www.columbia.edu/cu/computinghistory/dec20.html#networks

Hamishmb (talk) 17:08, 3 August 2022 (UTC)[reply]

Must've been a temporary glitch. The Columbia URLs are live now. I updated the refs with "url-status=live". -- HLachman (talk) 07:01, 1 July 2024 (UTC)[reply]

1982 BSD DECNET

DECNET for at least one of the 4.1c BSD variants exists "in the wild". ("varient" as in tapes with a "4.1 BSD" label sticker on them can have different contents as 4.1* BSD appears to have been some sort of "rolling release")

The DECNET code is also in the BSD SCCS version control archives Those SCCS archives were converted to the fossil version control system and available on online at Files in sys/deprecated/netdecnet/. Note that the "deprecated" directory is where it ended up after being in a "current" directory back in 1982. The same DECNET code is available on the CSRG ISO #1 in the directory 4.1c.1/sys/netdecnet. -- Jamplevia (talk) 01:47, 10 June 2023 (UTC)[reply]