TechTalks Transcript
Network Management and the Future
 Judith Boettcher [JB] |
 Jeff Ogden [JO] |
 Ken Klingenstein [KK] |
February 11, 1998
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB Welcome to the CREN Virtual Seminar Expert Series for Spring of 1998 on Campus Communications Strategies. Whether you are joining us by phone or on the Internet, you are here because it's time. This is Judith Boettcher of CREN, one of your hosts for today's session, and today's co-host is Jeff Ogden from MERIT. Jeff is standing in for Greg Marks. Jeff is an associate director at MERIT, focusing on the Internet. Thanks for being here today, Jeff.
JO Glad to be here. This is my first session, and I'm looking forward to it.
JB All right, great. And as expected, our guest expert today is Ken Klingenstein, the Director of Information Technology Services at the University of Colorado at Boulder. Ken has been a leader in national networking since 1985, since very serious networking got under way. He is currently a member of the CREN Board and a member of the Internet 2 Working Group on Quality of Service. We will be talking with Ken today about two areas: first about the overall status of national networks today and where they are going, and then about the tools and best practices for managing networks. Thanks much for being here today, Ken. You know, it's amazing to think about the huge impact networks are having on everything we do, and yet at the same time, network managers often have very different experiences with managing networks and the expectations of their clients. In fact, you suggested that our title today might be "A Manic Depressive View of Network Management." Would you like to tell us how you came to that conclusion?
KK Well,-�
JB Do you remember that?
KK I do, and I guess I'd like to say that one other advantage of virtual seminars is that I can sit here and eat my lunch and not offend anybody along the way. So if you hear a chomp every once in a while, just understand that it's an apple in the background.
JB We'll check how that does with the audio (inaudible).
KK Yeah, that manic depressive insight that was made even before today, which reiterated to me that life is certainly manic depressive. I think part of the bipolar nature, which maybe is a more apt term. I don't know how depressed we'll be at the end of all of this stuff, or manic. But we're being asked to do lots of new things and it's very hard to get rid of the old stuff. So, for example, we're all needing to begin to think about Internet 2 and its consequences on campuses, and the infrastructure that it's going to require. At the same time, Internet 1 is certainly very important to all of us, increasingly important. And so we have to pay attention to those sets of needs as well. I think the bipolar nature of all this is reflected to some degree in the fact that we're starting to run many different kinds of media; that when we add fiber to the desktop, we don't get rid of copper; that when we add wireless to our mix, we don't get rid of wired. Similarly, many of us are building multiple backbones on our campus, and we can't get rid of the old stuff even as we do the new stuff. So pretty widely across the horizon, the diversity of what we have to deal with increases, and so we wind up focusing our attention in more than one area.
JB You know, that's an interesting analogy I might offer at this time. As you know, we keep thinking that when VCR's came out, that movies would go away, or when videotapes came out, that audiotapes would go away. And we just keep accumulating everything.
KK Right. I think that increasingly the right answer's going to be "all of the above."
JB Interesting. Jeff, before we go on, would you like to review for folks how the Tech Talk work and how they might join in?
JO Sure. People should remember that there's really two ways you can participate in one of the Tech Talk. One is by actually calling a phone number and joining this telephone conference. That will allow you to participate directly. The phone number to call is area code 734, 647-2803. Or, you can listen to the event on the Internet using real audio. There's a two step process from a link on the CREN homepage. The CREN homepage is www.cren.net. For those of you who are joining in, you can send a e-mail message to the address ccs@cren.net. That will let folks know that you're listening in, and you can also send in questions that way.
JB Okay, very good, Jeff. Do we have someone joining in?
DP Yes, I just joined. Don Porter from RPI.
JB Hi, Don. Welcome. Just jump in when you have a question to ask, or did you have one major one that you wanted to ask Ken right now?
KK Or Don, if you have an answer, we'll take those too!
JB Or an answer. Thank you for reminding me of that.
DP My question was, I was trying to get there on the real audio link and I'm not succeeding.
JB Okay.
JO A hard question! Hold on for a second.
JB. Jeff is going to take that one, I think, Don, and hopefully get back to you on that. Okay?
JO I'm receiving the real audio link at this end, so it seems to be working in general. You might want to just take a step back and try again from the beginning. I did attach from the CREN page.
DP Okay. I was going off of the e-mail message, so maybe I should start back at a different point.
JB Yes, go ahead and start at the CREN homepage and then follow the Expert Event link, and that should hopefully work. But let us know if it doesn't.
DP Okay.
JB Ken, let's go ahead and get into some of our questions for today. One of the questions that everyone really wants to know about is just what is the general, overall health of our networks? We keep seeing the numbers on the tremendous growth and the addition of new people onto the Net. How are we doing?
KK Well, if you do things at the right time of day, from the right spot, life is okay. I would, I guess, characterize today's Internet as having a very strong basal metabolism, but it's riddled with diseases, and it manages to survive and prosper indeed despite having lots and lots of things that are broken about it. To give you a sense of some of the things that are broken, there are two major exchange points for traffic between different ISP's, one in the DC area called Mae East and one in the west called Mae West. And Mae East in particular experiences, during congested periods, one out of every three packets may get dropped across that environment, which is just a spectacular disaster. And because of that, a number of ISP's have built private piering points where, for example, MCI and Sprint can exchange traffic without going through these common exchange points.
One of the side effects, by the way, of the private exchange points is that you can begin to exclude traffic and build an oligarchy of just a few service providers. I won't get into the politics of that, but that still (inaudible) the condition of Mae East as an example.
Some of the backbones are fairly congested, but people are adding significant bandwidth. The problem tends to be that we have more bandwidth than the routers along the way can handle. Then when you start to look down at a more fine grain, you find other kinds of problems. You find what are called "mice packets," packets that are only 40 bytes long, and it turns out that about a third of the network traffic at this point, maybe a little bit less, are mice. And what mice are indicative of are protocols that either didn't age well or other problems.
For example, when you type something with a TelNet command, the question comes up, "Who should echo that character?" Well, the way most TelNet commands do work is that each character goes off as an individual packet and then gets echoed by the far machine back as the same character coming back. So some percentage of those mice packets out there today are in fact the one-character exchanges that happen as you type a line of text.
Another kind of mice packet is a large number of acknowledgments going pack that are not piggybacked. Processes that are spewing large amounts of data, particularly Web processes, want acknowledgments that these are being received, and the acknowledgment is coming back in an otherwise empty packet.
So there's a lot of traffic out there that are short packets, and short packets don't take up a lot of bandwidth. But a short packet requires as much processing by a router as a long packet does, for somewhat less payload. So routers get hurt by the mice packets that are out there. I can go on and talk about routing flaps, too.
JO Ken, just let me interject a question if I might. We talked about a disease on the Internet. Is this the sort of disease that's a skin rash, that might be hard to get rid of and we just live with, or is this the sort of disease that's like a broken arm, and we hope that we can get the arm set, and after a while we'll be better?
KK We're going to break this analogy, Jeff, I'm sure!
JO I realize we're pushing it a little hard already.
KK I would guess that mice packets are an example of skin rashes in that, in fact, they're going to come and go. We won't be particularly successful, that the problem is in some sense the upper level applications are not as network oriented as they need to be. The case of routing flaps, where a route between two locations changes sometimes as many as ten times in a second is another problem that maybe is more of a broken arm in that it is a bad thing, and it is something that we can remedy by fixing our routing protocols and ignoring a lot of the stray noise that comes in. A lot of these routing flaps are not lines coming up or down and not being responsive to congestion surges that may suggest alternative routes. But the routing flaps are from machines that aren't authorized to speak for an environment speaking for an environment and claiming that the best way to get to all of the University of Michigan's machines is to go through the PC on my desk. And those kinds of routing problems, those routing flaps are stuff that we really need to work on as a business and an industry.
JB Ken, let's just do a couple process things. Do we have another person joining us?
NH Yes, this is Neil Hodges, South Dakota School of Science and Technology.
JB Hi, Neil.
NH I tried coming in over the Web, but sounds like you're going through a meat grinder. Access leaving the state isn't real good this year.
JO So perhaps this is an example of what we were just talking about.
NH Yeah, but then you've got government mixed in!
JO Okay.
KK Is government a skin rash or a broken arm?
JO Don't have the answer to that one.
NH The Plague of Death?
JB Okay. So, Ken, do you want to address that?
KK No, I don't want to address that one, actually.
JB Okay. Well, Neil, why don't you just hang in there with us on the phone today, then.
NH Thank you very much.
JB Ken, let's go back to those routing flaps for just a moment. For some of us who might not be familiar with that term, would you mind going into just a little more detail on what a routing flap is?
KK Yeah. Typically what happens is that a route is set up to carry all of the packets in a particular flow, let's say between some process running on a machine at MIT and a process running on a machine at Cal San Luis Obispo. And then one of the intermediate ISP's that is carrying part of that traffic decides that it has a better route to Cal San Luis, and so it changes the route in mid-flow, and then it decides, "Oh! I guess it wasn't a better route after all!' and changes back, and then changes again. One of the things that winds up happening here is that the router spends more of its time figuring out what are the proper paths then actually passing the packets and traffic that it's supposed to pass. A second problem that arises from routing flaps is that the packets stand greater likelihood of arriving out of sequence because they're going along differing routes, and that makes the reassembly of the packets more challenging. It means you need more buffers on your host to store packets that might arrive out of sequence.
JB Okay. All right, good.
JO. One other thing to say is, it's not just the routers that are carrying the packets from MIT out to California, but the routing information that has to get updated has to get updated in thousands of routers all over the world, potentially. So it's not an isolated problem just in one little place.
JB. Ken, you said that was a problem that really did need some attention and hopefully that is going to be part of what Internet2 will be looking at?
KK Well, Internet2 is certainly looking at routing issues, but not these particular ones. For Internet2, where routing becomes fairly important is that on a high-speed line, you tend to have a large number of packets in flight. And packets in flight represent memory that you need to have in place at the receiving end, because those packets may arrive out of order. It also means that if you want to slow down a connection because it's overwhelming the receiver, you have so many packets in flight that by the time you get the BE QUIET back to the sender, you've already overwhelmed the receiver. So one of the things that Internet2 is looking at is making the routing topologically sensitive, in some sense to reduce the physical distance of the paths that packets are taking. And if you reduce the physical distance, you reduce the number of packets in flight because it's just a shorter flight plan. And so one of the things that Internet2 is looking at is how can routing paths reflect the shortest distance between two locations?
JB Jeff, do you want to ask Ken about backbone strategies for our campuses?
JO I guess it would be reasonable, as we talk about this bipolar nature of our worlds. What are the strategies for someone on a campus who needs to support their existing users, but perhaps Internet2 users at the same time?
KK Well, I think the University of Colorado serves as a--I can't say if it's a good or a bad example--of multiple backbones. We have, in fact, three campus backbones today. We have the legacy Ethernet that we started many years ago. We have a FIDI backbone that, over the years, has grown to connect many of the major traffic points on campus together, and the FIDI provides not only higher bandwidth, but it is much better in congestion than Ethernet. Ethernet in congestion is known to swoon dramatically as the load picks up. And then we have a third ATM network that we use to deliver truly high performance to a very limited number of desktops. I've heard another very interesting example of multiple backbones from the University of California at Berkeley, where in the process of wiring all of their dormitories and providing network access, there was a concern that the dormitory traffic not overwhelm the scholarly traffic being generated in the labs and offices of faculty. And so what Berkeley did was to run a second backbone to all of the dormitories, and that backbone meets the rest of the campus traffic only at the gateway router. And then at that gateway router, there is the ability to cap the dormitory traffic. And so there's a constraint there on the fact that they will use no more than x% of the overall external bandwidth being purchased by Berkeley.
JB Interesting strategy.
KK Right. And typically when you run multiple backbones, you may wind up with multiple pricing structures, depending upon the classes of service that you are delivering. I should point out one or two negative aspects of multiple backbones. First of all, it is highly fiber consumptive. Especially for the inter-building fiber plants, each backbone will require its own separate strands. There's a variation that you can do on that which is to do ATM as the fundamental structure, and then partition backbones as sub-channels of ATM, and that saves you some of the fiber, but at the cost of having to deploy that ATM switching structure. That leads to a second negative aspect of multiple backbones, which is conservation of technologies, that you're asking the technical staff at this point to support not only Ethernets and FIDI's, but also ATM and it's differences in training, it's differences in diagnostic tools, differences even in wire splicers and other mundane physical tools. So you need to be a little cautious in getting into multiple backbone philosophies, recognizing that you'd better have the fiber plant and you'd better have the technical staff that can support diversity.
JO Ken, it sounds as if we are heading towards a world in which, instead of one-size-fits-all, we've got perhaps the fast backbone and the older, slower backbone?
KK Um-hum.
JO What do you say to the faculty member who you attach to the older, slower backbone who really wants to be on the new, faster backbone?
KK Well, I'll tell you what I want to say to them, which is, "You pays the money and you gets the freight." On the other hand, one of the cruel ironies of Internet 2 as it begins to unfold via the VBNS is that much of this is being financed on the basis of serving scholarly research, and so those people feel like they helped write the grant that brought in the VBNS, and so therefore they deserve free access. In fact, that is the situation, and here the University of Colorado truly is serving as a bad example. We charge, I think it's $12 a month for some old asynchronous ISN-based switching. We charge $3 a month for Ethernet access, and the 155 megabit ATM service is free. And in fact, in that line of thought, when we get up to 622 megabits, we'll have to pay the users.
JO That's a good plan!
JB You're into making users happy.
KK Yeah. One of the other problems that arises in this is that the (inaudible) of a desktop or a variety of speeds becomes very, very hard. And there's been a reasonable amount of discussion about how you take TCP and work with the buffers and the time apps that are implicit in TCP when you're sometimes going to be going across a network that has T1 or Ethernet response and sometimes 155 megabit response. In one case, you won't time out soon enough. In the other case, you won't be able to sustain true 155 megabit performance because your time outs aren't occurring in the right time frames. That turns out to be a very hard problem at this point, and when people talk about orders of magnitude and how it might make us bipolar, it isn't so much that things are getting fast as that there is a greater variation between the highs and the lows. And it's that diversity of performance that makes life so hard. If everything was 155 megabits, we'll tune it for that. It's when you go and have to cope with T1's as well as 115's that life becomes very, very complicated.
JO How does my dial-in user at 33.6 kilobits fit into this puzzle? I expect it makes it harder.
KK Or the one at 2400 baud.
JB Hopefully we don't have many of those left.
KK Certainly not listening to real audio. Those are very tough situations. Again, if you're always on a fixed network speed, we'll tell you how to tune for that. But typically, you sitting at your desktop will go to one place that has high performance and then another place where somewhere along the way, you cross an Ethernet, and so that becomes the gating performance factor, and despite the fact that you may have left your campus at 155 megabits and may have traversed across the MCI backbone at 155 megabits, you're not going to get anything better than a motley Ethernet speed, and you want to be tuned for that parameter.
JO So it's the weakest link in the chain.
KK Um-hum. Indeed.
JB Maybe it's a good time to stop and ask whether any of our other participants have a question at this point? Who do we have on the line, please?
JC Hello, this is Joel Cohen from (inaudible) College.
JB Hi, Joel. Did you have a question?
JC No, I was a lurker.
KK Do you have any answers, Joel?
JC And a late lurker, besides.
JB Well, welcome to it. Perhaps, Ken, another question that does come up is what about long and short term planning for networks, particularly on campus? Campuses wish they were often faced with occasionally getting a big pot of money, and then having to "go fix the problem," right? And without many expectations of having additional money. Any advice for someone in that kind of situation?
KK Well, you know, before I get into the details of advice, there are very few things in life that are really just one-time expenses, and I think we have an educational process to go through so that our management understands that everything is a gift that keeps on giving, and that we have to pay attention to that.
That said, if a patent comes through and the school is temporarily wealthy, I'd certainly begin with fiber in the ground. You'll never have too much of that. And a mix of single-mode and multi-mode, but I think single mode is more or less carrying the day. Vertical fiber within buildings is often very hard to do. That's where you have to get out the core drill and worry about the asbestos and worry about the fact that a building is a historic site, so you need 19 signatures before you run a piece of conduit. Those are good one-time expenses.
I think that running fiber to the desktop is less certain, that it's very attractive in terms of at least you're deploying what we think of as the final media, but today, by and large, to put electronics on that fiber is very expensive. Typically, what you're trying to do is often slow down the data rate of the fiber to a rate like Ethernet that a PC can cope with, so you're trying to take a drink out of a fire hose. That's a tough thing to do, and up till about three months ago, it was significantly more expensive to run Ethernet across fiber than it was to run Ethernet across twisted pair.
I saw something that I think Doug Gale from George Washington University can talk about, some fiber adapters that were on the order of $100 to $200 that looked like they could run Ethernet. Because remember, the cards in the machine on the desktops are Ethernet and are still going to be Ethernet for quite some time to come. There were some other advantages, by the way, of running fiber to the desktop that Doug revealed in terms of management in that when you run fiber, you say that's your standard networking offering, that you tend to remove some of the ad hoc networking that departments may do because the campus standard is now fiber and few people have that expertise. But fiber to the desktop, at the University of Colorado when we looked two years ago, it was $800 a port of electronics to do Ethernet, and what we were giving people was exactly the same service as we would have done on twisted pairs, so we had to subsidize that difference in order to get people to think about installing the right media. And that's an expensive subsidy.
One last investment that is likely worthwhile is to move from shared Ethernet hubs to switched Ethernet, that providing ten megabits to the desktop has two benefits. One is that most switched Ethernet hubs give you a much better security mechanism than the broadcast style of shared hubs, and secondly, it looks like for the applications that we understand today and for the computers that we have today, that ten megabits to the desktop will likely be sufficient for a good number of years. I say that and immediately worry about the killer app I haven't seen. But what I've seen in combining video at 384 kilobits a second with voice at 64 kilobits a second, combined with some data services at max one to two megabits per second. If that's what you're doing to the desktop, that fits fairly comfortably inside a ten megabit service, and if you start to talk about new applications, we start to talk about the human as the limiting function. And how many things can you do simultaneously? And if the answer is just two or three, then it's likely that ten megabits will suit you fine for a while.
JO Ken, do you want to say anything about the difference between ten megabit Ethernet, plain old Ethernet, versus fast Ethernet, 100 megabits, versus the discussions about gigabit Ethernets? It all sounds great. It all sounds like Ethernets should make my life easy, right?
KK That's another one of "You gets what you pay for." The management capabilities of Ethernet tend to be fairly limited, and we moved up to routers and other kinds of higher level protocol devices for management capabilities. That said, fast Ethernet certainly is an attractive offering. It seems to be better than FIDI for a lot of purposes, and let's understand here that we are the tail on the vendor dog and that it's the kinds of cards that are in the boxes that our faculty are buying that's going to determine our networking strategy. And so when boxes get shipped with ATM cards or fast Ethernet cards, then that tends to dictate what services we need to provide. Many boxes are coming out now with 10/100 switchable cards for Ethernet, so fast Ethernet is becoming fairly attractive.
The price you pay there is modest in that your driving distance tends to get highly constrained in fast Ethernet, and that adds a subtle, hidden cost of intermediate phone closets and intermediate wiring hubs, and those intermediate wiring hubs need electricity and air conditioning. So there's a hidden cost when you reduce driving distance in terms of physical facilities. We just ran into a situation where the only place we could put the wiring hub was in the hallway, and so we had to build a closet in the hallway, and that made the hallway too narrow for fire code, tra la la la la la la la la la. When you stop and think about gigabit Ethernet, there I start to get more concerned about that as a desktop technology. I think gigabit Ethernet may be something that we use in machine rooms and in major switching locations, but when you try to run things at a gigabit, your driving distance drops precipitously. And your susceptibility to electronic noise, be it fluorescent lamps or diathermy machines, becomes much greater. And so I don't know that gigabit Ethernet will make it as a desktop technology. I do know that I've not seen a computer that could handle a gigabit worth of data coming in.
JO Okay, if 100 megabits is within my reach on Ethernet, and a gigabit is maybe a little risky or maybe something that I can't even really use very well, what options do I have been 100 -- I need to go faster than 100 for some particular application, but I don't need to go up to a gigabit. What can I do?
KK First you can ask the hard question about will the application really respond to faster speeds with faster performance? There's a pretty good analysis done just looking at the header overhead of running ATM service at 155 megabits, and when you start to look at the overhead introduced by the IP layer, by the TCP layer, by the ATM headers, the best you can hope for out of 155 megabits being presented to the application layer is about 110 to 115 megabits per second. So understand that you've lost some to physical overhead that you can't possibly ever capture. One step beyond that is poor implementations of TCP and UDP and remote procedure calls. A poor implementation there will affect your performance dramatically, and no matter how fast you're running the data into the machine, the application isn't going to see it a whole lot faster. If you've gone through all that stuff, and you're satisfied with it, then ATM at 155 is a service we offer today on campus. It works, and a fair number of machines are being shipped with ATM cards in it. And there's not much negative to be said about it except for the fact that we've taken our 155 megabit birthright and piddled it away to 100 through overhead, but so it goes.
JO In addition to just wanting to go fast, or faster, is there some other reason that I might want to really look hard at ATM compared to fast Ethernet?
KK Again, other than the fact that the machine you bought may have come with an ATM card in it, the answer is unfortunately at this point, no, that ATM has in its mythology a number of services out there, such as switched virtual circuits, that promise us the ability to really dedicate bandwidth to individual users. However, switched virtual circuits have taken forever to get off the ground. The interoperability among vendors of ATM switches on SVC's is highly limited, and we're not at the point where the benefits are there, unfortunately.
JB Ken, we are getting further along here very quickly. I just want to double check and see whether any of our guests have a question they'd like to ask of you right now. Joel, did you have a question?
JC Yeah, I have a question. Topologically, you in the old days--whatever those were--when we talked about putting fiber in, people used to come up with guidelines as to number of fibers that you would take per building. Actually, you talked about the narrowing of distances, even with multi-mode fiber, there's a distance limitation on gigabit Ethernet, I believe, which is going to make that difficult unless you have single mode fiber. I'm wondering, the concept of a fully collapsed backbone versus other switching centers here on campus, can you comment on that?
KK In fact, maybe all of us can chew on that for a minute or two. You know, the collapsed backbone idea is a little tough these days when you have speeds that are relatively high compared to a single router's ability to perform packet switching, and so the idea of having the collapsed backbone being, in fact, the backplane on the router may be more problematic now that the speeds coming into the routers are so much higher that you can't expect a single router to do this. Another issue here is, where is the data and where are the hosts that you're going to? I think one of the apps that we'll see on campuses in the next few years is video on demand, and so you want to make sure that your video servers are extremely strategically placed to minimize network traffic. In some sense, if your video on demand is serving your external constituencies, then in fact, you want to put your video server on the other side of your Internet drainage in the GigaPop, and one of the functions that a GigaPop may well serve is to house institutional video servers that are aimed at the external world. And there, I've not congested my link to the Internet with video streams going to outreach or external constituencies. I've put them on the other side of that line. The same logic will apply on campus, and so you want to position your video servers to be cognizant of where those video streams are going because they're not bursty, they're hefty and ongoing and represent a drain. I think one of the other advantages of collapsed backbones was that we could have everything be close to our networking technicians and we could UPS everything, and now, I'm discovering that we have to put UPS's in closets anyway. And our networking technicians have to have golf carts anyway, because the territory has gotten so big and so vast. We never collapsed our backbone, and I don't see anything to change that mindset, but I'd sure be curious to see what Michigan or RPI or anybody else who's on the line is doing.
JO The University of Michigan has a fairly traditional setup with FDDI rings. It certainly isn't a collapsed backbone. I talk to a lot of different people around the country, though, who talk about using ATM as a strategy to collapse their router backbone, and to use the higher speed switching ability of some ATM switches to make it look like it's a single hop between any two routers or between a host and a router, even though it might go through multiple ATM switches.
KK Yeah, you see that. In fact, if you do a trace route across the VBNS, I had my network management class do that as preparation for this session. And nobody could find a path longer than seven hops, which is odd, given that the --well, not odd, but that's a product of the full mesh topology of the VBNS and the use of ATM switches. But a typical Internet packet takes 17 or 18 hops, and here we're talking about only seven or eight hops, so that really is an advantage.
JB Ken, we have one question that I think we really wanted to get to today. Is now a good time in terms of the conversation about the collapsed backbone strategies?
KK Sure.
JB Okay. One of the things we wanted to talk about was what the next generation of campus networks is going to be, and is the enterprise-wide LAN finally in sight?
KK Well, I haven't followed Bill Gates' testimony today, but I can tell you, as of yesterday, the enterprise-wide LAN was in sight and its name was NT 5.0, and it is a very impressive product. As many people have said about Microsoft, it's not just that they're evil, it's that they're good and evil that makes it such a challenge. NT 5.0 is, I guess the phrase is, an insurmountable opportunity. It's (inaudible) and make some sense out of it and to build the enterprise-wide LAN that we missed with Novell and that we missed with AppleShare.
Actually, we did with AppleShare, and God, it was the wrong thing to do! You had no protection over who could see which zones, and you still have today that students print out obscene pictures on the chancellor's printer because of our AppleShare. That said, 5.0, which I think will be out in actual production in November, but is out in beta now and there's a new release of beta coming out in I think the May timeframe. It has extraordinary power.
In some sense, it's giving the nuclear bomb to Andorra and Liechtenstein. It is giving individual LAN managers through services like dynamic name servers the ability to derail campus-wide mechanisms for domain name servers. In some cases, NT 5.), through its directory structures, has the ability to create duplicate data that will be inconsistent, that somebody will build a local directory with one interpretation of what various fields mean and that the institutional definitions will be different. We have to worry about that.
Two other things that are in 5.0 that are consequential is Kerberos is in there, and that gives us a chance to do finally single log on to both the LAN and the Wide-Area or central servers, and NT 5.0 turns out to have an API in it for RSVP. And RSVP is one of the technologies being advanced for Internet2, which will guarantee bandwidth. This is nothing but an API. It isn't the management software or anything else, but it's an important hook in there that gives us the ability to perhaps guarantee various applications, a particular set of network characteristics associated with that. A lot of power, and what we need to do in higher ed is get out in front of that curve and create some standards, some standards of meta-data for the directory issues, some centralized Kerberos servers for the distributed Kerberos implementations that will happen in LAN's. Set up mechanisms for dynamic name service. Deal with a number of the other activities that are in there that make NT 5.0 so powerful and so dangerous at the same time.
It really is the first enterprise-oriented piece of software for the LAN, and one of the things that Microsoft just announced that has given me faint hope is that there is a piece of software now available that will synchronize your passwords between the NT server and a Unix server, I think it's using Kerberos. And so that piece of software is free to higher education, and Microsoft doesn't do a whole lot of stuff that's free to higher education. And this is one which is a wonderful piece of glue, and we need to be very aware of this. The directory structures may be in the long term the most important part of 5.0.
The buzzword for the next three years will be "directory enabled." And it will be applied to directory-enabled networking, directory enabled computation, directory enabled French fries may be right out there, where they will look up your French fry preference in your directory and then the French fry machine on your campus that's on the network will cook it right to your --
JB And send it over that wide bandwidth we're going to have! That's what we're going to need those 155 megabits for! Ken, we're going to have to close out for today, but do you want to just have any final words to folks? As they're looking at NT 5.0. what's the first thing they ought to do, or any summary like that?
KK Well, I think CREN is looking at providing some kind of educational services to help us, so I would think one thing would be to keep checking with CREN to see what its intentions are. Beyond that, I would think that I don't know enough about 5.0 to know exactly how we are going to proceed on it, but I do know that it should be on the radar screen.
JB Okay, well, thank you very much, Ken. I would like to thank everyone for joining in. And also be sure to use the e-mail of ccs@cren.net for any follow-up questions, and Ken would be able to take those. Also, plan to join us here for the fourth Expert Event in this series. Actually, it's just next week, Wednesday, March 11 at 3 PM, a little earlier, when our guest expert is Mark Bruhn from the University of Indiana. We'll be talking with Mark about the future of network security. And be sure and view the virtual seminar CD sections on network security if you can. Watch the website for the event phone number and URL, and if you'd like to receive your own announcement message for these expert events, be sure and send e-mail to CREN at cren.net. Ken and all even participants, thanks for being here. Thanks also to everyone who helped make this possible: the board of CREN, Corporation for Research and Educational Networking; our guest expert, Ken Klingenstein; Jeff Ogden and the team at Merit; Jason Luke, the audio encoder. All who joined in, you were here because it's time. Good-bye Ken.
KK Bye-bye, Judith. Bye-bye, all.
JB 'Bye, Jeff.
JO So long.
JB And 'bye, all online.
