Configuring Class of Service (CoS)


For interfaces that carry IPv4, IPv6, or MPLS traffic, you can configure class-of-service (CoS) features to provide multiple classes of service for different applications. On the router, you can configure multiple forwarding classes for transmitting packets, define which packets are placed into each output queue, schedule the transmission service level for each queue, and manage congestion using a Random Early Detection (RED) algorithm.

To configure CoS properties, include the following statements:

 [edit]  class-of-service {   classifiers {  type   classifier-name  {       import (  classifier-name  default);       forwarding-class  class-name  {         loss-priority (low  high) code-points [  alias   bits  ];       }     }   }   code-point-aliases {     (dscp  exp  ieee-802.1  inet-precedence) {  alias-name   bits  ;     }   }   drop-profiles {  profile-name  {       fill-level  percentage  drop-probability  percentage  ;       interpolate {         drop-probability  value  ;         fill-level  value  ;       }     }   }   forwarding-classes {     queue  queue-number   class-name  ;   }   forwarding-policy {     next-hop-map  map-name  {       forwarding-class  class-name  {         next-hop [  next-hop-name  ];       }     }     class  class-name  {       classification-override {         forwarding-class  class-name  ;       }     }   }   interfaces  interface-name  {       scheduler-map  map-name  ;       unit  logical-unit-number  {         classifiers {           (dscp  exp  ieee-802.1  inet-precedence) (  classifier-name  default);         }         forwarding-class  class-name  ;         rewrite-rules {           (dscp  exp  inet-precedence) (  rewrite-name  default);         }       }     }   }   rewrite-rules {     (dscp  exp  inet-precedence)  rewrite-name  {       import (  rewrite-name  default);       forwarding-class  class-name  {         loss-priority (low  high) code-point (  alias   bits  );       }     }   }   scheduler-maps {  map-name  {       forwarding-class  class-name  scheduler  scheduler-name  ;     }   }   schedulers {  scheduler-name  {       transmit-rate (  rate  percent  percentage  remainder) <exact>;       maximum-buffer-delay (  milliseconds  percent  percentage  remainder);       priority (low  high);       drop-profile-map loss-priority (low  high) protocol (non-tcp  tcp  any)         drop-profile  profile-name  ;     }   } } 

Table 6.11 lists the RFCs that define the standards supported by certain aspects of the JUNOS CoS software.

Table 6.11. CoS Standards Supported by JUNOS Software
Standard Title
RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 2597 Assured Forwarding PHB Group
RFC 2598 An Expedited Forwarding PHB (see also draft-ietf-diffserv-rfc2598bis-01.txt)

The JUNOS software supports only two loss priorities and, by default, supports only one assured forwarding (AF) class, although you can configure more at the expense of other class types. Only IEEE 802.1p Layer 2 classification propagation mechanisms are currently supported. RFC 2983, Diffserv and Tunnels , is not supported.

Defining Code-Point Aliases

A code-point alias is a name you assign to a set of DiffServ code-point (DSCP) bits. When you configure classes and define classifiers, you can refer to the code points by these alias names. You can configure user -defined classifiers in terms of alias names . If the value of an alias changes, it alters the behavior of any classifier that references that alias. Table 6.12, Table 6.13, Table 6.14, and Table 6.15 list the default mappings between the bit values and standard aliases. For example, it is widely accepted that the alias for DSCP 101110 is expedited forwarding (ef).

To define a code-point alias, include the code-point-aliases statement:

 [edit class-of-service]  code-point-aliases {   (dscp  exp  ieee-802.1  inet-precedence) {  alias-name bits  ;   } } 
