Subject: mapping to ATM switching Hardware

From: "Kainia Cloutier" <[email-masked]>
Date: Wed, 27 Sep 2000 20:06:12 -0700

My dear MPLS colleagues,

I'm currently in London, attending the MPLS Next Generation Networking
conference. I came to this conference with one objective: finding out
how to map an LSP to specific ATM switching hardware, while using
RSVP-TE. For the last several weeks, I read RFCs 2205, 2210, 2212 and
several IETF drafts and still couldn't find one paper describing "an
edge LSR, sending a path message with these parameters set in the ADSPEC
and FLOWSPEC object, will receive, from a downstream node,  an ATM CBR
label mapping". (and so on and so forth for RT-VBR, NRT-VBR, UBR label
mappings).

Sounds easy doesn't it? After all, the CR-LDP IETF draft covers this in
only one page (appendix B).

After asking several questions to some expert speakers at the
conference, I was told that the reason I can't find the answer to my
question is not, because I didn't find the appropriate IETF draft, but
because this has not been addressed.

Moving forward, shouldn't this issue be addressed to ensure proper
multi-vendor QoS interoperability within a network CORE? After all, if
the CR-LDP draft covers this in one page... couldn't we have the same
guidelines for when a SP will deploy a multi-vendor MPLS CORE with
RSVP-TE?

Kind Regards,
Kainia Cloutier
Alcatel.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Sep 2000 23:00:40 -0400

> label mapping". (and so on and so forth for RT-VBR, NRT-VBR, UBR label

QoS is supported with the services defined in the diff-serv WG and to
the extent that diff-serv services such as EF, AF, etc can be mapped
onto ATM you have compatibility with the legacy ATM devices.

Apparently the experts you talked to failed to inform you that
draft-ietf-mpls-diff-ext-07 has gone through last call and will become
an RFC.  It maps LSPs onto services defined in diff-serv.  Mapping
these diff-serv services onto ATM is also defined, though three drop
preferences of AF doesn't map exactly to ATM and few ATM switches do
RED (probably none), but that may have been their shortsightedness.
[I can remember going to Fore in 1994 and telling them they needed to
forget this UBR, VBR, ABR stuff and do RED.]

Curtis

ps- There has been little or no effort to preserve what was regarded
as bad ideas and the ATM traffic management was regarded at the time
as one of those ATM bad ideas (and they still are regarded that way).

---

From: David Charlap <[email-masked]>
Date: Thu, 28 Sep 2000 10:46:45 -0400

Curtis Villamizar wrote:
> Kainia Cloutier writes:
>>
>> I'm currently in London, attending the MPLS Next Generation
>> Networking conference. I came to this conference with one objective:
>> finding out how to map an LSP to specific ATM switching hardware,
>> while using RSVP-TE. For the last several weeks, I read RFCs 2205,
>> 2210, 2212 and several IETF drafts and still couldn't find one paper
>> describing "an edge LSR, sending a path message with these parameters
>> set in the ADSPEC and FLOWSPEC object, will receive, from a
>> downstream node, an ATM CBR label mapping". (and so on and so forth
>> for RT-VBR, NRT-VBR, UBR label mappings).

Strangely enough, I haven't been able to locate an RFC or draft that
maps IntServ-style QoS specs onto ATM-style.  Which does strike me as
odd.

> onto ATM you have compatibility with the legacy ATM devices.

It is also supported by signalling QoS vis IntServ objects.  Each ATM
switch that supports IntServ will have to reserve according to these
parameters.  If the hardware can only make reservations using ATM-style
parameters, then some form of mapping will be needed.

Although there are a number of RFCs that mention RSVP and ATM together
(2379, 2380, 2381 and 2381), a quick scan of their content didn't reveal
any standard formulae for converting one style of resource
representation to the other.

-- David

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Sep 2000 11:11:21 -0400

see rfc2381...

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Sep 2000 14:24:43 -0400

> representation to the other.

MPLS maps into diff-serv.  Diff-serv does not specify how to implement
a behavior, just the desired characteristics.  Forget intserv.  The
RSVP tspec in RSPV/TE just carries the reservation amount (a per PSC
usage is defined).  This and the PHB is all diff-serv needs.

If you think intserv is somehow important and if you think there is
good reason to specify mapping of intserv to ATM, write a draft and
take it to the ISSLL WG (intserv over specific link layers).
Apparently there wasn't enough interest in the combination of intserv
and ATM so far.

Curtis

---

From: John Wroclawski <[email-masked]>
Date: Thu, 28 Sep 2000 14:56:17 -0400

>Apparently there wasn't enough interest in the combination of intserv

Actually, this was done ages ago, in the RFC's he mentioned. The 
mapping RFC is quite detailed about how to do a reasonable job, but 
doesn't give a single "right" answer because there are tradeoffs to 
be made, and because "ATM", with all of its myriad QoS options, was 
hardly a single fixed target.

Intserv is primarily about QoS control for applications. Diffserv is 
about many things, including ISP-level differentiated QoS and, in 
some people's view, providing a useful building block for end-to-end 
app-level QoS. The notion that only one of these things is important 
might be a little short-sighted.

Cheers,
John