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

From: CATANZARITI Sergio FTR&D/TI <[email-masked]>
Date: Tue, 26 Sep 2000 11:18:54 -0700

I would like to be back to my original question. That was how I will map, in
a semantically compatible way, the COS-type values of Tspec/FlowSpec with
the DS classes. Okay, assuming that I have clear the first case, mapping DS
classes in the IntServ service types, (of course it is a joke... this
presumption of understanding), for the second case, how to map COS-type
values to DS classes, I do not think that it is a customization/local
configuration choice. Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt)
says...
Paragraph 5.6
>>When processing a path (respectively Resv) message for an E-LSP or an
L-LSP using the COS service, a Diff-Serv capable LSR must ignore the value
of the COS field within a COS SENDER_TSPEC (respectively a COS FLOWSPEC).
So, I guess that, when we (Diff Serv Routers) process RSVP/PATH messages
with COS-type TSpec/FlowSpec for (L or E type) LSPs carrying DS class
trunks, the choice on how to implement service treatments is not given by
COS values but EXP and/or label value. So, I do not worry about values
mapping at all.
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:	David Charlap [SMTP:[email-masked]]
> Sent:	Tuesday, September 26, 2000 7:34 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: CR-LDP traffic parameter TLV and RSVP
> 
> 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.)
> > 
> > This is a unique idea.  How does the router at the edge do WFQ or
> > implement the three drop preferences for an AF class?  :-)
> 
> 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

---

From: David Charlap <[email-masked]>
Date: Tue, 26 Sep 2000 14:28:56 -0400

CATANZARITI Sergio FTR&D/TI wrote:
> 
> I would like to be back to my original question. That was how I will
> map, in a semantically compatible way, the COS-type values of
> Tspec/FlowSpec with the DS classes. Okay, assuming that I have clear
> the first case, mapping DS classes in the IntServ service types, (of
> course it is a joke... this presumption of understanding), for the
> second case, how to map COS-type values to DS classes,

You really can't.  There is no defined meaning for COS-type values other
than zero (best effort).  Any other value may be ignored, rejected, or
handled in a way you don't want.

It's really not a good idea to use non-zero values for the COS-type,
unless you know precisely what your switch's implementation will do with
it.

> I do not think that it is a customization/local configuration choice.
> Indeed, the draft (dratf-ietf-mpls-diff-ext-07.txt) says...
> 
> Paragraph 5.6
> When processing a path (respectively Resv) message for an E-LSP or
> an L-LSP using the COS service, a Diff-Serv capable LSR must ignore
> the value of the COS field within a COS SENDER_TSPEC (respectively a
> COS FLOWSPEC).

Recognizing the fact that no classes other than zero have any standard
definition.

> So, I guess that, when we (Diff Serv Routers) process RSVP/PATH
> messages with COS-type TSpec/FlowSpec for (L or E type) LSPs carrying
> DS class trunks, the choice on how to implement service treatments is
> not given by COS values but EXP and/or label value. So, I do not worry
> about values mapping at all.

Sounds right to me.

-- David

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Sep 2000 23:58:44 -0400

In message <[email-masked]>
> COS values but EXP and/or label value. So, I do not worry about values

Sergio,

My strong recommendation is don't use COS if you want useful QoS!

draft-ietf-mpls-diff-ext-05.txt:

  1.6 Bandwidth Reservation for E-LSPs and L-LSPs

   Regardless of which label binding protocol is used, E-LSPs and
   L-LSPs may be established without bandwidth reservation or with
   bandwidth reservation.

   Establishing an E-LSP or L-LSP with bandwidth reservation means that
   bandwidth requirements for the LSP are signaled at LSP establishment
   time. Such signaled bandwidth requirements may be used by LSRs at
   establishment time to perform admission control of the signaled LSP
   over the Diff-Serv resources provisioned (e.g. via configuration,
   SNMP or COPS) for the relevant PSC(s). Such signaled bandwidth
   requirements may also be used by LSRs at establishment time to
   perform adjustment to the Diff-Serv resources associated with the
   relevant PSC(s) (e.g. adjust PSC scheduling weight).

   Note that establishing an E-LSP or L-LSP with bandwidth reservation
   does not mean that per-LSP scheduling is necessarily required. Since
   E-LSPs and L-LSPs are specified in this document for support of
   Differentiated Services, the required forwarding treatment
   (scheduling and drop policy) is defined by the appropriate Diff-Serv
   PHB. This forwarding treatment MUST be applied by the LSR at the
   granularity of the BA and MUST be compliant with the relevant PHB
   specification.

   When bandwidth requirements are signaled at establishment of an
   L-LSP, the signaled bandwidth is obviously associated with the
   L-LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform
   admission control may perform admission control over Diff-Serv
   resources which are dedicated to the PSC (e.g. over the bandwidth
   guaranteed to the PSC through its scheduling weight).

   When bandwidth requirements are signaled at establishment of an
   E-LSP, the signaled bandwidth is associated collectively to the
   whole LSP and therefore to the set of transported PSCs. Thus, LSRs
   which use the signaled bandwidth to perform admission control may
   perform admission control over global resources which are shared by
   the set of PSCs (e.g. over the total bandwidth of the link).

   Examples of scenarios where bandwidth reservation is not used and
   scenarios where bandwidth reservation is used are provided for
   information in APPENDIX B.

   [...]

   The above is summarized in the following table:

           Path Message  LSP type
    Service  DIFFSERV
              Object

     GS/CL     No        E-LSP + preconf mapping + bandw reservation
     GS/CL   Yes/E-LSP   E-LSP + signaled mapping + bandw reservation
     GS/CL   Yes/L-LSP   L-LSP + bandw reservation
     COS       No        E-LSP + preconf mapping + no bandw reservation
     COS     Yes/E-LSP   E-LSP + signaled mapping + no band reservation
     COS     Yes/L-LSP   L-LSP + no bandw reservation

   Where:
        - GS stands for Guaranteed Service
        - CL stands for Controlled Load
        - COS stands for COS service

Use bandwidth reservation (use service type CL with a tspec giving the
bandwidth reservation amount).  Don't use COS service.

  B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control

   Consider the case where a network administrator elects to:
     - have Diff-Serv resources entirely provisioned off-line (e.g. via
       Command Line Interface, via SNMP, via COPS,...)
     - use L-LSPs
     - have Constraint Based Routing performed separately for each PSC,
       where one of the constraints is availability of bandwidth from
       the bandwidth allocated to the relevant PSC.

   In that case, L-LSPs would be established with signaled bandwidth.
   The bandwidth signaled at L-LSP establishment would be used by LSRs
   to perform admission control at every hop to ensure that the
   constraint on availability of bandwidth for the relevant PSC is met.

  B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and
  per-PSC Resource Adjustment

   Consider the case where a network administrator elects to:
     - use L-LSPs
     - have Constraint Based Routing performed separately for each PSC,
       where one of the constraints is availability of bandwidth from
       the bandwidth allocated to the relevant PSC.
     - have Diff-Serv resources dynamically adjusted

   In that case, L-LSPs would be established with signaled bandwidth.
   The bandwidth signaled at L-LSP establishment would be used by LSRs
   to attempt to adjust the resources allocated to the relevant PSC
   (e.g. scheduling weight) and then perform admission control to
   ensure that the constraint on availability of bandwidth for the
   relevant PSC is met after the adjustment.

I don't know how this could be more clear.

"Don't use COS" is my pesonal advice.  The spec supports COS.  I just
don't think it provides a useful service.

Curtis