Table 6.12. Default DSCP Mappings for DiffServ Code Points
DiffServ Code Designator Mapping
ef 101110
af11 001010
af12 001100
af13 001110
af21 010010
af22 010100
af23 010110
af31 011010
af32 011100
af33 011110
af41 100010
af42 100100
af43 100110
be 000000
cs1 001000
cs2 010000
cs3 011000
cs4 100000
cs5 101000
Table 6.13. Default DSCP Mappings for MPLS EXP Code Points
DiffServ Code Designator Mapping
be 000
be1 001
ef 010
ef1 011
af11 100
af12 101
nc1/cs6 110
nc2/cs7 111
Table 6.14. Default DSCP Mappings for IEEE 802.1 Code Points
DiffServ Code Designator Mapping
be 000
be1 001
ef 010
ef1 011
af11 100
af12 101
nc1/cs6 110
nc2/cs7 111
Table 6.15. Default DSCP Mappings for Legacy IP Precedence Code Points
DiffServ Code Designator Mapping
ef 101110
be 000
be1 001
ef 010
ef1 011
af11 100
af12 101
nc1/cs6 110
nc2/cs7 111

Configuring Forwarding Classes

Forwarding classes control how packets are assigned to output queues. To assign each forwarding class to an internal queue number, include the forwarding-classes statement:

 [edit class-of-service]  forwarding-classes {   queue  queue-number class-name  ; } 

The default CoS configuration is based on queue number. The name of the forwarding class that shows up when the default configuration is displayed is the forwarding class currently associated with that queue. Following is the default configuration for forwarding classes:

 [edit class-of-service]  forwarding-classes {   queue 0 best-effort;   queue 1 expedited-forwarding;   queue 2 assured-forwarding;   queue 3 network-control; } 

If you reassign the forwarding-class names, the forwarding-class name best-effort appears in the locations in the configuration previously occupied by network-control , as follows :

 forwarding-classes {   queue 0 network-control;   queue 1 assured-forwarding;   queue 2 expedited-forwarding;   queue 3 best-effort; } 

In the current default configuration, only IP precedence classifiers are associated with interfaces, the only classes designated are best effort and network control, and schedulers are not defined for the expedited-forwarding or assured-forwarding classes. You must make a conscious effort to classify packets to the expedited-forwarding or assured-forwarding class and define schedulers for these classes.

If classifiers fail to classify a packet, it always receives the default classification, to the class associated with queue 0.

The number of queues depends on the hardware in the chassis. CoS configurations are inherently contingent on the number of queues on the system. Only two classes, best-effort and network-control , are actually referenced in the default configuration. The default configuration works on any platform.

CoS configurations that specify more queues than the platform can support are not accepted. The commit fails with a detailed message that states the total number of queues available.

Classifying Packets by Behavior Aggregate Class

The simplest way to classify a packet is to use behavior aggregate classification. The DSCP or IP precedence bits of the IP header convey the behavior aggregate class information. The information might also be found in the MPLS EXP bits or IEEE 802.1p CoS bits. Table 6.16 lists the default system classification scheme for the well-known DSCPs. Note that all af classes other than af11, af12, and af13 are mapped to best-effort , because RFC 2597 prohibits a node from aggregating classes. In effect, mapping to best-effort implies that the node does not support that class.

Table 6.16. Default Behavior Aggregate Classification
DSCP Forwarding Class PLP
ef expedited-forwarding Low
af11 assured-forwarding Low
af12 assured-forwarding High
af13 assured-forwarding High
af21 best-effort Low
af22 best-effort Low
af23 best-effort Low
af31 best-effort Low
af32 best-effort Low
af33 best-effort Low
af41 best-effort Low
af42 best-effort Low
af43 best-effort Low
be best-effort Low
cs1 best-effort Low
cs2 best-effort Low
cs3 best-effort Low
cs4 best-effort Low
cs5 best-effort Low
nc1/cs6 network-control Low
nc2/cs7 network-control Low
Other best-effort Low

To define new classifiers for all code-point types, include the classifiers statement:

 [edit class-of-service]  classifiers {   (dscp  exp  ieee-802.1  inet-precedence)  classifier-   name  {     import [  classifier-name  default];     forwarding-class  class-name  {       loss-priority (low  high) code-points [  alias   bits  ];     }   } } 

