Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI??

From: Javier Antich <[email-masked]>
Date: Wed, 18 Apr 2001 11:02:59 +0200

> Hi
> 
> If all ATM switches are MPLS capables, that is, they are able to run IP
> routing protocols like OSPF/IS-IS then they behave like neighbouring
> routers and use those routing protocols and LDP for label assignment and
> therefore for LSP establishment. However if you have two ATM-LSR which
> need to communicate accross a standar ATM cloud, you may have  either aVP
> established, what would lead us to the previous case, or use SVCs
> established by normal ATM signalling (i.e. PNNI) and SVC-to-LSP binding by
> using VCID Notification. In this case the ATM-LSRs would be using both
> OSPF/IS-IS and PNNI.
> 
> 
>                                           ^   ^
> ==============ooo====(.)v(.)====ooo=====
> Javier Antich Romaguera
> Network Consultant
> --------------------------------------------------------------------------
> -
> TELINDUS 
> Pza. Ciudad de Viena, 6-2º
> 28040 Madrid 
> --------------------------------------------------------------------------
> -
> [email-masked]
> tel: +34 91 456 00 08
> fax: +34 91 536 10 74
> --------------------------------------------------------------------------
> -
> For more information about our products and services,
> please visit our website http://www.telindus.com
> --------------------------------------------------------------------------
> -
> Full connectivity & mobility
> ==================ooo0===0ooo========
> 
> 
> 
> -----Mensaje original-----
> De:	MP LS [SMTP:[email-masked]]
> Enviado el:	miércoles 18 de abril de 2001 10:02
> Para:	[email-masked]; [email-masked]
> Asunto:	ATM-LSR do they use OSPF/IS-IS or PNNI??
> 
> Hello all,
> 
> I have some questions becasue something is verry strange to me.
> I just assumed that ATM-LSRS used an IP routing protocol (IGP) just for 
> finding the topology of the network.
> 
> But last i read an doccument and there they described that When you change
> 
> an ATM switch to an ATM-LSR it will use PNNI instead of a IGP for IP. Can 
> anyone make this clear for me??
> 
> Thanks a lot.
> 
> Greetings,
> 
> Niels Sitters.
> 
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

---

From: "Donkin, Richard" <[email-masked]>
Date: Wed, 18 Apr 2001 19:38:29 +0100

> -----Original Message-----
> From: Geoff Bennett [mailto:[email-masked]]
> Sent: 18 April 2001 11:15
> To: MP LS; [email-masked]; [email-masked]
> Subject: Re: ATM-LSR do they use OSPF/IS-IS or PNNI??
> 
> 
> Hi Niels,
> 
> There may be some confusion arising depending on how you 
> configure the ATM
> switch.  In effect there are three modes of operation for 
> this device...
> 
> 3.  Ships in the Night (SIN).  In this case, both ATM and MPLS Control
> Planes operate simultaneously.  ATM signalling happens on VCI 
> 5, and MPLS
> signalling on VCI 32.  VCs that are set up as a result of 
> signalling are
> "owned" by one or other of these control planes.   SIN would allow an
> operator to continue to run high revenue voice services (and 
> maybe existing
> Frame Relay or native ATM services...they make money too)  
> over the ATM
> "character" of the switch.  They can then run the loss-making Internet
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> services over the MPLS character.
^^^^^^^^^^

Very amusing... I'm sure this was just flame-bait, but first of all, MPLS
supports IP services, not just Internet traffic, and you can of course run
highly profitable IP VPN services over MPLS.

Ultimately, ATM/FR services (as seen by the customer) may well be carried
over an MPLS core, particularly as MPLS becomes one of the key signalling
mechanisms for all-optical core networks, but since much of the traffic
running over ATM/FR is actually IP, it may be simpler to deliver IP VPNs
directly to the customer premises. 

> Cheers,
> Geoff

