The MPLS-OPS Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: Guaranteed QoS using MPLS?
A long discourse on ATM vs MPLS is pointless. It just depends what problem you are trying to solve. If your main aim is to transport IP traffic, IP networks have more appropriate queuing mechanisms. Getting ATM networks to differentiate between an IP application with high priority and an IP application with low priority is a real pain (as an aside, QoS is an end to end issue, there is no ATM to the desk top, and the ethernet card is not going to understand CBR or VBR). To map Ip to ATM QoS you either have to perform something like a queue and drop on a per precedence basis in to one VC, or have multiple VCs and map the IP traffic to the different VCs depending on how you want to map a given precedence level to a VC type. If you want to have hard edge to edge QoS guarantees for all traffic, ATM is probably what you want. So a provider that primarily wants to offer voice services on their private network, plus some data and no internet access may make a different choice than a provider that offers internet access, differentiated level of service for data and some voice. Chris At 02:50 PM 1/28/2002, Daniel Kharitonov wrote: >IMHO, >MPLS just slowly follows in ATM's foosteps as far as >QoS goes. It already faced the same issues with >constraint-based routing as PNNI RCAC developers did, >now we are hearing talks about crankbacks, and I will >not be surprised to see a multilevel (>2) OSPF draft >pretty soon. >As far as the forwarding plane goes, MPLS definitely >is not quite there. Not only policer features (like >CAR) are not geared towards full dynamic CAC yet, but >scheduler operation and resource (buffer space) >reservation in MPLS platforms is not nearly as good as >in ATM hardware. Sometimes it looks rather funny - in >a fully capable ATM switch LS1010, if used as LSR, all >tag switched traffic just bypasses CAC, can belong >only to the WRR traffic groups (no rate scheduling) >and there is even no good way to map labels to the >TBRs. >It looks like the legacy of ATM world is just not >being reused properly, as new kids on the block are >reinventing their own wheels :) > >-- >DK > >--- Christopher Lewis <chrlewis@cisco.com> wrote: > > OK, here's a really simple view from an IP rather > > than ATM background :-) > > > > With ATM connections, the resources needed for the > > VC are defined at setup > > time and resources are reserved along the VC path > > for that VC. ATM CAC is > > still in the control plane AFAIK. In MPLS, resource > > reservations are also > > in the control plane, so to make them "hard" a > > policer has to make sure > > that only the amount of traffic of a certain type > > that matches the > > reservation for that traffic type enters the > > network. So if you reserve 100 > > Meg through a TE tunnel for high priority traffic > > and CAR ensures that no > > more than 100 Meg of high priority traffic is > > allowed in to the network, > > things are fine and pretty much equivalent to ATM > > guarantees IMHO. Of > > course, this requires co-ordination of two different > > features to ensure you > > get what you want, which is obviously more > > administration, but it seems > > possible to me. Maybe an NMS/OSS vendor opportunity > > to make something that > > keeps track of this for the service provider? > > > > Perhaps if there are specific questions on the docs > > referenced in the link > > below you could let me know? > > > > Chris > > > > At 05:29 AM 1/28/2002, Jacinto Velasco wrote: > > > > > > >People, > > > > > >My background is ATM with an IP component and only > > recently I joined this > > >MPLS world. I have been reading discussions,White > > Papers, Tech Notes... on > > >QoS, CoS and DiffServ for MPLS and could not yet > > find a white paper or > > >equivalent that put some light on those issues, > > also I have notice within > > >the MPLS-distr-list several e-mails asking for such > > info again and again... > > >. From what I have read I could not see any clear > > method to guarantee a > > >real QoS in mpls that convinced me (remember I come > > from the ATM world), > > >it`s always a sort of... , theres a big cloud > > behind it for me and probably > > >for some other people. > > > > > >Do you have any documentation or sites you can > > re-direct me that puts some > > >light on this issue. > > > > > > > > >Regards, > > > > > >Jacinto Velasco > > >Marconi > > >Senior Systems Eng. (Broadband Routing&Switching) > > >(Embedded image moved to file: pic32237.pcx) > > > > > >Marconi Iberia S.A > > >C/ Caléndula, 93 > > >Minipark III Edificio E > > >El Soto de la Moraleja > > >28109 Alcobendas > > >(Tel: +34 91 229 40 82 (directo) > > >(Tel: +34 600 999 482 (movil) > > >(Tel: +34 91 229 40 00 (centralita) > > >2Fax +34 91 229 40 75 > > >*E-mail: jacinto.velasco@marconi.com > > > > > > > > > > > >Christopher Lewis <chrlewis@cisco.com> on > > 28/01/2002 03:57:14 > > > > > >To: <saqibj@margallacomm.com> > > >cc: <mpls-ops@mplsrc.com> > > > > > >Subject: Re: Guaranteed QoS using MPLS? > > > > > > > > >With the caveat that the amount of traffic the > > application will send is > > >known prior to the network being setup to service > > that level of traffic, > > >yes. > > > > > >Try > > >http://www.cisco.com/warp/public/732/Tech/mpls/mpls_techdoc.shtml > > > > > >This link shows how this can be done on Cisco > > networks by combining diff > > >serv QoS and MPLS traffic engineering capabilities. > > This combination used > > >to be called Guaranteed bandwidth services, but was > > changed to diff-serv > > >aware traffic engineering. For this to work > > properly, a policer at ingress > > >is necessary for the traffic eningeered tunnels to > > really function as you > > >want. > > > > > >Chris > > > > > >At 06:36 PM 1/27/2002, Saqib Jang wrote: > > > > > > > > > >Could MPLS be used to provide "virtual circuits" > > > >for IP applications having specific QoS > > requirements. > > > >For example, could MPLS be used to create > > guaratee QoS > > > >across an IP core for an application that > > requires > > > >no more that .1% packet loss? Do existing MPLS > > routers > > > >have such capabilities or would this require > > implementing > > > >a new MPLS standard? > > > > > > > >Also, how would an MPLS LER classify traffic that > > uses > > > >dynamic port numbers (e.g. SIP)? > > > > > > > >Saqib > > > > > > > >Margalla Communications, Inc. > > > >3301 El Camino Real, Suite 220 > > > >Atherton, CA 94027 > > > >(650) 298-8462 (W) > > > >(650) 274 8745 (C) > > > >(650) 368-8198 (F) > > > >saqibj@margallacomm.com > > > >http://www.margallacomm.com > > > > > > > >------- > > > >The MPLS-OPS Mailing List > > > >Subscribe/Unsubscribe: > > http://www.mplsrc.com/mplsops.shtml > > > >Archive: > > http://www.mplsrc.com/mpls-ops_archive.shtml > > > > > >------- > > >The MPLS-OPS Mailing List > > >Subscribe/Unsubscribe: > > http://www.mplsrc.com/mplsops.shtml > > >Archive: > > http://www.mplsrc.com/mpls-ops_archive.shtml > > > > > > > > > > > > > > >------------ > > >This e-mail and any attachments are confidential. > > If you are not the > > >intended recipient, please notify us immediately by > > reply e-mail and then > > >delete this message from your system. Do not copy > > this e-mail or any > > >attachments, use the contents for any purpose, or > > disclose the contents to > > >any other person: to do so could be a breach of > > confidence. > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: > > http://www.mplsrc.com/mplsops.shtml > > Archive: >http://www.mplsrc.com/mpls-ops_archive.shtml > > >__________________________________________________ >Do You Yahoo!? >Great stuff seeking new owners in Yahoo! Auctions! >http://auctions.yahoo.com ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|