The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] QOS Routing
firstly, a key difference between resource reservation at the ATM layer and at the IP layer may also be how much topological information you have when you make the reservation - if we assume IP over ATM, then there are 3 types of routing - classic, where the ATM layer has no knowledge of the IP layer, augmented, where, withi nthe ATM cloud, the ATM layer and IP layer share information, and integrated pnni, where both layers have full information only in the latter case can i) a sensible global decison be made as to whether a full path can support a reservation ii) the routing updates then include the capacity allocated (or subtract it from their link state4 advertisements - though its safer to have two seperate link state advertisement types, one for actual transmission capacit, the other for allocated effective bandwidth) if you believe ATM everywhere, then the problem goes away... the origin of this entire thread was about QoS routing - neither ATM nor IP (with int-serv and rsvp - see the to: line) have any of the 3 stages of what we might mean by this 1. routing that permits QoS to be advertised safely so that more than a single set of paths from a soruce to a set of dfestinations are available - this is just about there in some OSPF implementaions and promised PNNI work... 2. routing that includes current traffic conditions in the advertisements so that new flows be admitted whilst taking account of existng traffic - obviously, this can be done without actually advertising the traffic conditions if a hop by hop reservation is made since each hop can decide if the current reservation set will permit a new flow, but it might be nice to actually advertise conditions so that the next stage can evolve... 3. alternate paths (i.e. overflow paths) routing, where not only do we advertise the metrics, and the metrics include the current traffic conditions, but we also can route (and reroute) traffic to load balance the net..... doing this, and including more than just link capacity, is very very hard.... the advantage that we have with IP level reservation is that it is (just about) incrementally deployable... secondly, off at a tangent.... reserving resources for one person is the same as saying that you are prepared to deny resources to someone else - denying resource to some applcations is denying someones business (e.g viewing live TV< surveillance, telemmetry, share dealng - anythign where the actual data soruce is ephemeral) - denying service to other applications is noit denying anything - e.g. if an FTP can be resecheculed, and osmeone has other work to get on with, then whats the problem - these key requirements are why you HAVE to have guaranteed services, and why the internet works....respectively.... however, there may be no business case for denying service to any realtime users - certainly TV companies (and most telephone nets) guarantee service without reservation....in the sense that you practically never get a busy signal..... the bottom line is that there is only so much that people can do - and being on a 3D holographic videophone or VR game 24 hours a day is the limit - there is no such thing as a bottomless demand for capacity....people claim computer based applications might cause higher capacity fdemand, but the economics say that we'd move the processing power to the data in those cases... jon |
|