Richard Donkin
T: +44 (0)20 7348 1507
Orchestream
Avon House, Kensington Village, Avonmore Road, London W14 8TS
T: +44 (0)20 7348 1500 F: +44 (0)20 7348 1501
www.orchestream.com

--
This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed.  If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited.  If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents.  Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated.

---

From: "Kavi, Prabhu" <[email-masked]>
Date: Thu, 19 Apr 2001 14:29:55 -0400

Geoff,

Your generalization about "loss making Internet Services" is
foolish.  

Several years ago, somebody forgot to tell UUNET that they
were selling loss making Internet services, and they hit
break-even during a period of explosive growth (very hard to
do).  I think it is fair to say they are quite profitable 
for Worldcom today.

I also know for a fact that several other large ISPs are 
profitable as well, but they are part of larger organizations 
that do not publicly break out the P+L of each division.

No doubt, ISPs could do better by offering a range of services,
some of which promise higher service quality.  But if a service
provider is going to start providing higher revenue services
today, why in the world would they want to do it over ATM 
switches?

Prabhu

> Sent: Thursday, April 19, 2001 12:20 PM
> To: Donkin, Richard; MP LS; [email-masked]; [email-masked]
> Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI??
> 
> 
> Hi Richard,
> Please read my post carefully.  Internet services are 
> generally intended to
> mean "best effort".  In contrast VPN services are supposed to 
> carry some
> kind of added value.  In other words, I fully accept that IP 
> VPNs should
> make more money than a basic Internet service.
> 
> 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.
> 
> I know that Orchestream's core business is based on the provision of
> services over an MPLS core, so this may be akin to asking a 
> barber if he
> thinks I need a haircut, but is there any evidence that IP 
> VPN services are
> "truly profitable" (as opposed to "press release" 
> profitable)?  the problem
> is that asking most SPs this question will result in "sorry, 
> this is very
> confidential information" responses.
> 
> I'm not trying to bang a vendor drum here, I'm truly 
> interested because of
> the fact that about a dozen European SPs are technically bankrupt from
> being too dependent on IP services ever making money.
> 
> Cheers,
> Geoff
> 
> 
> At 19:38 18/04/01 +0100, Donkin, Richard wrote:
> >
> >
> >This communication contains confidential information 
> intended solely for
> the use of the individual/s and/or entity or entities to whom it was
> intended to be addressed.  If you are not the intended 
> recipient, be aware
> that any disclosure, copying, distribution, or use of the 
> contents of this
> transmission is prohibited.  If you have received this 
> communication in
> error, please contact the sender immediately, delete this 
> communication
> from your system, and do not disclose its contents to any 
> third party, or
> use its contents.  Any opinions expressed are solely those of 
> the author
> and do not necessarily represent those of Orchestream Ltd or 
> its group of
> companies unless otherwise specifically stated.
> >
> >-------
> >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: [email-masked]
> BP 123
> 06903 SOPHIA ANTIPOLIS
> FRANCE
> ================================================================
> 
>

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 19 Apr 2001 14:39:41 -0400

Hi David

Please look at the Voice over MPLS framework document:
http://www.alternic.org/drafts/drafts-k-l/draft-kankkunen-vompls-fw-01.pdf

Presently so many VoIP working groups (MMUSIC/SIP/IPTel etc) have
there own mechanism for end-to-end delay characteristics but at the
applications level.

But in the above draft they made some progress to Voice Traffic 
Engineering using MPLS and Dynamic traffic management. Section 5 
is left unanswered about Requirements for MPLS signaling 
(LDP/CR-LDP and RSVP-TE)

Unfortunately I didn't see any progress after in VoMPLS.

-Venkata Naidu

