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?
From an architectural perspective, I don't think I'm qualified to answer, there's probably only a handful of people that are. Chris At 04:18 PM 1/28/2002, J L T wrote: >Chris: > > >From the sound of your message, it sounds like we must accept one other >the other and we simply can't have both. In effect, I think your saying >that the hardware architectures are so different, and no simple >mechanism have been found that can effectively map the two environments. >Interestingly, in my review of the history of MPLS' development, Toshiba >introduced the concept of a Cell Switch Router. Their proposal, if >taken to its natural conclusion, would have given label switch routers >the ability to offer hard QoS mechanisms in a packet network using IP >signaling mechanisms. Yet, ultimately, it was determined that there was >not a clear market need nor problem that was being addressed with the >proposed architecture. I'd be very interested in hearing whether this >is a solvable problem architecturally and whether there is indeed that >market need. It seems that much of the "hard bounded" QoS needs revolve >around packet switched transit services and private networks in their >transition to packet switching. Furthermore, private ATM and FR >networks appear to be one of the few decently profitable operations for >most providers. IMHO, I would think that being able to offer both hard >guarantees for the vast majority of traffic, and allowing them to >transition to packet switching could be very appealing. I it just not >architecturally possible at this point? > >Jeff > >-----Original Message----- >From: Christopher Lewis [mailto:chrlewis@cisco.com] >Sent: Monday, January 28, 2002 1:29 PM >To: Daniel Kharitonov >Cc: mpls-ops@mplsrc.com >Subject: 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 ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
|
|