Subject: [Diffserv] RE: Mapping IP QoS Info to ATM QoS

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 14 Jun 2000 10:00:21 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> Hello,
> I have a doubt regarding mapping QoS attributes..
> 
> Attributes like Token Bucket Rate etc.. are being used in 
> RSVP and similar resource reservation techniques which are IP 
> based. If the link is ATM, how are these mapped to ATM QoS? 
> Is it implementation specific or are there any standards to 
> dictate this?

There is work in progress at the ATM Forum that addresses this issue, but it
hasn't made it to the approved specs folder of their web site, it seems.
Maybe someone who is still a member can provide more updated info.

With respect to diffserv compatibility, the general idea is to take two
possible approaches:

1. You use ATM like any other link layer, UBR, and literally apply the same
queueing solutions diffserv comes up with, at the ATM switches. This is sort
of the LANE philosophy, where ATM's own native capabilities are not used to
their fullest extent, but rather the IP solutions are layered on top of ATM,
and ATM emulates (to the extent possible) a connectionless broadcast LAN.

2. You rigorously map ATM CBR, VBR, etc. CoS to diffserv EF and AFxy. This
second strategy is presented only in an appendix, though.

Of course, #2 cannot at this stage be rigorously standardized, because
diffserv itself has no specific implementations quantified yet.