> > 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.
> 
> One clear advantage of ATM is that ATM provides more parameters for
> tuning QoS than RSVP or CR-LDP do.
> 
> None of the current MPLS signaling protocols provide a way to specify
> delay characteristics as part of QoS.  ATM's QoS allows signaling of
> delay and delay variation.  RSVP's ADSPEC object allows the collection
> of delay information, but there is no way to request that the network
> try to establish an LSP that conforms to particular delay
> characteristics.
> 
> Delay information is important for circuit-emulation and for real-time
> streaming applications (like voice/video).
> 
> Of course, delay factors are much less of a problem today (with
> extremely fast backplanes and OC-x interfaces) than they were in the
> recent past (with slower backplanes and DS-x interfaces), but I don't
> think we're yet at the point where they can be completely ignored.
> 
> I think there are still some applications where delay and delay
> variation are important even on today's hardware.
> 
> Of course, there's no reason why delay characteristics 
> couldn't be added
> to either RSVP or CR-LDP in the future.
> 
> -- David
>

---

From: "Donkin, Richard" <[email-masked]>
Date: Thu, 19 Apr 2001 18:14:09 +0100

> From: Geoff Bennett [mailto:[email-masked]]
...
> ...  In other words, I fully accept that IP VPNs should

Good to hear :)

> 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".  

Many operators are initially interested in the VPN service, i.e. isolational
security - QoS/CoS is seen as a supplement, particularly since it requires
CE management, and is therefore harder to scale, and requires
customer-specific classification/marking, which means more involvement with
customer requirements than a non-CoS VPN service.  In other words, something
like today's successful Frame Relay services, but with better provisioning
scalability for the provider, and the option of adding QoS/CoS services on
top.

> 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...
> 
> c: An over-provisioned stat mux service (eg. IP), which is also expensive
> in the long term.

I'm not clear about the current market for hard-QoS services (partly because
of the CoS factors above, plus the extra QoS parameters that must be
specified, again with customer input), but MPLS TE + CoS features does
enable firmer QoS than currently possible with IP alone. Comparison with ATM
QoS is probably a religious issue, and left as an exercise to the reader... 

> confidential information" responses.

Information on profitability is of course hard to come by, and I am on the
technical side not business, but I don't see why MPLS VPNs cannot be more
profitable than the equivalent Frame Relay services, given better
scalability, simpler provisioning (particularly if non-CoS), etc.  In fact,
MPLS VPNs can be delivered as FR services, e.g. AT&T's 'IP enabled Frame
Relay' which is really an MPLS VPN service internally.

Cheers,

Richard

---

From: Geoff Bennett <[email-masked]>
Date: Fri, 20 Apr 2001 08:55:54 +0100

Hi Prabhu,

>Your generalization about "loss making Internet Services" is

Yes, this is a foolishness I share with quite a lot of financial analysts :-)

>do).  I think it is fair to say they are quite profitable 

UUNET's success has a lot to do with hiring top notch staff, and also
having a flexible strategy that takes into account emerging technologies.
I'm a great admirer actually because they have been amongst the more
aggressive carriers in terms of MPLS piloting.

BUT...there is a big difference between wholesale and retail IP sales.  I'm
talking about IP Services, not raw bandwidth.

You need to be aware of the regulatory differences between the US and the
rest of the world.  While we are all in various stages of deregulation,
only in the US did the Telecommunications Act create a legal framework of
IXCs, ILECs and CLECs.

In contrast in Europe, there are "carriers' carriers", sure, but very often
these businesses mix in the notion of retail services, as well as
wholesale.  In general most people would agree that wholesale bandwidth
operation has historically been more profitable than retail.  In fact in
some cases the wholesale business is profitable enough to offset the losses
from retail and allow the company to demonstrate overall profitability.
This was helped by generous vendor financing during the "happy time".  The
problem is that a wholesale market can only maintain price (or
profitability) levels while its retail customers are able to stay in
business, and that situation is now coming into question.

>that do not publicly break out the P+L of each division.

You must have access to information that I don't.  Where the P&Ls are
combined, isn't this information confidential?  One of the sources of
debate in this area is that it's so difficult to substatiate these sort of
claims, isn't it?

