North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
RE: Internet II is coming...
| would you mind expanding a bit on why SVCs would do the job? | We're trying to determine if it's a service worth offering anytime | soon, who would use it, etc., Well, you have to remember that I'm not a marketing expert, so my advice has to be taken with a few kilograms of salt. Also, I was distracted for long periods of time between paragraphs, and had little revision time... Essentially, I could see some applications where one might want to nail up an SVC for a day or two, essentialy like ordering a private line. One obvious application might be putting some facility into well-known conference venues; from time to time one would want to nail up a gaggle of bit pipes to various places. Whether this is done as a virtual circuit using ATM or some other VC protocol, or mapping a "real" circuit through some SONET fabric(s) is probably less material than that it work reliably and not cost arms and legs in terms of time and in terms of money to set up and tear down. Another likely application might be to set something up between a supercomputer centre and a big data-storage or data-collection facility for some relatively short period of time. For instance, if a bunch of oil exploration data is suddenly going to be processed on some crunchy site, one would want a bunch of bandwidth available for some period of time as something along the lines of a dedicated circuit. Again, how this is done is less important than doing it relatively inexpensively and reliably. Could this be done with SVCs? Yes, certainly, but your routers will have to deal with shoving IP down the new SVCs, and your SVCs will therefore more likely want to be more like short-term PVCs than anything else. The 'S' part is probably useful for pricing and billing; your customers get to bring up a "circuit" when they want it and tear it down when they're through, and if one thinks in terms of hours or days or something as a billing period, rather than seconds, or milliseconds or whatever, this is relatively nifty stuff, potentially. If you are having to think in short time units, you get into ugly SVC setup times and having to deal with when to bring up an SVC and when to tear it down, more dynamic rather than static routing and the like. Could this be done with PVCs? Sure, no problem, but you lose some potential functionality and flexibility. For instance, if I were an ISP or an ISP's client, I'd like to be able to guarantee an X kbps path to somewhere specific for some period of time, which roughly translates to a CBR PVC, if one is disinclined to use a "real" private line. The problem is that PVCs typically are set up by telcos (which are not known to be ultraresponsive), and likely the SVC mechanism will allow one to acquire more or less bandwidth as necessary, under the control of the telco's customer, rather than the telco itself, within configured maximum and minimum bounds. This is pretty much the only REALLY interesting feature left in ATM: ideally you get to play TDM games at the endpoints rather than having to muck with things through a cloud or series of clouds. If one could do this with SONET, or one could do this at some other level that is more data-friendly than ATM, it would be a plus. (BTW, RSVP is not a good way to do this at the IP layer, but hybrid level-2/level-3 switch/routers (think of tags) might be...) Essentially, SVCs *could* offer some flexibility in terms of finding out what one wants as a PVC or in terms of having "temporary" PVCs. SVCs are not, however, remotely useful for building a connection-oriented network with the way the Internet works now, except in very very small niche markets. Thinking of SVCs and the equivalent as lightweight private lines might well be a good marketing and engineering position to take, although it is not precisely what canonical ATM hype seems to believe in. Moreover, you will note that lightweight private lines is not something that can be done only by ATM... Sean. - - - - - - - - - - - - - - - - -