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
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