>today, why in the world would they want to do it over ATM 

No reason really...except that ATM is the infrastructure that's running
today just fine...and supports the services the SPs need in order to be
profitable.

These days, if your MPLS vendor declines to buy their equipment for you,
then ATM is a great alternative as you can demonstrate a real ROI within a
sensible timescale.

Please forgive me if I appear to be bashing MPLS...I don't intend to.  My
point is that claims are being made about the technology that are rather
exaggerated.  This kind of hype ultimately hurts any technology (history
teaches us this about FDDI, ISDN, SMDS, ATM, ADSL, etc.).

MPLS could be as good as ATM one day.  In fact it could be so much better
because MPLS is not tied to a single underlying technology.

Cheers,
Geoff

================================================================
Geoff Bennett                             								Tel: (33) 497 21 43 62
Director of Technology, OCTO               						Fax: (33) 497 21 43 50
Marconi
Gaia - Bat. E                           					email: [email-masked]
BP 123
06903 SOPHIA ANTIPOLIS
FRANCE
================================================================

---

From: Geoff Bennett <[email-masked]>
Date: Fri, 20 Apr 2001 09:09:57 +0100

Hi Richard,

>> make more money than a basic Internet service.

Even though they make more money than "best effort" IP, it's still not
clear that ISPs are actually operating at a profit.  I think that Prabhu
Kavi's post highlighted the difficulty of getting down to the true state of
affairs here.  I think I'm right in saying that all independent, pure ISPs
(not the ones who are becoming ASPs) operate at a loss.  Wholesale business
can be profitable if they are well run.  Where wholesale and retail are
mixed, the accountants can shuffle the numbers from one column to another,
but the detailed breakdown in confidential.