To assign the classification map to a logical interface, include the forwarding-class statement in the following configuration. The dscp classifier classifies all incoming IPv4 packets, while the exp classifier handles MPLS packet classification.

 [edit class-of-service interfaces  interface-name  unit  logical-unit-number  ] forwarding-class  class-name  ; classifiers {   (dscp  exp  ieee-802.1  inet-precedence) (classifier-       name  default); } 

Configuring Scheduling Policy Maps

You use scheduling policy maps to configure the forwarding classes that represent packet queues and associate them with physical interfaces. A scheduler configuration block specifies the buffer size, bandwidth, and priority for a queue. It also specifies the RED drop profile for packets that fall within specification and out of specification. To configure schedulers, include the schedulers statement:

 [edit class-of-service]  schedulers {  scheduler-name  {     transmit-rate (  rate  percent  percentage  remainder)       <exact>;     maximum-buffer-delay (  time  percent  percentage  remainder);     priority (low  high);     drop-profile-map loss-priority (low  high) protocol       (non-tcp  tcp  any)       drop-profile  profile-name  ;   } } 

After you define a scheduler, include it in a scheduler map to map a given forwarding class to a scheduler configuration:

 [edit class-of-service]  scheduler-maps {  map-name  {     forwarding-class  class-name  scheduler  scheduler-name  ;   } } 

Then associate the map-name with an output interface:

 [edit class-of-service]  interfaces {  interface-name  {     scheduler-map  map-name  ;   } } 

You must configure each forwarding class in turn . The following is the default set of schedulers and scheduler maps:

 [edit class-of-service]  schedulers {   network-control {     transmit-rate percent 5;     maximum-buffer-delay percent 5;     priority low;     drop-profile-map loss-priority low protocol-type any       drop-profile passive;     drop-profile-map loss-priority high protocol-type any       drop-profile aggressive;   }   best-effort {     transmit-rate percent 95;     maximum-buffer-delay 95;     priority low;     drop-profile-map loss-priority low protocol-type any       drop-profile passive;     drop-profile-map loss-priority high protocol-type any       drop-profile aggressive;   } } scheduler-map default {   forwarding-class best-effort scheduler best-effort;   forwarding-class network-control scheduler network-       control; } 

Configuring RED Drop Profiles

RED drop profiles are associated with the forwarding classes and loss priorities from the scheduler map you configured on the interface. To configure the drop profiles themselves , include the drop-profiles statement:

 [edit class-of-service]  drop-profiles {  profile-name  {     fill-level  percentage  drop-probability  percentage  ;     interpolate {       fill-level  value  ;       drop-probability  value  ;     }   } } 

Include either the interpolate statement and its options, or the fill-level and drop-probability percentage values. These two alternatives enable you to configure either each individual drop probability at up to 64 fill-level/drop-probability paired values, or a profile represented as a series of line segments. If you include the interpolate statement, you can specify more than 64 pairs, but the system generates only 64 discrete entries.

The line segments are defined in terms of the following graphical model: in the first quadrant, the x axis represents the fill level, and the y axis represents the drop probability. The initial line segment spans from the origin (0,0) to the point (<l1>, <p1>); a second line runs from (<l1>, <p1>) to (<l2>, <p2>) and so forth, until a final line segment connects (100, 100). The system automatically constructs a drop profile containing 64 fill levels at drop probabilities that approximate the calculated line segments. Figure 6.6 shows sample line graphs contrasting use of the segment percentages (on the left) and interpolated values (on the right).

Figure 6.6. Segmented and Interpolated Drop Profiles

graphics/06fig06.gif

The JUNOS software supports two packet loss priority (PLP) designations, low and high. The packet loss priority is used to determine the RED drop profile when queuing a packet. You can set it by configuring a classifier or policer.

Rewriting Packet Header Information

You can rewrite the packet header bits because the logical interface transmits the packet along with the forwarding class and PLP information associated with the packet. The rewrite-rules configurations define the mappings. Table 6.17 lists the default mappings.

