Slashdot Mirror
Harvard Offers Sneak Peek Into Their Network
Bob Brown writes "Harvard University doesn't usually talk much about its internal network, but here, the guy overseeing it opens up about the homegrown and commercial tools used to manage the massive system." From the article: "Harvard, as of late, has been exhibiting another telco trait - considering the network as part of the university's critical infrastructure. As such, its construction is considered during the initial planning phases of building renovation, new construction and campus expansion projects. The data networks that are being built today, at Harvard and similar institutions, are being built to host a variety of IP-based traffic. Most every physical-plant control device, whether it be security cameras, chilled water-valve actuators or parking garage card readers, are being designed to work with the IP network"
Off-topic?
I guess the moderator has no idea that MIT is two subway stops down the street from Harvard. Funny? Maybe, or maybe not. But not off-topic. Dumb moderator.
My favorite piece of network technology at Harvard is their system to shut off a student's WiFi network access when they have a scheduled class. :) Been in use for a while now, and it sure cut down on the kids at the back of the class yelling "PWNED YOU!" during a lecture.
Crimson brags about its class B address -- MIT has a class A! And if you look at the physical connection, last I heard the Harvard campus was served by a fiber strung along the MBTA Red Line tunnels -- straight from an MIT router!
--- Often in error; never in doubt!
What magical internet law dictates having a web server at hostname.com? And what other law dictates hostname.com resolve to an ip address? If anything, they are being pendantic, not sloppy.
Maybe I'm wrong, but I thought the point of the GP was that once the MIT students hear about it, the occurrences at Harvard of building lights blinking on and off or the temperature fluctuating wildly during the day would be non-stop.
Two things:
- you're confusing the servers and the network. The network is intended to be up 24/7 just like electricity and water, and it seems from the article that they do a pretty good job of this. This is also true of individual servers, but you're kidding yourself if you think that crashing the www.harvard.edu webserver, or cutting their internet access off, is also going to shut off the water. The water server is separate, and more importantly:
- the water valve actuator is not likely to be continuously controlled via its network connection. These kinds of building automation systems, which I have a bit of experience with, usually run under localized control. Their connection to the central system is for monitoring and sending new control instructions to the localized controller. The local controller can then run its program oblivious to the network, until new instructions arrive. If the network fails, it just keeps right on going, and if you really need to turn the water on or off, you can always send a live person to rotate the valve.
The point of the article is that they no longer allow these kinds of monitoring systems to be run over separate wiring and custom serial protocols -- it MUST be IP-based. Which is a good thing -- you want as few custom solutions as possible, especially when the existing network can handle the job just as well.
rfc states (don't rember which one, sorry) that hostname.com MUST point to an A. a CNAME is illegal.
it is also Good Practice to have an A record on your hostname. for legacy reasons. some mail systems will refuse to send and/or receive mail if the A is absent (although they may check for MX, there's no garantee)
Ummm, check with dig -- harvard.edu is not a "hostname" and only has SOA, NS, and MX records associated with it -- neither CNAME nor A.
It's not nearly as rosy a picture as is painted in the article. I've been working in IT at Harvard for quite a few years and until recently we've had too small of a budget with priorities on gadgets for VIPs and not regular infrastructure replacement. We're still in the dark ages in many ways.
Those custom apps he brags about? They break, are poorly documented, and we're in fact trying to move away from them as much as possible. Testing of major network changes is so poorly done as to be nonexistant in many cases. And let's not even get into the uptime of critical systems like email and webspace (those have been down for hours at a time, days in a row for week son end).
And those staff numbers? Inflated. We are really short-staffed.
A cold water valve actuator works very differently from your faucet in your ketchen, both in the mechanics and scale of flows.
Let me begin by pointing out the facts that most, if not all of the new industrial controls are trying to get on the IP based networking already. It is far cheaper to convert all different wiring and protocols (RS-232, RS-485, serial communication in general and Common and proprietery protocols like Modbus, ControlNet, etc.) and have them run over the TCP/IP network than having dedicated networks on all of those devices across a plant, or in this case, across the campus (and possibly multiple "plants."
TCP/IP network is scaleble, and second, it can be secured (with proper isolation and expertise). It is also transparent, i.e. multiple typs of physical wiring/connection scheme can be used. Other industrial protocols (yes, there IS a protocol involved in that actuator valve you mentioned, and so does other devices) often are either proprietary or are "narrow-band" type protocol designed to run across a serial cable. Running multiple networks on dedicated medium requires more wiring than single TCP/IP network. It also makes it difficult to do upgrade/equipment change-out in the future. When changing out industrial equipments down the road (we're talking about like 10 years later), technology changes, making it unreasonable to put up a wiring that will need to be changed.
In addition, there are usually limitations on the physical length of the wiring on the medium. Most protocols not based of TCP/IP model tends to be limited on the length on its own, requiring a repeater if it needs to travel longer distance (we're only talking about more than 250 ft). TCP/IP network, on the oter hand, has switches and routers in place, they act as the repeaters when needed. TCP/IP can also be run on fiber, expanding the distance a lot farther than traditional copper wires. Across the campus control with direct serial cable might work (RS-485, for those who are famaliar with them), but management cost is a lot higher today using pure serial wiring network than new "virtual" network resides on TCP/IP infrastructure. Signals can be re-routed without signigicant physical re-wiring as well.
Let's also talk a bit about the "why" we need to have the on that actuator valve connected to the network. Modern campus-wide (or plant wide) controls are monitored and done by a centralized control room. They monitor and issue commands to run the equipments to maximize the use of equipments while minize the cost of operation (wages = expansive cost). Actual machine controls(flow control, automatic safety switches) are done by PLC or other embedded devices on site. They are your field operators today! The commands are issues by the central Control Room to those controllers, and they in term control individual devices (pumps, valves, power breakers, you name it). If my descriptions does not convince you how complicated it can be, it is. To have dedicated control networks on those devices, which are not necessarily on the same protocols, especially not at one location, only add cost to the control system. It is better to "out-source" the transmission medium to a more transparant network platform and let the networking people to ensure its constant uptime.
I'm sure I do not have to mention the use of VOIP, audio/video, survalience (security) on the TCP/IP network. We already beat the subject to death.