If anyone wants to confirm this, you can stump up the cash for Infonetics'
roll call of European ISPs (http://www.infonetics.com).  This lists
services provided, and the revenues.  It's not comprehensive, there are
only 70 companies on the report and there are at least three times that
number of SPs in Europe alone.

>Relay' which is really an MPLS VPN service internally.

I agree.  I just haven't seen the figures broken out to prove it yet.  The
initial implementations of MPLS VPNs seem to be very admin-intensive, while
the NMS tools for Frame Relay and ATM VPNs are very well established.

Cheers,
Geoff

---

From: "Kavi, Prabhu" <[email-masked]>
Date: Fri, 20 Apr 2001 08:50:55 -0400

Geoff,

All of the components needed to provide QoS with MPLS are available
today.  That is why I asked why ATM switches were needed.  Just 
to review, here are the major components needed for QoS:

	1. Per-class of service bandwidth reservation
	2. Line-rate classification & forwarding
	3. Policing
	4. Non-blocking switch fabric
	5. Per-class of service congestion control 
	6. Queueing discipline that allows both pure priority and WFQ

To a large extent, IP routers are close to implementing numbers
2-6.  MPLS originally only provided bandwidth reservation on 
a single class of service.  Now it is being extended to multiple
classes, solving #1.   Today, there are multiple implementations
of #1 that are proprietary, but recent Internet Drafts are moving
these towards interoperable standards.

Now, ISPs an choose how much of this they want.  Some want two 
classes, some want four, and some are happy with best-effort IP 
services.  Almost none of them want the full complexity of ATM 
QoS (like its per-VC queueing).

Prabhu

> Sent: Friday, April 20, 2001 3:56 AM
> To: Kavi, Prabhu; Donkin, Richard; MP LS; [email-masked];
> [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 20 Apr 2001 09:01:42 -0400

There is some effort in the MPLS Forum to define VoMPLS for a class of
problems that are best described as severe bandwidth restrictions on
the MPLS link.  It trades off incompatibility with every other
VoXXX for link efficiency.  That spec is getting close to being
finished.

End-to-End delay is currently limited by routers - switches don't
add significant delay.  We can pretty easily build 30 ms end to end
systems using ATM switches.  Router delays are typically much longer,
but then again, some things that are called routers are really
switches, and some real routers have so much hardware that they
don't add much delay, especially for a media stream (which gets to
use cached information effectively).  Still in all, if you see
traceroute giving you 200 ms RT times, better have long tails on
your echo cancel!

Putting a bound on delay would be nice, but I don't see routers
implementing that any time soon.

Brian 

-----Original Message-----
From: Naidu, Venkata
To: Charlap, David; [email-masked]; Rosen, Brian
Cc: [email-masked]'
Sent: 4/19/01 2:39 PM
Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI??

Hi David

Please look at the Voice over MPLS framework document:
http://www.alternic.org/drafts/drafts-k-l/draft-kankkunen-vompls-fw-01.p
df

-Venkata Naidu

---

From: "Donkin, Richard" <[email-masked]>
Date: Fri, 20 Apr 2001 11:01:18 +0100

> Sent: 20 April 2001 09:40
> To: HANSEN CHAN
> Cc: Donkin, Richard; MP LS; [email-masked]; [email-masked]
> 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.

This is quite true - I have yet to see anyone doing hard QoS in a highly
scalable way.  Back in the mid-Nineties, there was much talk of public ATM
networks providing SVCs to customers, but this did not materialise, and the
same has happened with RSVP in the IP world.
 
> 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.

The real advantage here is application signalling of QoS, connection
orientation is just the simplest way to implement this - if such signalling
can interface with a connectionless core (see the RSVP to DiffServ mapping
work in the IETF), you can get the best of both worlds.  Of course, building
such a network is still a research topic, involving bandwidth brokers that
make admission control decisions for the DiffServ core.  The RSVP community
is also working on scalability improvements (in router state and signalling
overhead), which may help in this area through aggregation.

There are very few applications that can generate ATM or RSVP signalling -
Microsoft provides a GQoS API in Windows 2000 that addresses this, but it's
not clear how many applications use this (and many of them will just signal
the application + user identity, allowing a policy server to assign a
DiffServ marking rather than a hard QoS).  Until we have smarter middleware,
or network gateways that generate such signalling, this chicken and egg
problem (no apps, so no hard QoS networks, so no apps) will probably
continue.
 
> 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).

I don't think you need to overprovision the core network if you are using
variable size PDUs - as long as you fragment large packets/frames at the
link layer on lower speed links, the higher speed links will take care of
themselves (assuming a reasonable upper bound on PDU size).

This is now somewhat off the topic of MPLS, but in theory you could have a
mapping from flow-based RSVP into RSVP-TE so I guess there is some relevance
to MPLS in the longer term if this can be worked out.  In practice, most
people seem to be building CoS networks with MPLS, and would be more
interested in mapping per-flow RSVP onto DiffServ and MPLS CoS, mediated by
a bandwidth broker for the MPLS/DiffServ domain.

Richard

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 20 Apr 2001 11:11:15 -0400

Hi Eric

> > 
> > many people are more concerned about having a bounded
> > delay than they are about having a bounded delay variation.
> > And with a bounded delay, you get bounded delay variation
> > for free.

I am not quite convinced by this! I looked at many 
pointers, esp, IETF IPPM working group. Why is delay variation
is not as important as delay in delay sensitive applications?
And more over, how can we get a bounded delay variation
with a bounded delay?

By looking at the:
section 3.2 of
http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt and
http://carmen.cselt.it/papers/iss2000-ipdv/paper/ipdv.html

Still so much research in going on in IP to make IPDV work

Please let me know how did you came to the above conclusion

-Venkata Naidu
--
http://www.geocities.com/kvsnaidu

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 20 Apr 2001 11:35:48 -0400

> Eric,
> 
> I interpreted David's statements to mean that you can get 
> completely bounded delay with variable size packets.  David,
> correct me if I am wrong.

