Integrating Voice, Data, and Video in the Campus Network

Hello. I would like to spend some time talking about what I think is the most important topic in network planning over the next decade, and that is the integration of voice, data, and video in the Campus Network. We're going to spend some time talking about why that's important. We're going to look at some of the approaches to doing that. We're going to look specifically at the plan for Cornell University, and then we're going to talk about some of the challenges that we face as we move toward the next generation network, one characterized by the integration of voice, data, and video.

Why is the integration of voice, data, and video in the Campus Network important? Well, there are several reasons, and the importance of those reasons to you on your campus will determine, to a great degree, how seriously you have to take this issue of integrated voice, data, and video. In the first place, there are a set of technical imperatives, and these are very important as we watch the next generation of applications unfold on our University campuses. They fall into several areas; our traditional science areas, as we talk about heterogeneous computation, the ability to combine supercomputers with the capabilities of imaging workstations that have to be very tightly coupled to supercomputers, the teaching missions that we have now in our universities and the growing importance of distance learning. As you look at the first-generation Internet, the capability of doing distance learning in that environment, where we integrate video into our instruction, is not possible to do on the first-generation network; and as we talk about the future of distance learning, we have got to establish a network infrastructure that is capable of combining voice, data, and video. And, we have all seen that the most important contribution that many of the campuses have found for networking -- for high-speed networking in particular -- is in the area of communicating and collaborating. And while the first-generation communications technologies have been important -- the electronic mail, the list servers -- we're going to see a radical change in the types of communicating and collaborating that are possible in the next-generation network, when in fact we're able to move full-motion video out into that environment. And so the technical imperatives are obviously what have to drive your campus's approach to integrated voice, data, and video.

But quite honestly, particularly for those of you who are worrying about financing the Campus Network, our investigation has determined that the financial imperatives are what is really driving our decision to move sooner rather than to move later. We have discovered, for example, that one incurs tremendous cost penalties in current generation telephony. About five years ago, when we began to do our next-generation network plan, we looked very closely at the nature of our current voice and data networks. In the case of the voice network, we found it was requiring a tremendous amount of investment on our part in order to maintain roughly 500 simultaneous voice conversations and the capacity to do that at one time. On our data network, we found that we're sending tremendous amounts of data through that network. In fact, if you compare the current data network to the current voice network, the data network is carrying approximately 200 times the capacity of the traditional voice network. However, when you start to look at the cost of that network, we discovered that we're spending roughly four dollars on the voice network to every one dollar we spend on the data network. Why is that the case? Because the voice network is based on a more traditional technology that, of course, guarantees a quality of service and guarantees a connection when you start to make a telephone call; but that value comes at very, very high price. And the question for us now becomes, when will our packet data networks like the Internet become capable of providing this quality of service and low-latency capabilities that one needs to provide voice communications? The problem, of course, with having to make these levels of investments in our technology is that they become barriers to additional campus investment in technology.

Currently, we are in a situation, I suspect, across most campuses where, while we may be able to find some small amounts of additional money to fund Campus Networks, we are finding that in general, we are tapped out. There's not a significant amount of additional money to spend. When we add up the cost of updating our current data network, of replacing our current PBX, of providing on-campus video network, we find that cost barrier to be something that -- certainly in the case of our university-- we're simply not able to achieve without some serious, serious sacrifices; in terms of the applications that we're able to support and in particular, the ability to simultaneously provide good voice communications, first-rate data communications, and in many cases, establish a video network that is every bit as ubiquitous as our current voice data networks, is simply not possible. And, quite frankly, in order to keep higher education in a leadership position, continuing to use our networks as we have in the past for strategic advantage is going to require a different approach; a significantly different approach, in fact, to the way we look at our Campus Networks.

Well, as we start to look at integration of the Campus Networks, the question becomes, how do you go about it? While there have been different approaches taken at different universities and in different corporate environments, I have found a model that I think tends to be pretty solidly equated with successful efforts at most universities. There are two levels; what I call the building-block level and what I refer to as sort of the next-generation level. In terms of the building blocks, you will discover that it will be very difficult to achieve integration of voice, data, and video with organizations that support particularly voice and data, that have split reporting lines in your organizations. The amount of coordination and leadership necessary to make this kind of integration happen is very difficult to do across the organizations. Many universities, in anticipation of this, have moved to integrated reporting lines for voice and data organizations; and frankly, have found some reasonable amount of success in achieving the objectives when there is a focus and a lot of leadership around seeing that a voice and a data organization work effectively together. But frankly, and we have experienced this at Cornell University, the real ability to look at the future of integrated networks comes when one reaches the point where you have a unified organization; when we begin to see an organization's approach to both voice technologies and data technologies become internalized by a staff who understand that they've got to learn the skills of the other organization, who understand that the future of the network will depend on seeing the differences in these technologies begin to go away.

