Subject: RE: CR-LDP traffic parameter TLV and RSVP

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Fri, 22 Sep 2000 17:33:30 -0700

Hello,

I need a clarification in the context that you mentioned below, that is
setting up, through RSVP-TE, LSPs for Diff Serv trunks with both Diff Serv
and CoS object. What is the congruous relationship (if we need one
whatsoever) between the COS value (other than best effort) for the traffic
stream carried out in by the LSP and the diff serv PHBID/PSC objects of the
data flows going into the LSP?

Thanks,
Sergio

> --------------------------------------------------------------------
> Sergio Catanzariti
> Senior Project Manager, Technology Integration
> France Telecom R&D 
> 1000 Marina Boulevard Suite 300 
> Brisbane CA 94005
> Tel. 650-875-1526
> Fax. 650-875-1505
> email:[email-masked] 
> --------------------------------------------------------------------
> 
> 
> -----Original Message-----
> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Wednesday, September 13, 2000 9:15 AM
> To:	'Mark Dewey'; [email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: CR-LDP traffic parameter TLV and RSVP
> 
> Hi Mark,
> 
> For supporting Diffserv, a new Diffserv object/TLV is introduced for RSVP
> and CR-LDP respectively in "MPLS support of Diffserv draft". In case of
> RSVP, if the Diffserv object and the CoS object are not present the node
> should implement Intserv, however, the presence of each one indicates
> non-Intserv (Diffserv) implementation.
> 
> Regards,
> -Shahram
> 
> -----Original Message-----
> From: Mark Dewey [mailto:[email-masked]]
> Sent: Wednesday, August 30, 2000 1:55 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: CR-LDP traffic parameter TLV and RSVP
> 
> 
> Hi,
> 
>    I apologize for the wide distribution. I am not sure which mailing list
> 
> this question belongs to.
> 
>    I understand, in CR-LDP, the qos characteristics(e.g bandwidth) of an
> LSP
> 
> tunnel can be specified in traffic parameter (e.g CDR) TLV.
> 
> How is this value  specified in RSVP if it were used to establish a LSP 
> tunnel with qos characteristics?
> 
> 
> If sender TSPEC object is used, should the node implement integrated 
> services (CL,GS)?
> 
> Thanks,
> -Mark
> 
> 
> 
> 
> 
> 
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> Share information about yourself, create your own public profile at 
> http://profiles.msn.com.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 25 Sep 2000 17:24:59 -0400

In message <[email-masked]>
, CATANZARITI Sergio FTR&D/TI writes:
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_001_01C024F5.E8A3A4C0
> Content-Type: text/plain
> 
> Hello,
> 

If you are talking about COS in RSVP signaling, then my advice is
pretend it never existed and reread draft-ietf-mpls-diff-ext-07.
Assume that you will be signaling the amount of bandwidth per PSC
(using CL and considering only the sustained rate parameter in the
tspec) and setting aside resources (setting queue weights)
appropriately.  If paths change and the mix of PSCs changes so does
the proportional allocation of resource.

If you are talking about EXP and mistakenly calling is COS (which I
doubt anyone will still do :) then just reread
draft-ietf-mpls-diff-ext-07 since it is very clear how EXP is handled.

Curtis

---

From: David Charlap <[email-masked]>
Date: Mon, 25 Sep 2000 17:45:50 -0400

> pretend it never existed and reread draft-ietf-mpls-diff-ext-07.

Yes.  The CoS CType (of TSpec and FlowSpec) of RSVP-TE accomplishes
something different from what the MPLS-DiffServ draft is trying to
accomplish.

The RSVP CoS objects allow an entire LSP to be signalled for a specific
class.  The only class whose behavior is defined is class 0 - best
effort.  The meaning of all other classes (if any others are even
allowed in an implementation) are left up in the air - to be defined
either by vendors, by local administrative control, or an independant
signalling mechanism.

It is not possible to signal real QoS along with the class, because RSVP
only allows one TSpec per sender descriptor, and only one FlowSpec per
flow descriptor.

In other words, if you use CoS-type TSpecs and FlowSpecs, you will not
be able to signal QoS.  And vice versa.

If you try to use these classes as mappings for DiffServ classes, then
you will be forced to create a separate LSP for each class.  This may
cause scalability problems on a real-world network that makes extensive
use of DiffServ and MPLS together.

(And if you want to only use one LSP per DiffServ class, then you don't
have to signal the class at all - you can just signal QoS for a bunch of
LSPs and let the edge routers do all the DiffServ work.)

-- David

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 25 Sep 2000 21:32:02 -0400

> LSPs and let the edge routers do all the DiffServ work.)

This is a unique idea.  How does the router at the edge do WFQ or
implement the three drop preferences for an AF class?  :-)

Curtis

---

From: David Charlap <[email-masked]>
Date: Tue, 26 Sep 2000 10:33:40 -0400

Curtis Villamizar wrote:
> David Charlap writes:
>>
>> (And if you want to only use one LSP per DiffServ class, then you
>> don't have to signal the class at all - you can just signal QoS for a
>> bunch of LSPs and let the edge routers do all the DiffServ work.)
> 

It doesn't.  It picks IntServ parameters that approximate the QoS level
required for each DS class and uses them when signalling the tunnels. 
If the LSPs are signalled using the COS-type of TSpec and FlowSpec, then
the switches in the cloud will have to have some sort of agreement about
what the non-zero classes are supposed to mean.

All the edge router does on the data plane is use the DS bits to pick
which tunnel to forward the traffic into.  If the tunnels have different
QoS or priority levels, then the different DS classes will end up with
those levels as well.

In this setup, the MPLS cloud is not actually using DS at all - it's
simply mapping the DS classes onto tunnels have their own QoS/COS levels
that are signalled independantly of any DS signalling.

-- David