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

From: "HANSEN CHAN" <[email-masked]>
Date: Thu, 19 Apr 2001 11:53:39 -0400

> 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

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 13:44:24 -0400

> 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: "HANSEN CHAN" <[email-masked]>
Date: Thu, 19 Apr 2001 11:53:39 -0400

Geoff,

Cheers,
Hansen

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

---

From: Eric Gray <[email-masked]>
Date: Thu, 19 Apr 2001 14:34:34 -0400

David,

I believe the IP model for control of delay variation

is to control delay.  This approach has its own problems,

but there are complexities associated with having distinct

knobs for delay and delay variation and these complexities

will probably get in the way of building an implementation

that will work this way with IP and still be reasonably

scalable.  Also, there's a well known 'tax' associated with

the approach that ATM uses to control delay variation.  :-)

--

Eric Gray

delay characteristics as part of QoS.  ATM's QoS allows signaling
of

characteristics.

-- David

---

From: Geoff Bennett <[email-masked]>
Date: Thu, 19 Apr 2001 17:20:01 +0100

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.

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:
>
>
>> -----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.
>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: Geoff Bennett <[email-masked]>
Date: Fri, 20 Apr 2001 09:39:31 +0100

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:
>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

---

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

Hi Hansen,

Cheers,
Geoff

-------