Bert
[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Shahram Davari <[email-masked]>
Date: Fri, 16 Jun 2000 13:56:59 -0700

This is OK according to AF-PHB RFC. The RFC says at least 2 drop precedence
are required. It also says you should map DP1-> CLP0, DP2&DP3->CLP1.

-Shahram

>From: Mohammed Atiquzzaman [mailto:[email-masked]]
>Sent: Friday, June 16, 2000 4:47 PM
>To: [email-masked]
>Cc: 'Grenville Armitage'; Manfredi, Albert E
>Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS
>
>
>An issue related to DiffServ-ATM mapping (in addition to
>the mapping of the services) is the mapping of the drop 
>precedences from
>DiffServ to ATM.  The question is, even if can map AF to VBR 
>or ABR, how do
>we map multiple drop precedences from the Assured Service to 
>only two drop
>precedence of ATM (ATM has only one CLP bit to indicate the drop
>precedence).
>
>Anyone has any thoughts or pointers to literature?
>
>Regards
>
>Mohammed Atiquzzaman       | Email: [email-masked]
>Department of Electrical & |        [email-masked]
>  Computer Engineering     | Voice: (937) 229 3183,
>University of Dayton,      |  (937) 229 3191 (sec), (937) 229 
>4974 (lab)
>Dayton, Ohio 45469-0226.   | Fax:   (520) 962 8422 or (937) 229 4529
>                           | 
>http://www.engr.udayton.edu/faculty/matiquzz/
>
>
>> From: [email-masked] 
>[mailto:[email-masked]]On Behalf
>> Of Manfredi, Albert E
>> Sent: Friday, June 16, 2000 4:20 PM
>> To: 'Grenville Armitage'
>> Cc: [email-masked]
>> Subject: RE: [Diffserv] Re: Mapping IP QoS Info to ATM QoS
>>
>>
>> > From: Grenville Armitage [mailto:[email-masked]]
>> >
>> > John Schnizlein wrote:
>> >
>> >  [ ... ]
>> >
>> > > Dan's "by whatever name" refers to the linguistic debate spawned
>> > > by the attempt to move a litte closer to service specification
>> > > named "behavior aggregate" and renamed "per domain 
>behavior" (PDB).
>> >
>> > That part I understand, but I still dont see why DiffServ needs
>> > to define services before anyone can figure out what ATM
>> > level services can usefully support particular DS PHBs.
>> >
>> > > While we are out here in the weeds, note that the tidy 
>lawn view of
>> > > this is as Brian said - ATM virtual circuits connect router hops
>> > > through a virtual link. And the link behavior is part of 
>the per-hop
>> > > behavior.
>> >
>> > Well, that's pretty much what I said in different words. IP PHB
>> > is DS PHB + link service class. So what's the question that cannot
>> > be answered by this approach?
>>
>> I'm going to assume that ATM is used in part or all of the 
>diffserv domain
>> and that the approach used is to map diffserv PHBs to ATM 
>CoSs, or vice
>> versa.
>>
>> What can be said, at this stage? As far as I can tell, not 
>much more than:
>>
>> 1. For EF, use CBR.
>>
>> 2. For AFxy, use VBR or ABR, or GFR.
>>
>> 3. For so-called best effort, use UBR.
>>
>> Does that tell you anything. For that matter, is it even 
>correct? I think
>> there is a lot more quantifying of services that needs to be 
>done before
>> anything meaningful can be said about mapping. It's possible that the
>> diffserv wg will never go to that level of definition.
>>
>> In my view, once (or if) diffserv determines what EF means 
>in terms of
>> packet drop probabilities, latency, and jitter, and what the 
>different AF
>> classes mean in terms of peak, avergage, and min bit rates, drop
>> probabilties, and latency, then once can start working out real
>> equivalencies in terms of the kind of QoS an ATM setup 
>message must demand
>> when serving a diffserv domain.
>>
>> Or vice versa.
>>
>> Or am I missing something?
>>
>> Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 16 Jun 2000 16:59:21 -0400

> precedence of ATM (ATM has only one CLP bit to indicate the drop

No, I don't think this is a problem.

The drop precedences of diffserv would _not_ be mapped to the CLP. They
would, I beliveve, be mapped to the cell drop ratio QoS of ATM, negotiated
during call setup. I think we're talking at different levels here.

Bert

---

From: Scott W Brim <[email-masked]>
Date: Fri, 16 Jun 2000 17:39:44 -0400

At 04:19 PM 06/16/2000 -0400, Manfredi, Albert E wrote:
>In my view, once (or if) diffserv determines what EF means in terms of
>packet drop probabilities, latency, and jitter, and what the different AF
>probabilties, and latency ...

>Or am I missing something?

PHBs don't mean anything in any of those terms, they're just PHBs.  All 
those terms are for services (or at least PDBs).

---

From: Mudassir Tufail <[email-masked]>
Date: Fri, 16 Jun 2000 15:12:06 -0700

A similar suggestion was to map AFs in a differentiated UBR service where a
"Virtual Class Selector IE" in the setup signaling message identifies the
priority of an AF flow. The selector value is based upon DSCP. However, drop
priority in DSCP was supposed to be carried by CLP bit.

Mudassir

> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Friday, June 16, 2000 1:59 PM
> To: [email-masked]'; [email-masked]

---

From: [email-masked]
Date: Mon, 19 Jun 2000 16:31:07 +0300

There has been an internet draft:
Mapping to ATM classes of service for Differentiated Services Architecture
http://www.ietf.org/internet-drafts/draft-ayandeh-diffserv-atm-00.txt
That draft has been expired.

ATM Traffic Management Specification af-tm-0121.000 July 1999
has for example added "Enhancements to Support IP Differentiated Services
and IEEE 802.1D over ATM" according 
http://www-comm.itsi.disa.mil/atmf/tm.html
Same document says also:
Traffic Management Specifications in Approval
TM v4.1 Addendum, Differentiated UBR 
"This specification defines the Differentiated UBR service category, which
is intended to provide ATM support of 
IP Differentiated Services (Diffserv) as defined in RFC 2474 and 2475 
IEEE 802.1D, Media Access Control (MAC) Bridges (also ISO/IEC 15802-3) 
The nature of the traffic is determined at the ingress to a network or
domain and each subsequent ATM switching point determines the Per Hop
Behavior (PHB) based on information added to the ATM cell header, referred
to as the Behavior Class Selector (BCS). PHBs are defined in RFCs 2474,
2597, and 2598."

I have no current status information on either of those specifications ?
Anyone following more closely those ATM forum specifications could
comment on that ?

> From: EXT Mohammed Atiquzzaman [mailto:[email-masked]]
> Sent: 16. June 2000 23:47
> To: [email-masked]
> > > > through a virtual link. And the link behavior is part 
> of the per-hop
> > > > behavior.
> > >
> > there is a lot more quantifying of services that needs to 
> be done before

---

From: [email-masked]
Date: Mon, 19 Jun 2000 16:54:20 +0300

Kalevi Kilkki from Nokia Research Center has proposed an
ATM traffic controlling scheme for both ATM and IP networks
which handles the drop precedences in similar ways on both
IP and ATM networks: SIMA concept. 

Kalevi Kilkki presented adding this drop precedence thing 
to ATM system at "Simple Integrated Media Access (SIMA)"
(http://www-nrc.nokia.com/sima/cost257.doc) paper at
COST257 TD(97) conference at  Espoo, May 1997.

That same SIMA concept is also designed to work with 
IP network and the concentration of the development of
the system is in IP networks nowadays. IP is nowadays
"the gorilla technology" and the ATM seems to be entring
the fading technology stage on my viewpoint.

There are plenty of SIMA related conference papers, 
many written by Dr. Kalevi Kilkki (the inventor of SIMA),
Dr. Jussi Ruutu and also papers which I have written with
with Mika Loukola available on-line at 
http://www-nrc.nokia.com/sima/confer.htm

  Tomi Engdahl

---

From: [email-masked]
Date: Mon, 19 Jun 2000 17:31:00 +0300

> From: EXT Grenville Armitage [mailto:[email-masked]]
> Sent: 16. June 2000 21:37
> To: John Schnizlein
> Cc: Dan Grossman; [email-masked]
> Subject: Re: [Diffserv] Re: Mapping IP QoS Info to ATM QoS
> 
> 
> 
> 
> John Schnizlein wrote:
> 	[..]
> > Since ATM services are end-to-end, and PHBs are not, it is necessary
> > to form an end-to-end (or at least edge-to-edge or cross-domain)
> > service level for comparison to the ATM service level.
> 
> But why? Perhaps I missed the question (which I thought was
> triggerd by someone saying the ATM Forum is waiting for DS
> services to be defined before it could figure out mappings
> from PHBs to VC service classes).  If I've gotten the question
> right, I dont see the above as a 'necessity'.

I don't see that necessuty either.

> 	[..]

I don't see a reason why DiffServ needs to find you how
certain service could be bets impelemnted with ATM before
defining anything ? The DiffServ system works on expectation
that there are transparent bit pipes or some transmission
channels which understand the DS PHBs between the DiffServ
routers. ATM CBR fullfills the bit pipe definition quite
well (on properly designed and performing ATM network).

Sto my viewpoint it is better idea to design sensible realizable
services for DiffServ without too much sticking and restricting
to the details of what the ATM system can provide and what
maps to ATM nicely. Who says that ATM will be here forever
as the IP without ATM networks are quicly going in.
If we are designing services which can be run on transparent
bit pipe, then we can run those on any such pipe,
no matter if it is ATM CBR connection, point-to-point 
Gigabit Ethernet, IP over SONET, IP directly to the fiber etc.

ATM hype has pretty much gone. ATM is widely deployed nowadays,
but the situation might change in the future. The ATM below
IP might there forever for various reasons (money, complexity, etc.).