The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] ATM-LSR do they use OSPF/IS-IS or PNNI??
Geoff....there is another important QoS-related difference between ATM and MPLS/IP which I have tried to explain on the list before.....but let me give it another shot since I think this may still be not understood looking at some of recent mails: 1 In a cnls fabric failures get mutated into QoS hits. That is, post the IGP re-convergence, there is no reduction in traffic demand, just a reduction in resource available. With 1 class (ie BE) there is uniform reduction in QoS to everyone, with multiple classes (ie DS) there is some skewing of the resource reduction across the classes. The tolerance of an application to accept resource reduction is application-specific....so what would be unacceptable to say some interactive services (eg voice) would be OK to some less-interactive service (eg Email). Contrast this now with an CO fabric. Here failures just take-out the traffic served by the affected trails. Traffic on unaffected trails sees no QoS hit. So this leads to the 1st observation wrt QoS in comparing a cnls and CO fabric, ie in a cnls fabric failures get mutated into QoS hits but this is not true in CO fabrics. 2 There is no relationship between the up-state QoS forwarding treatment of a given application and its survivability requirements. For example, whether voice is mission-critical or not it has to go EF class to meet delay/jitter-transfer requirements. However, within a VPN (or between different VPNs) who is to say which voice is/is-not mission critical? The sales team may have mission-critical voice but the engineering team may not.....however, things might be reversed for their data applications (which would use some AF class say). So this leads to the 2nd observation wrt QoS in *either* cnls or CO fabrics, ie the up-state QoS forwarding treatment of an application tells you nothing about its survivability requirements. 3 This now leads to the 3rd observation on QoS and availability, ie QoS and availability metrics/objectives need to be set independently, but QoS is only applicable when the trail considered is in the available state.....and from this and the 1st observation we note that this independence is strictly only possible in CO fabrics. 4 As pointed out by a couple of people in recent mails, VPN customers consider security/traffic-isolation requirements (ie trad L2 VPN look-alike) before they consider QoS requirements. Further, the survivability of VPN_A must not be a factor of the traffic/behaviour of any other VPNs. So when we couple this with the previous observations this leads to the almost inescapable requirement to have hard effective BW partitioning between VPNs. And it is this reason why one sees, and will continue to see, ATM in most operators access networks (since here one cannot appeal to 'over-engineering', as may be possible in the core). It was the above perspective (ie a need to be able to offer/measure availability on LSPs) that motivated our recent work on MPLS OAM which some of you will have read I guess. And until we get MPLS to offer the same (or ideally better) QoS/availability attributes, then ATM (or possibly FR and TDM fabrics) will continue to be required for those VPNs (and access networks) that require more robust availability/QoS objectives. regards, neil > -----Original Message----- > From: Geoff Bennett [mailto:geoff.bennett@marconi.com] > Sent: 20 April 2001 09:40 > To: HANSEN CHAN > Cc: Donkin, Richard; MP LS; mpls-ops@mplsrc.com; mpls@UU.NET > Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI?? > > > Hi Hansen, > I agree with you in general...MPLS should be able to > demonstrate similar > capabilities to ATM QoS, but I think most people would agree > there's a long > way to go yet, especially for the routing protocols. There's also the > problem that nobody is yet building LSRs that were designed > for the job. > They're all adaptations of either a router or an ATM switch design. > > Hard QoS architectures are hard to build. ATM got it right > for the most > part, but there would be a strong argument that the way ATM > does QoS (on a > VC basis) will not scale to networks as big as the Internet. > With MPLS we > can aggregate things nicely, but in my mind this is not QoS, > it's CoS. The > tradeoff we seem to be faced with is the "quality" of our QoS > architecture > vs its scalability. > > ATM also has the advantage that it's Connection Oriented from > end to end. > One of the reasons it can deliver such a hard QoS assurance > was that the > application itself is able to negotiate with the network to > ask for the > explicit QoS requirements, and to get the network's agreement > that these > resources were available. To duplicate this with MPLS we'd > have to extend > RSVP signalling to the host (or maybe to the voice gateway in a VoMPLS > installation). I know this has been discussed, but is at a > very early stage. > > Another advantage of ATM in terms of QoS is the fixed cell size. Any > fixed-PDU technology will have the edge over a variable PDU > technology when > it comes to QoS. Before I ignite a cells vs frames debate > let me say that > I believe the (many) advantages of a variable length PDU > infrastructure > (especially at very high speeds) outweight the QoS benefits > of fixed PDU. > In other words, I'll go along with the assumption that if you're > transmitting at a high enough speed, the CoS you can squeeze out of a > variable PDU network will one day be "good enough" (if you > over-provision > the network sufficiently). > > Cheers, > Geoff > > > > At 11:53 19/04/01 -0400, HANSEN CHAN wrote: > >> But as I understand it, the added value from IP VPNs > either comes from > >> security (whether this is "isolational" in nature like an > ATM or Frame > >> Relay VPN, or "truly secure" as in the case of an ecrypted > ATM or IPSec VPN > >> is up to the user), or from "perceived service > enhancement". The latter > >> could be via a CoS mechanism, which MPLS can potentially > offer, or from a > >> hard QoS mechanism which can only be offered from... > >> > >> a: A TDM mechanism (like SONET/SDH, which is expensive). > >> b: A native ATM service. > >> c: An over-provisioned stat mux service (eg. IP), which is > also expensive > >> in the long term. > > > >Geoff, > > > >I agree with your points above. However, I don't think there > is anything > stop MPLS implemented with a hard QoS mechanism like ATM > >has done. A good LSR with the necessary traffic management > infrastructure > (queuing and scheduling) can achieve the same level, if > >not better QoS. > > > >Cheers, > >Hansen > > > >------- > >The MPLS-OPS Mailing List > >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > > > ================================================================ > Geoff Bennett > Tel: (33) 497 21 43 62 > Director of Technology, OCTO > Fax: (33) 497 21 43 50 > Marconi > Gaia - Bat. E > email: geoff.bennett@marconi.com > BP 123 > 06903 SOPHIA ANTIPOLIS > FRANCE > ================================================================ > |
|