The other level of integration that's very important is in the area of financing. It is often the case that networks are financed in very, very different ways. Quite often, in fact it is probably the norm that on most campuses, we find that the data network has been traditionally funded through some model of central campus allocation; while the telephone network, from the very beginning -- when we first began to put PBXs in universities was done from an enterprise perspective, that is, fully cost recovery. And of course, in some environments, we have a mixed model for collecting data for voice, data, and video services. The reason this becomes so terribly, terribly important is because to try to walk into the integration of voice, data, and video with two completely, radically different models of cost-recovery becomes a real barrier to doing that effectively. And so, for those of you who are beginning to make the moves toward integrated organization in anticipation of integrating your voice, data, and video networks more effectively, you've got to begin to look at the model for financing those. Of course, the level of integration that many people recognize as most important -- and in fact, it is, and many universities have now moved beyond this arena -- is in terms of physical plant. Having a physical plant in place of wire a fiber that is capable of supporting integration is a very important step to take.

Now, these are what I would call the fundamental building blocks, and as you look at universities across the country, many universities have now begun to tackle these in a very serious way. And, in fact, if you look at the experiences, particularly our experience at Cornell University, we have been able, in fact, I suspect, not so much to save money by doing these three levels of integration successfully. But, in fact, we have really had the opportunity to avoid additional cost.

But to really realize the potential of integrated voice, data, and video, one has to go after what I have traditionally called the Holy Grail of integration, and that fundamentally is integration at the switching level and at the application level. If you look at the switching level, the current situation in nearly every university in the country is that they have built a reasonably fully-deployed and ubiquitous data network based on a packet technology, most often TCP/IP. Those networks tend to be composed of an array of central campus routers combined with switches for Ethernet and other kinds of switching technology for data to the desktop. In the telephony case, most campuses, particularly since the divestiture of telecommunications in the mid-1980s, have moved toward installation of a separate circuit-switched voice network that is normally comprised of a large and often very expensive switching infrastructure, coupled with a massive distribution of telephone sets and line cards around the environment. For those universities that have already begun to move in terms of providing video infrastructure, that infrastructure is most often provided in an analog video network, quite often across cable with some sort of broad-band/mid-band split implementation. And of course, the problem with this is that all three of these switching infrastructures require different kinds of staff to support them, are fundamentally different technologies that require very, very different kinds of support modes, and when one looks at building the next generation network, that would require us to have a state-of-the-art data network, an updated voice network, and a video network capable of supporting video to the classroom and to the desktop. You begin to look at the campus level at the costs of providing that kind of infrastructure, and you're often talking in the range of 25 to 40 million dollars in order to achieve state-of-the-art nature in all three of those networks. The target, then -- and the only way we're going to save a significant amount of money -- will come from collapsing that switching infrastructure into one switching fabric across the campus that is capable of handing both voice and data, and providing video services as well.

Now, as one begins to move toward the level of full integration, one also discovers that a lot of attention has to be focused on what I would call application integration; that separate applications that support voice -- telephony, for example-- and that support e-mail and communications across the data network and, obviously, provide video communications from one person to another or multi-point, from multiple people to one or from one person, the sort of broadcast paradigm, from one person to many. The implication here is that, in order to really take advantage of this integrated switching network, we're going to have to move to a new level of integrated applications. The most interesting challenge associated with that, of course, is moving the telephony application from this very odd, black instrument that sits on our desktop into a fabric where we're able to sit down at our workstations and communicate by voice across the network to the people that we would like to.

If that is in effect our goal integrated switching, how do we get there? What are the key challenges? Well, clearly, there is a set of challenges that are technical here, and one could not in any way underestimate the impact of those technical challenges. When will this be possible? About three years ago, as we looked, at Cornell University, at what we needed to do, we set a goal of having ourselves aggressively implementing an integrated network infrastructure by 1998. With full recognition that the nature of the telephone instrument and the degree to which that telephone instrument is so fully integrated in with the culture of the way we do business, that while we'll be able to start (we hope) telephony migration in the 1998 time frame, that, quite frankly we're not going to see full telephony integration in a switch network until probably a few years beyond the year 2000; probably most aggressively, 2002 and 2003. If this is, in fact, technically possible then, what are the alternative strategies that we need to use to get us there?