Table 6.17. Default Packet Header Rewrite Mappings
Map to DSCP/EXP/IEEE/IP Map from Forwarding Class PLP Value
ef expedited-forwarding Low
ef expedited-forwarding High
af11 assured-forwarding Low
af12 (DSCP/EXP) assured-forwarding High
be best-effort Low
be best-effort High
nc1/cs6 network-control Low
nc2/cs7 network-control High

To configure a rewrite-rules mapping and associate it with the appropriate forwarding class and code-point alias or bit set, include the rewrite-rules statement:

 [edit class-of-service]  rewrite-rules {   (dscp  exp  inet-precedence)  rewrite-name  {     import (  rewrite-name  default);     forwarding-class  class-name  {       loss-priority (low  high) code-point  alias   bits  ;     }   } } 

To assign the rewrite-rules configuration to the output logical interface, include the following statements:

 [edit class-of-service]  interfaces {  interface-name  {     unit  logical-unit-number  {       rewrite-rules {         (dscp  exp  inet-precedence)  rewrite-rule-name  ;       }     }   } } 

Configuring CoS-Based Forwarding

See Chapter 8, "Routing Policy and Firewall Filters," on page 301.

CoS-based forwarding enables you to control next-hop selection based on a packet's class of service and, in particular, the value of the IP packet's precedence bits. For example, you might want to specify a particular interface or next hop to carry high-priority traffic while all best-effort traffic takes some other path. When a routing protocol discovers equal cost paths, it can pick a path at random or load-share across the paths either through hash selection or round robin . CoS-based forwarding allows path selection based on class. You can apply CoS-based forwarding only to a defined set of routes. To do this, include the cos-next-hop-map statement in a policy then statement. To apply a CoS next-hop map, include the forwarding-policy statement:

 [edit class-of-service]  forwarding-policy {   next-hop-map  map-name  {     forwarding-class  class-name  {       next-hop [  next-hop-name  ];     }   } } 

The JUNOS software applies the CoS next-hop map to the set of next hops previously defined; the next hops themselves can be located across any outgoing interfaces on the router.

Finally, apply the route filter to routes exported to the forwarding engine. This configuration instructs the routing process to insert routes to the forwarding engine matching my-cos-forwarding with the associated next-hop CoS-based forwarding rules.

 routing-options {   forwarding-table {     export my-cos-forwarding;   } } 

The following rules are used to apply a configuration to a route:

  • If the route is a single next-hop route, all traffic goes to that route; that is, no CoS-based forwarding takes effect.

  • For each next hop, associate the proper forwarding class. If a next hop appears in the route but not in the cos-next-hop map, it does not appear in the forwarding table entry.

  • The default forwarding class is used if all forwarding classes are not specified in the next-hop map. If the default is not specified, one is chosen randomly .

For IPv4 or IPv6 packets, you can override the incoming classification, assigning them to the same forwarding class based on their input interface, input precedence bits, or destination address. You do so by defining a policy class when configuring CoS properties and referencing this class when configuring a routing policy. When you override the classification of incoming packets, any mappings you configured for associated precedence bits or incoming interfaces to output transmission queues are ignored. Also, if the packet loss priority bit was set in the packet by the incoming interface, the packet-loss priority bit is cleared. To override the input packet classification, do the following:

  1. Define the policy class by including the class statement. class-name is a name that identifies the class.

     [edit class-of-service]  forwarding-policy {   class  class-name  {     classification-override {       forwarding-class  class-name  ;     }   } } 
  2. Associate the policy class with a routing policy by including it in a policy-statement statement. Specify the destination prefixes in the route-filter statement and the CoS policy class name in the then statement.

     [edit policy-options]  policy-statement  policy-name  {   term  term-name  {     from {       route-filter  destination-prefix match-type  <class  class-name  >;     }     then class  class-name  ;   } } 
  3. Apply the policy by including the export statement:

     [edit routing-options]  forwarding-table {   export  policy-name  ; } 


Juniper Networks Field Guide and Reference
Juniper Networks Field Guide and Reference
ISBN: 0321122445
EAN: 2147483647
Year: 2002
Pages: 185

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net