| The institution in the situation you describe, procure an ATM interface to the | provider. Have the provider two PVC's. Set both PVC's for EPD. Contract | the Researchers PVC as a VBR PVC, and contract the other as a ABR or UBR | PVC. In other words, somewhere close to the edge of a network fabric, some router is making a decision based on things like origin/destination or protocol number or what-have-you to send traffic across a point-to-point line instead of the Internet. Instead of building a real point-to-point line, you build a PVC using ATM, and then play games to make sure the ATM fabric does the right thing or some approximation thereof if there is contention in the ATM fabric. In the brave new world of an ATM-free future (assuming the ATM people don't get _cheap_ SVCs out the door before we get the "Peter-Tony Protocol" model deployed), you can do the same for less cost by pulling a tributary out of your SONET MUX at the appropriate bandwidth, and doing policy-based routing using your favourite vendor's NetFlow switching or some future tag-switching-like system or the equivalent. This is your PVC, no EPD or PPD needed. Cells? What are those? All each approach is doing is source-routing across different paths, making a decision somewhere close to one or both edges of a given fabric. This could as easily be accomplished by having a fabric made up of either multiprotocol routers which deal with IPv4 and something else which does source-routing, or of routers which have the time budgets to do Christmas-tree packets (all decorated with options). If you make decisions to do different queue/drop algorithms based on something decided at the edge of a fabric, or at a host, then you might not even necessarily need any sort of separate infrastructure to meet most reasonable QOS-like demands. This is your *BR game-playing with ATM, for dealing with contention. The separate circuit model has an attraction in that you can avoid having Special Traffic move normal traffic out of the way, and you avoid paying a huge penalty in routers in the core of the best-efforts Internet, both of which are serious problems in efforts like RSVP. A mix of separate circuit/parallel infrastructure vs. smart queuing in IP routers should really be done using the appropriate parts: real circuits and real routers. Playing games with ABR and friends introduces the problems of disconnected resource consumption feedback loops (TCP vs ABR, for example), which tend to compete with each other in nasty ways. Temporary circuits of whatever flavour have an attraction in that you can get a mix of parallel infrastructure and smarter infrastructure without necessarily incurring enormous cost, and without worrying about byzantine billing for normal Internet traffic. This is coming, both for ATM and for non-ATM models. Finally, I assert that we are already at the point where anything that can be deployed today that is based on ATM (which incidentally typically rides over SONET/SDH) can be kludged up (or even done right) with Cisco gear and SONET/SDH. ATM has a temporary edge in being multivendor and making it easy to do TDM-style and point-to-multipoint things, however the former is likely to be short-term and the latter is something that can be done better for Internet traffic anyway, with a bit of cleverness in the latest and in the next generation of IP routers. Since these routers will be needed with or without ATM, the time to ponder whether ATM really has that much added value in the long run is upon people already. Sean.