| 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.