ATM established that cells, which are a set of frames
that are all the same size, are preferred because they
help to eliminate unacceptable "delay variability". In
reality, the fact that ATM cells are short is more 
important than the fact that they're all the same size.

The key factor in controlling delay is to control how
long each cell - or frame - occupies the transmission
facilities. The time that the cell or frame occupies the
line - which we'll call "packet time" - is directly related
to the "packet length" and inversely related to the
transmission speed.

In fairness, we should mention that the maximum
packet size is at least as important as the fixed size for
controlling delay. That is, a frame-based network with
a small maximum packet size can offer the same
packet times as a cell-based network with equal
maximum packet size.

Thanks & Regards
Venkata Naidu

> For example, a commonly used MTU of 1500 bytes requires only
> 5 microseconds of transmission time on an OC-48.  Therefore
> it is possible to create a queueing mechanism where a high
> priority packet is at most 5 microseconds away from the 
> start of transmission. Queuing points in the rest of the 
> system (if any) can be handled in a similar fashion.
> 
> Implementations of these systems might not be as far away
> as you think.
> 
> Prabhu
> 
> 
> > From: Eric Gray [mailto:[email-masked]]
> > Sent: Friday, April 20, 2001 8:39 AM
> > To: David Charlap
> > Cc: [email-masked]
> > David,
> >     I'm sure some smart person or another has written a paper
> > on this, but I don't have the time to do a full-blown literature
> > search right now.  While what you are saying is technically
> > true, I believe it has very little applicability in practice.
> > You can see that this works by imagining that an implementation
> > might treat MTU propagation time exactly the same way that ATM
> > treats cell propagation time.
> > 
> >     But this is very ugly.  It is so coarse that many would be
> > hard pressed to consider it a useful guarantee.  It also seems
> > to require deliberately inserting latency (N times an MTU
> > propagation time) for all affected traffic (to allow for packet
> > shuffling to accomodate the guarantee).  And it would be
> > very difficult to allocate forwarding resources efficiently and
> > still deliver guaranteed delay variation deterministically.
> > 
> >     Without making any moral judgement about why it is so,
> >     My opinion: there are two models here and trying to make
> > technologies support both models may not be a good idea.
> > 
> > --
> > Eric Gray
> > 
> > You wrote:
> > 
> > > Eric Gray wrote:
> > > >
> > > >     You can't exactly do ATM style QoS over non-ATM media.
> > > >
> > > >     The thing that allows an ATM switch to contemplate delay
> > > > variation separately from delay is the fact that ATM switches
> > > > switch data in fixed size chunks.  When the size of data chunks
> > > > can vary, the only practical way to control delay 
> variation is to
> > > > try to control delay.  Therefore, with IP packets on non-ATM
> > > > media, you can't even begin support two knobs for delay and
> > > > delay variation.  So why would you undertake to add complexity
> > > > by trying?
> > >
> > > Variable-size frames don't make it impossible.  It just 
> > means you are
> > > forced to work with a coarser granularity (defined by your 
> > configured
> > > MTU size.)
> > >
> > > -- david

---

From: [email-masked]
Date: Fri, 20 Apr 2001 11:21:30 +0100

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

> 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.
> 
> can aggregate things nicely, but in my mind this is not QoS, 
> it's CoS.  The
> installation).  I know this has been discussed, but is at a 
> very early stage.
> 
> fixed-PDU technology will have the edge over a variable PDU 
> technology when
> At 11:53 19/04/01 -0400, HANSEN CHAN wrote:
> >> is up to the user), or from "perceived service 
> enhancement".  The latter
> >I agree with your points above. However, I don't think there 
> is anything
> stop MPLS implemented with a hard QoS mechanism like ATM
> infrastructure
> (queuing and scheduling) can achieve the same level, if
> >not better QoS.
> >
> >Cheers,
> >Hansen
> >
> >-------