[j-nsp] Policer/Scheduler/Leaky Bucket

[Saku Ytti]

First thanks to Robert O'Hara for his off-list help. 

I've been trying to search in-detail information about above subjects
from www.juniper.net but I'm still not 100% sure if we can do certain
QoS related queuing. So instead of asking ambiguous questions I'll
give configuration examples of IOS, what I'm asking if same effects
can be achieve in JunOS. 

5.2 Policing                                                                    

In order to control the load of assured part of the traffic in the
network, all traffic that enters the network needs to be policed at
CE-PE interfaces of a PE for conformance with the traffic description of
each subscribed service class.  If a site has not subscribed to a
particular service class, then all traffic in that class needs to be
discarded at the CE-PE interface of a PE.                                       

As an example on policing, below is a Cisco IOS (12.2T or newer) policer
configuration of a CE-PE interface of a PE for a customer that has
subscribed to AD service at 512 Kbps and AR service at PIR of 10 Mbps
and CIR of 2 Mbps:                                                              

class-map match-all low-delay-traffic
  match ip precedence 5
  
policy-map ad-512Kb-ar-10Mb
  class low-delay-traffic
    police cir 512000 bc 1000
      conform-action transmit
      exceed-action dro
  class class-default
    police cir 2000000 bc 10000 pir 10000000 be 100000
      conform-action set-prec-transmit 1
      exceed-action set-prec-transmit 0
      violate-action drop

interface customer-x
  service-policy input ad-512Kb-ar-10Mb

Another example is a customer who has subscribed to AD service at 2 Mbps
and to BE service at 10 Mbps:

policy-map ad-2Mb-be-10Mb
  class low-delay-traffic
    police cir 2000000 bc 1000
      conform-action transmit
      exceed-action drop
  class class-default
    police cir 10000000 bc 100000
      conform-action set-prec-transmit 0
      exceed-action drop

interface customer-y
  service-policy input ad-2Mb-be-10Mb

 Note that the CE-PE interface of a PE can be any physical or logical
 interface.  Examples of logical interfaces are Ethernet VLANs, FR or ATM
 VCs, MPLS LSPs, as well as GRE and L2TPv3 tunnels.

 5.3 Queuing

 In order to assure QoS for the assured part of traffic, the network
 nodes must queue the packets according to their traffic class and, in
 case of AR traffic, drop precedence.  This applies to all interfaces of
 the network and especially to CE-PE interfaces of both the CE and PE,
 which usually contribute the most to delay and packet loss.

 For minimal latency, AD traffic is placed in a separate, strict priority
 queue.  All other (AR and BE) traffic is placed in another queue where
 assured (precedence 1) part of the traffic is protected from non-assured
 (precedence 0) part by discarding all non-assured packets before
 starting to discard any assured packets.

 Below is an example Cisco IOS queuing configuration for PE-PE and PE-P
 interfaces:

 class-map match-all ad
   match ip precedence 5
 
 policy-map output-policy
   class ad
     priority percent 30
   class class-default
     bandwidth remaining percent 100
     random-detect
     random-detect precedence 0   32    127    10
     random-detect precedence 1   128    4096  10
 
 interface trunk-z
   service-policy output output-policy

 It guarantees that 30% of the link bandwidth is available for the strict
 priority queue serving AD traffic.  All remaining bandwidth is available
 for the AR and BE (precedence 0 and 1) traffic.  Discarding of
 precedence 0 packets starts when 32 packets is in the queue and all
 precedence 0 packets are discarded when the queue lenght increases to
 127 packets.
 The same queuing configuration is also used on the CE-PE interface of a
 CE. On PE-CE interfaces of a PE, the aggregate traffic needs also to be
 shaped to the subscribed rate unless the customer has a dedicated
 physical interface in the PE, which has the same rate as the subscribed
 rate. With shaping the configuration of the CE-PE interface of a PE
 becomes:                                                                        
 interface customer-x (physical or logical)
   service-policy output output-policy
   traffic-shape rate <peak rate>
 
 where <peak rate> is the subscribed aggregate rate.

 5.4  Marking of Layer 2 Packets

 When an IP packet is sent out to a Layer 2 interface, the precedence
 field value of the IP packet needs to be mapped to Layer 2 QoS field
 (Ethernet User Priority, MPLS Exp, GRE IP Prec or L2TPv3 IP Prec).  In
 order to avoid multiple copies of policy map configurations, the mapping
 from IP Precedence to Layer 2 QoS field should be configurable on
 interface type basis rather than as part of a policy map.                       
-- 
  ++ytti