Well, we have built our strategy at Cornell -- and I'm going to talk more explicitly about that in just a few minutes -- around an evolving technology called ATM, and you might have read quite a bit in the trades about ATM technology. I think there may be some other components of this series that focus more explicitly on ATM. But in general, ATM was a technology that was, in fact, billed as a collaboration between the telephony, the data, and the video communications industry, the goal of which was to be able to enable one technology to be used for all three means of communication. In the Cornell case, this technology needs to be coupled, we feel, with something that allows us to deliver ATM technology to the desktop in a time frame before people have begun wholesale replacement and upgrades of their workstations to any technology beyond the current Ethernets. There is another strategy -- alternative technical strategy that is becoming ever more the focus of the work of the people who built the first generation Internet. It's called the next generation IP, with particular and special protocols, like RSVP. It basically stands for Resource Reservation Protocol, that allows you to mimic some of the capabilities of a network that needs to have low latency and quality of service provided.

Let me talk a bit about the Cornell strategy, based around ATM. If you come back and look at the goals we set for ourselves two years ago, we really felt the financial pressures that would be associated with replacing our large PBX system, supporting approximately 16,000 users. Those of us in the data business are used to working in a financial environment where the more users we support, the lower per-user our cost is. In the case of telephone switches, PBXs in particular, the reverse is true, and you find that you as you go over certain plateaus, the cost for supporting these things gets very large and replacing a large campus PBX is an investment that will run into the ten to 12 million dollar range, making a lot of additional investment in other technologies, quite frankly, impossible. We wanted to have a technology compared to our first generation Internet technology, with FDDI and Ethernet, that enabled scaleable band width. What do we mean by scaleable band width? We mean that, as we need to move our network to much higher band widths to support faster applications, we don't want to be in a position where we have to come back and fundamentally replace the entire infrastructure in order to make that possible; that we want to be able to come in and replace cards. So, we were looking for a network technology, and ATM was that technology that was designed to be scaleable up the band width levels. We also wanted to use our existing infrastructure where possible. Cornell, as is the case with many universities, has a very extensive Category III copper wiring plant put in the mid-1980s, and while we have pulled already certain amounts of higher-speed, more capable copper and some fiber into important buildings, 95% of the campus will continue to be on this Category III wiring. And our goal is not to rewire the campus until the year 2000. And so we needed to find a strategy that would preserve the life of the copper wiring, and as well, the campus has made enormous investment over the past three to five years in Ethernet "NIC" cards in workstations. And we wanted to try to find a network strategy that allowed us to move to integrated networking and still allow those Ethernet cards and people with those cards to be playing in the network. And then again, that ever-important and recurring financial goal. We felt that, at Cornell University, the campus was probably spending as much money on communications as it was likely to spend -- set aside, perhaps, some additional marginal investments, and we wanted to find a network strategy that kept us and our costs within the levels of current investment.

The Cornell plan, then, involved several elements. The construction of an ATM backbone that will start out at 155 megabits with the capability to scale all the way up, ultimately in terms of ATM, to multiple gigabits. We wanted to migrate our desktops, in what we have called a "flash" cut-over. Now, that term is very familiar to those of you who have been in the telephone business for a while. What that means is, you don't want to migrate a few people at a time, but you want to be able to come into an environment and you want to do a significant technology cutover all at one time. Why is that important? Because if, in effect, the decision about when they migrated was left to the end user, then our ability to control our costs and our ability to downsize our PBX as we ramped up telephone communications over the packet-switched ATM network would be much less than if we were able to have some control over that. We intend at Cornell to use two technologies to do that. Bear in mind our Category III wire plant. We will be implementing 25 megabit ATM to those people who need faster connections, but, for those people that are not in a position to move their workstation from Ethernet to another technology, we have proposed and are working with a number of people in industry, to create a new standard called "cells-in-frames" that basically carries ATM cell-based applications over Ethernet frames, enabling somebody to receive a telephony service at their desktop, for example, and still maintain their Ethernet connectivity. Clearly, the plan with respect to telephones is a very important component of this, and we really have sort of three components of our strategy.

The first component is that we feel that large portions of the campus will want to move toward workstation-integrated telephony, that people have become quite enamored of the notion, particularly with early experiments with video products like See You-See Me and others, that the workstation, in fact, makes an ideal environment at which one is capable of providing most of the voice communications one wants, when coupled with some solution for what happens when one gets up from the desk and wants to walk around -- to go to the next office, to be able to pick up a phone and make a call there. Then, we are looking very closely at the evolution of brand-new technology that we see some vendors focusing in on called, quite simply, ATM phones. These are remodeled phone instruments that in fact will plug into an ATM network that basically allows you to do voice communications in a very standard way, with a very standard-looking telephone, without all of the PBX switching infrastructure that is necessary. And then, it is always the case that we, as we see the culture change for telephone communications within campus environments, are going to have faculty and administrators who want to stay on legacy phones. We're going to have emergency phones and the need to maintain some smaller PBX well into the future becomes a very, very important component of this strategy. One other very clear element of the plan, of course, is that as we do that integration, we have to maintain the kind of features and functions that people within the university environment are used to having in their telephone environment; the ability to forward calls, obviously, the ability to get to the standard commercial telephone network. And in this Cornell model, over time that PBX also needs to stay around in order to become a server to the ATM network for the kind of telephone features that are so very important. And in the case of video, it is our plan to use current technologies -- and there are several evolving right now -- to do ATM to the desktop and to the classrooms.

So that's a summary of the Cornell plan. This is a very ambitious plan. We have bitten off pieces of this, I think, probably before many other universities are ready to tackle this; in several cases, before the telecommunications vendors are building the kind of equipment we need to have to get there, and so this project for us has meant a great deal of joint work with the vendor community to try to figure out how to make this a feasible plan.

Now, as you begin to move in this direction of integrated technologies, there are challenges that are very important other than technology challenges. In fact, I would probably argue that one can solve all the technology challenges in this area and still find it very difficult to develop an integrated network, unless some attention is paid to what I think are some other key challenges. A very important one, of course, centers around organization. I suggested earlier that I feel it would be very difficult to try to do this kind of integration without having built some of the fundamental groundwork in terms of moving campus telephone, data, and video organizations into an environment where they are capable of working together with each other more effectively than has been the case in the past. Obviously, this issue is not solvable without addressing some very real campus political issues, given that these organizations have often historically reported in three different places and have generated, in the case of the telephone enterprise, for example, significant amounts of revenue which tends to be taken very, very seriously within the campus environment. And the ability to pull these things into a single organization is, in fact, a challenge that I suggest will require the best possible efforts to achieve a successful outcome. There are certainly core application challenges. I don't worry a lot about whether the integrated applications for integrating data networks and video networks will move forward rapidly. The piece that is most troublesome is moving telephony into a different environment; in effect, reinventing telephony as we know it now. The extent to which current telephony is so integrated in our culture implies that a tremendous amount of very creative resource is going to have to be invested in doing that effectively. And one could not think to move toward this level of integration and have the flexibility and the sorts of vendor products necessary to do that without taking into account the political and the regulatory environment. Quite simply put, while the goals of telecommunications deregulation are very much biased toward the notion that we will see integrated voice data and video emerge in our telecommunications infrastructure, there is enormous uncertainty about what time frame that's likely to unfold in, about how the various vendor communities are likely to line up. Certainly as one looks at the prospect of moving large amounts of voice communications into the packet-switched data network, be it this generation Internet (as many people are doing) or, more appropriately, the next-generation Internet, I think, we'll have the capability of supporting that. There are a large number of companies in this country that make an enormous amount of money providing telephone services. Since our goal is to reduce the amount of money we spend, in fact, one could argue that our goals do not always line up with those of the industry. Already, as we have begun to explore this, as we've tried to watch very closely the unfolding of this from a technical perspective, it becomes very obvious that many vendors are walking very carefully here, trying to avoid killing the golden goose since they make so much money from the telephony business as a whole.

Well, I have spent some time talking about the integration of voice, data, and video communications, trying to give you some idea about why we feel it's important to talk to you about some of the key challenges involved, to talk about at least one plan at Cornell University for doing that. I hope you find this valuable.

Thank you.

About CREN

© CREN, 1999

Contact Us