JUNOSe 9.1.x BGP and MPLS Configuration Guide > Configuring MPLS > MPLS and Differentiated Services

MPLS and Differentiated Services

Before you read this section, we recommend you be thoroughly familiar with the concepts of the JUNOSe QoS application. For detailed information about QoS, see the JUNOSe Quality of Service Configuration Guide.

MPLS employs several strategies to manage different kinds of data streams based on service plans and priority:

• Different conceptual models of diff-serv tunneling that either conceal intermediate LSP nodes from diff-serv operations or render the MPLS network transparent to the diff-serv operations
• Different strategies to set the EXP bits in the shim header to modify or maintain the traffic class/color combination of traffic
• Mapping of traffic behavior aggregates to corresponding per-hop behaviors so that traffic can be differentially switched to the appropriate LSPs to meet your network objectives

Tunneling Models for Differentiated Services

The JUNOSe software supports both the pipe model and the uniform model for tunneling with the mpls tunnel-model command. The router also provides a way to implement the functionality of the short pipe model for IP packets.

Pipe and Short Pipe Models

In the pipe and short pipe models, any traffic conditioning (that is, in a pure JUNOSe environment, a change in traffic class/color combination) that is applied when traffic goes through the tunnel has no effect on the EXP bits coding in the inner header. In other words, when traffic exits an LSP (when a label is popped) or when traffic enters an LSP, the inner header's EXP bits coding is not changed.

The pipe and short pipe models differ in the header that the tunnel egress uses when it determines the PHB of an incoming packet. With the short pipe model, the tunnel egress uses an inner header that is used for forwarding. With the pipe model, the outermost label is always used. Because of this, you cannot use PHP with the pipe model.

The pipe model is the default JUNOSe behavior, which you can configure with the mpls tunnel-model command. You cannot configure the short pipe model with this command. In fact, on ingress line modules the traffic class/color combination is always determined from the outermost label, so fabric queuing is also based on the outermost label. However, on the egress line module you can achieve the queuing behavior expected with the short pipe model by attaching IP policies to egress interfaces to reset the traffic class/color combinations based on the IP header. However, this method requires that the outgoing packets to be IP. If the outgoing packets are MPLS, then this short pipe model of queuing is not supported.

Uniform Model

The uniform model of tunneling renders MPLS transparent to the differentiated services operation. From the diff-serv perspective, it is as if MPLS is not used. In the uniform model, if traffic conditioning is applied somewhere along the LSP, the EXP bits of the inner header must be changed at the egress when the inner header becomes the outer header (because of the pop of the outer label).

mpls tunnel-model

• Use to specify whether MPLS uses the pipe or uniform model of tunneling for differentiated services.
• Specify the uniform keyword for the uniform model and the pipe keyword for the pipe model.
• Example

host1(config)#mpls tunnel-model uniform

• Use the no version to restore the default, the pipe model.

EXP Bits and Differentiated Services

MPLS matches on the EXP bits for incoming traffic to set the traffic class/color combination, and sets the EXP bits for outgoing traffic based on the traffic class/color combination.

Incoming Traffic

For incoming MPLS traffic, the traffic class/color combination is set according to the EXP bits in the outermost label, either per the policy attached to the label or per the per-VR rules. The policy has precedence over the per-VR rules. Therefore, fabric queuing is always based on the outer label's EXP bits.

If the traffic is label-switched through the router, the EXP bits value associated with the incoming label that is used for switching—which can be either an outermost label or an inner label after popping one or more outer labels—is passed onto the egress line module. This behavior enables the EXP bits value to be copied to outgoing labels, used to reset the traffic class/color combination on the egress module, or both.

Outgoing Traffic

Outgoing traffic is queued according to traffic class/color combinations. The applied combination can be the same as was set on the ingress line module, or it can be reset on the egress line module by egress IP policy.

Figure 62 illustrates how the initial value of the EXP bits is set for the first label pushed. Figure 63 illustrates how the EXP bits can be changed for all labels, including the first label, by attached policies or per-VR EXP rules. The following section describes in detail how the EXP bits value is set for outgoing traffic.

Setting the EXP Bits for Outgoing Traffic

Different types of packets distributed into LSPs by the router have different default settings for the EXP bits. For IP packets, the EXP bits value is set to match the IP precedence value from the TOS field of the packet header. For non-IP packets, such as Martini or VPLS packets, the EXP bits value is set to 000. You can use the mpls copy-upc-to-exp command to free the EXP bits value in IP packets from being tied to the IP precedence value. Instead, this command sets the EXP bits value to match the user packet class (UPC) value.

The IP precedence value can be copied back into the IP precedence field of the IP packet header at the LSP endpoint on the ingress line module. This action takes place only if the IP header is exposed after popping the MPLS labels and if the uniform tunnel model is employed. The remaining bits of the TOS field are not touched.

In contrast, when you issue mpls copy-upc-to-exp command, the EXP bits value is not copied to the UPC field at the LSP endpoint, because the UPC value might have been set by a lower layer policy for a different purpose.

NOTE: For control traffic originated from this router, if an attached per-LSP policy has rules to modify the EXP bits, or if per-VR EXP rules are configured, the EXP bits value copied from the IP precedence value might be overwritten incorrectly because the default traffic class/color combination for control traffic is best-effort/green. You can avoid this situation by establishing an outgoing IP policy that sets the traffic class/color combination for control traffic so that the policy or rules have the correct traffic class/color to work with.

If per-LSP policies are used or per-VR rules are configured, by default all labels pushed by the router for the same packet have the same EXP bits value. That value is determined by the policies or rules.

You can use the mpls preserve-vpn-exp command to specify that the EXP bits value for the VPN or Martini or VPLS label pushed by the router cannot be modified by either policy for outer labels or by per-VR rules. This capability is useful if you want the inner labels to have a different value for the EXP bits than do the outer labels. For example, in a VPN you might want the inner label's EXP bits value to be the copied IP precedence value. You might want the base label's EXP bits value set according to the mapping of EXP bits to traffic class/color combination that is defined in your network.

Figure 62: Flow for Initial Setting of EXP Bits for the First Label Pushed

Figure 62 shows how packet type and configuration determine how the EXP bits are set for the first label pushed.

Figure 63: Flow for Setting EXP Bits for All Pushed Labels

mpls copy-upc-to-exp

• Use to set the initial value of the EXP bits to the UPC value associated with the packets
• For IP packets, the default value of the EXP bits is set to the value of the IP precedence field. For non-IP packets, the default value of the EXP bits is set to 000.
• Example

host1(config)#mpls copy-upc-to-exp

• Use the no version to restore the default condition.

mpls preserve-vpn-exp

• Use to prevent the value of the EXP bits for a VPN/VC label from being modified by a per-LSP policy applied for the outer labels or by per-VR traffic class/color rules.
• By default, per-LSP policies or per-VR rules modify all labels in a given label stack to have the same value for the EXP bits.
• Example

host1(config)#mpls preserve-vpn-exp

• Use the no version to restore the default condition.

Example Differentiated Services Application

Figure 64 shows an example topology where a service provider offers the following differentiated services to its customers over its MPLS network:

• QoS Internet service—The CE router is managed by the provider and sets the IP precedence to predefined values. IP policy on the PE router sets the traffic-class/color combination according to the incoming well-defined IP precedence value. The policy also sets the UPC value to the incoming well-defined IP precedence value.
• Plain Internet service—IP policy on the PE router leaves the traffic-class/color combination as the default value, best-effort/green. The policy sets the UPC to 0.
• QoS VPN service—For CE-to-PE traffic, the VPN EXP is copied from the IP precedence value when the PE router pushes VPN stacked labels.

For PE-to-CE traffic, IP policy on the PE router resets the traffic-class/color combination according to the received, well-defined IP precedence value, so that egress queuing is based on the IP precedence value. This action takes place on the egress line module.

• Plain VPN service—For CE-to-PE traffic, the VPN EXP bits are set to 000 when the PE router pushes VPN stacked labels.

For PE-to-CE traffic, IP policy on the PE router resets the traffic-class/color combination to the default value, best-effort/green, so that packets are queued as best-effort. The IP precedence value is left unchanged.

In this example, the provider also offers an inter-AS VPN service. The provider's own protocol traffic, for example, BGP signaling traffic such as update messages, is also labeled, with the EXP bits set to the same value as the IP precedence.

The egress queuing of traffic as it leaves the provider is always based on either the VPN EXP bits as received on the core side in inter-AS case, or the IP precedence value in all other cases. It is acceptable that fabric queuing is based on the incoming base label's EXP.

Figure 64: Differentiated Services over an MPLS Network

Configuration Example

To configure the differentiated services described in this example:

1. Create and attach an IP input policy for the QoS Internet service to CE interfaces on the PE router for incoming traffic.

host1(config)#ip classifier-list prec0 ip any any precedence 0

host1(config)#ip classifier-list prec1 ip any any precedence 1

...

host1(config)#ip policy-list qos-service

host1(config-policy-list)#classifier-group prec0

host1(config-policy-list-classifier-group)#user-packet-class 0

host1(config-policy-list-classifier-group)#traffic-class class0

host1(config-policy-list-classifier-group)#color green

host1(config-policy-list)#classifier-group prec1

host1(config-policy-list-classifier-group)#user-packet-class 1

host1(config-policy-list-classifier-group)#traffic-class class1

host1(config-policy-list-classifier-group)#color green

...

host1(config)#interface atm 3/0.1

host1(config-subif)#ip policy input qos-service

2. Create and attach an IP input policy for the plain Internet service to CE interfaces on the PE router for incoming traffic. All traffic is treated as best effort, so no classifier group is necessary.

host1(config)#ip policy-list plain-service

host1(config-policy-list-classifier-group)#user-packet-class 0

host1(config-policy-list-classifier-group)#traffic-class best-effort

host1(config-policy-list-classifier-group)#color green

host1(config)#interface atm 5/0.1

host1(config-subif)#ip policy input plain-service

3. Attach an IP output policy for the QoS VPN service to CE interfaces on the PE router for outgoing traffic. The same qos-service policy that is attached to the input in Step 1 can be used on the output, even though the UPC setting is not needed.

host1(config)#Interface atm 3/0.1

host1(config-subif)#Ip policy output qos-service

Attach an IP output policy for the plain VPN service to CE interfaces on the PE router for outgoing traffic. The same plain-service policy that is attached to the input in Step 2 can be used on output, although the UPC setting is not needed.

host1(config)#Interface atm 5/0.1

host1(config-subif)#Ip policy output plain-service

4. For traffic toward the core, configure per-VR rules or per-LSP policies to set the base EXP bits value according to the traffic-class/color combination. Issue the mpls copy-upc-to-exp command to set the VPN EXP bits value to the UPC value. The UPC value is the same as the IP precedence value for the QoS service case; for all other cases the value is 000. Configure the mpls preserve-vpn-exp command so that VPN EXP bits are not subject to policy or to per-VR EXP rules.

host1(config)#mpls match traffic-class ... color ... set exp-bits ...

host1(config)#mpls copy-upc-to-exp

host1(config)#mpls preserve-vpn-exp

You must attach a policy to the core-side IP interface to set the UPC value of the control traffic appropriately so that the EXP bits value is copied from the UPC when this traffic goes out as MPLS packets.

host1(config)#ip classier-list control-traffic-prec0 ...

host1(config)#ip classier-list control-traffic-prec1 ...

...

host1(config)#ip policy-list core-ip-policy

host1(config-policy-list)#classifier-group control-traffic-prec0

host1(config-policy-list-classifier-group)#user-packet-class prec0

host1(config-policy-list-classifier-group)#traffic-class class0

host1(config-policy-list-classifier-group)#color green

host1(config-policy-list)#classifier-group control-traffic-prec1

host1(config-policy-list-classifier-group)#-packet-class prec1

host1(config-policy-list-classifier-group)#traffic-class class1

host1(config-policy-list-classifier-group)#color green

...

host1(config)#interface pos 0/0

host1(config-subif)ip policy output core-ip-policy

5. For traffic from the core, configure per-VR rules or per-LSP policies to set the traffic-class/color combination—and therefore shape the egress traffic queue—according to the value of the EXP bits in the base label. This action causes

host1(config)#mpls match exp-bits <value> set traffic-class <className> color 

...

Classifying Traffic for Differentiated Services

In a differentiated services domain, traffic is classified into a behavior aggregate (BA), based on the type of diff-serv behavior for the traffic. At each node, traffic belonging to a particular BA is mapped to the corresponding per-hop behavior (PHB), which provides the scheduling behavior and drop probability required by the traffic.

MPLS uses the EXP bits in the shim header to support differentiated services. The JUNOSe software supports both statically configured and signaled mapping between the EXP bits and the PHB of traffic.

In a signaled environment, you can configure on the ingress node the set of PHBs that a tunnel supports, and then the set of PHBs is signaled end to end.

To support differentiated services, MPLS employs two types of LSPs: E-LSPs and L-LSPs. The two types differ in how their PHB is determined. In the JUNOSe software, the PHB is a combination of traffic class (also called per-hop scheduling class, or PSC) and drop precedence (color).

• E-LSPs (EXP-inferred-PSC LSP) can transport as many as eight BAs. For E-LSPs, the traffic's PHB is learned from the MPLS shim header.
• L-LSPs (Label-only-inferred-PSC LSP) transport a single PSC. The PHB is determined from a combination of the packet's label, which indicates the traffic class, and the EXP field of the shim header, which indicates the drop precedence.

• Table 29 indicates how the PSC (column 1) is combined with the EXP field (column 2) to determine the PHB for incoming traffic on L-LSPs.
  
  
  Table 29: Incoming L-LSP PHB Determination 

  PSC	+	EXP Field	=	PHB
  BE		000		BE
  CSn		000		CSn
  AFn		001		AFn1
  AFn		010		AFn2
  AFn		011		AFn3
  EF		000		EF

  
  

For nonstandard PHBs (any that are not listed in Table 29), the JUNOSe software uses mapping similar to AFn mapping; EXP 001 is mapped to color green, EXP 010 is mapped to yellow, and EXP 011 is mapped to red.

Table 30 presents three examples that indicate how the PSC and the EXP field are combined to determine the PHB for traffic on incoming L-LSPs.

Table 30: Examples of Incoming L-LSP PHB Determination 

PSC	+	EXP Field	=	PHB
AF2		010		AF22
AF3		010		AF32
AF3		011		AF33

• For outgoing L-LSPs, the EXP is determined by the PHB. Table 31 indicates the PHB-to-EXP mapping for outgoing traffic on L-LSPs.
  
  
  Table 31: Outgoing L-LSP PHB Determination 

  PHB	=	EXP Field
  BE		000
  CSn		000
  AFn1		001
  AFn2		010
  AFn3		011
  EF		000

  
  

For nonstandard PHBs, the mapping is similar to AFn mapping. Red color maps to 011, yellow maps to 010, and green maps to 001.

Configured Mapping

You can configure static EXP-to-PHB mapping at the per-VR level. Configured mapping applies regardless of label distribution protocol, BGP. LDP, or RSVP-TE.

The PHB of incoming packets is determined from the EXP bits according to the following command:

mpls match exp-bits bitValue set traffic-class className color { green | 

yellow | red }

The EXP bits of outgoing packets are determined from the PHB according to the following command:

mpls match traffic-class className color { green | 

yellow | red } set exp-bits bitValue 

The configuration applies only to LSPs that do not have specific policies attached (by either per-LSP configured mapping or signaled mapping).

mpls match exp-bits

• Use to set a combination of traffic class and color for incoming traffic that matches the specified EXP bits value in the shim header.
• Specify an integer value in the range 0–7 to match the corresponding binary values (000–111) for the three EXP bits in the shim header.
• You can repeat the command to support the eight possible EXP bit values.
• Example

host1(config)#mpls match exp-bits 1 set traffic-class bronze color red

• Use the no version to restore the default behavior, setting neither traffic class nor color for all traffic matching the specified EXP bits value.

mpls match traffic-class

• Use to set the EXP bits in the shim header of outgoing traffic that matches a particular combination of traffic class and color.
• Specify an integer value in the range 0–7 to set the corresponding binary values (000–111) for the three EXP bits in the shim header.
• You can repeat the command to support up to 24 combinations: eight traffic classes supported on the router times three colors.
• Example

host1(config)#mpls match traffic-class gold color green set exp-bits 7

• Use the no version to restore the default behavior for traffic that matches the specified traffic class and color. For matching traffic entering an LSP, it sets the EXP bits to 000. For matching transit traffic, it does nothing.

Signaled Mapping for RSVP-TE Tunnels

For signaled mapping between EXP and PHB, policies apply the EXP bits matching and setting on a per-LSP basis rather than a per-VR basis. Signaled mapping applies only when RSVP-TE is the label distribution protocol.

When traffic is mapped onto the ingress router of the LSP, the EXP bits are set according to a policy attached to the LSP. The policy corresponds to the EXP-to-PHB mapping defined for the LSP. Typically, the policy sets the EXP bits differently according to classifier lists that match on internal class/color information or on a user packet class associated with a packet.

For transit routers and egress routers along the path of the LSP, the incoming EXP bits are matched to determine the traffic class and drop preference (color red, yellow, or green). This matching is accomplished by means of a policy corresponding to the signaled EXP-to-PHB mapping that is created and attached when the LSP is established.

EXP bits are not normally changed on transit routers, but when traffic is sent out of an LSP on a transit router, the bits can be changed by the policy. Normally, however, the net effect is that the EXP-bits remain the same through the mapping sequence of EXP bits to an internal traffic class/color combination back to EXP bits, unless the traffic class/color combination is also modified by other factors.

Because the policy (which maps the EXP bits to an internal traffic class/color combination and vice versa) attached to an LSP is created according to the PHB-ID–to–EXP mapping signaled by RSVP-TE, you must configure on each router a mapping association between PHB IDs and the internal traffic class/color combinations.

The JUNOSe software automatically generates and attaches policies when tunnels are established.

Figure 65 shows the mapping associations between PHB IDs, EXP bits, and traffic class (TC)/color combination in an E-LSP case.

• Mapping association between PHB ID and EXP bits is configured on ingress routers using the tunnel mpls diff-serv phb-id command.
• Mapping association between PHB ID and traffic class/color combination is configured on all routers using the mpls diff-serv phb-id traffic-class command.
• Mapping association between EXP bits and traffic class/color combination is done automatically by the JUNOSe software at the appropriate routers along the path.

Figure 65: Associations Between PHB ID, EXP Bits, and Traffic Classes/Colors

Figure 66 shows the operations performed at ingress, transit, and egress systems during signaled mapping sessions.

Figure 66: Signaled Mapping

mark-exp

• Use to define a policy rule that sets the EXP bits in packets to which the policy is applied.
• Use the mask keyword to modify certain EXP bits present in the packet.
• Example

host1(config-policy-list)#mark-exp 5 classifier-group claclEXP precedence 32

• Use the suspend version to temporarily suspend the EXP bits policy rule. Use the no suspend version to resume the application of the suspended rule. Use the no version to remove the rule from the policy list.

mpls classifier-list

• Use to create or modify an MPLS classifier control list to match on traffic class/color combination or EXP bits.
• Example

host1(config)#mpls classifier-list be-green traffic-class best-effort color yellow

• Use the no version to delete the classifier control list.

mpls diff-serv phb-id traffic-class

• Use to map the specified PHB ID to the internal traffic class/color combination. If color is specified, the PHB ID can be used only for E-LSPs. If color is not specified, the PHB ID can be used only for L-LSPs.
• Example

host1(config)#mpls diff-serv phb-id standard 45 traffic-class gold color green

• Use the no version to remove the mapping.

mpls policy-list

• Use to create or modify an MPLS policy.
• This command accesses Policy List Configuration mode, from which you define the rules that make up the MPLS policy. See the JUNOSe Policy Management Configuration Guide for more information about defining policies.
• Example

host1(config)#mpls policy-list mpls-exp-setting

• Use the no version to delete the policy.

mpls policy-statistics

• Use to enable collection of policy statistics for a tunnel or LSP. Collection is disabled by default.
• Policy statistics are displayed when you issue the show mpls forwarding or show mpls tunnel command, if a policy is attached and policy statistics are enabled.
• Example

host1#mpls policy-statistics boston2dc

• Use the disable version to stop collection of policy statistics. There is no no version.

mpls traffic-class

• Use to specify the traffic class for which LSP-level queues are created and the scheduler profile to be used with the queues.
• The scheduler profile distributes bandwidth among different classes.

Classes for which the LSP-level queues are created originate from one of two sources:

• E-LSPs and L-LSPs—Classes derived from the signaled PHB-ID
• Regular LSPs—Classes configured with the mpls traffic-class command

• Example

host1(config)#mpls traffic-class af1 scheduler-profile af1-scheduler-profile

• Use the no version to remove the configuration.

tunnel mpls diff-serv phb-id

• Use to specify the PHB supported by a signaled tunnel.
• For E-LSPs, you also use this command to map the PHB to the specified exp-bits bitValue. You can repeat the command for up to eight PHB mappings.
• Example

host1(config-if)#tunnel mpls diff-serv phb-id standard 35 exp-bits 5

• For L-LSPs, do not use the exp-bits keyword. If you repeat the command, the most recent command overwrites the previous command.
• Example

host1(config-if)#tunnel mpls diff-serv phb-id private 40

• Use the no version to remove the mapping association.

Preference of per-VR Versus per-LSP Behavior

MPLS always prefers the per-LSP method of matching and setting EXP bits by means of applied policies over the per-VR method.

Per-VR matching of EXP bits is not performed on the LSP when an input policy (matching on incoming EXP bits) is attached to the ingress segment of the LSP.

Similarly, per-VR setting of EXP bits is not performed on the LSP when an output policy (setting the outgoing EXP bits) is attached to the egress segment of the LSP.

Example Configuration

The commands in this example illustrate a partial network configuration that supports four differentiated service classes on a particular tunnel: a best-effort class, two assured forwarding classes, and an expedited forwarding class. Table 32 presents the mapping between EXP bits, PHB, PHB ID, and traffic class/color combination.

 Table 32:  Differentiated Services Mapping 

 EXP
 PHB
 PHB ID
 6-bit PHB ID
 Traffic Class/Color

 000

 BE

 0x0000

 00

 best-effort/green


 001

 AF11

 0x2800

 10

 af1/green


 010

 AF12

 0x3000

 12

 af1/yellow


 011

 AF13

 0x3800

 14

 af1/red


 100

 AF21

 0x4800

 18

 af2/green


 101

 AF22

 0x5000

 20

 af2/yellow


 110

 AF23

 0x5800

 22

 af2/red


 111

 EF

 0xb800

 46

 ef/green



 

 NOTE: This example includes both MPLS and policy configuration commands, and assumes that you are thoroughly familiar with the information and commands presented in the JUNOSe Policy Management Configuration Guide. 



 

The four traffic classes are configured to allocate fabric resources and allow global synchronization of the three segments of the data path through an E-series router: ingress, fabric, and egress. The JUNOSe software automatically creates the best-effort traffic class, with a default weight of eight. You must define the remaining three classes, af1, af2, and ef. In this example, the af1 class has twice as much fabric bandwidth as the best-effort class, and the af2 class has twice as much fabric bandwidth as the af1 class. The expedited forwarding traffic (the ef class) requires strict-priority queuing.

host1(config)#traffic-class af1

host1(config-traffic-class)#fabric-weight 16

host1(config)#traffic-class af2

host1(config-traffic-class)#fabric-weight 32

host1(config)#traffic-class ef

host1(config-traffic-class)#fabric-strict-priority

Define two scheduler profiles for the af1 and af2 classes on the egress line modules:

host1(config)#scheduler-profile af1-scheduler-profile

host1(config-scheduler-profile)#weight 16

host1(config)#scheduler-profile af2-scheduler-profile

host1(config-scheduler-profile)#weight 32

Create queue profiles to define how queues are instantiated to implement the corresponding traffic classes and PHBs. The JUNOSe software automatically creates the best-effort queue profiles.

host1(config)#queue-profile af1-queues

[Queue configuration omitted]

host1(config)#queue-profile af2-queues

[Queue configuration omitted]

host1(config)#queue-profile ef-queues

[Queue configuration omitted]

The scheduler and queue profiles are referenced in QoS profiles. For example, you can create a QoS profile for port-based per-class queuing or for LSP-level per-class queuing (configuration omitted).

You must map the PHB IDs to the appropriate traffic class/color combinations:

host1(config)#mpls diff-serv phb-id standard 0 traffic-class best-effort color green

host1(config)#mpls diff-serv phb-id standard 10 traffic-class af1 color green

host1(config)#mpls diff-serv phb-id standard 12 traffic-class af1 color yellow

host1(config)#mpls diff-serv phb-id standard 14 traffic-class af1 color red

host1(config)#mpls diff-serv phb-id standard 18 traffic-class af2 color green

host1(config)#mpls diff-serv phb-id standard 20 traffic-class af2 color yellow

host1(config)#mpls diff-serv phb-id standard 22 traffic-class af2 color red

host1(config)#mpls diff-serv phb-id standard 46 traffic-class ef color green

Configuration on the Ingress Router

You must access the tunnel interface to map the PHB IDs to the EXP bits. The E-series router signals this mapping to all routers on the tunnel. You can establish different PHB-ID–to–EXP mappings for different tunnels.

host1(config)#interface tunnel mpls:example

PHB-ID–to–EXP mapping for the best-effort traffic class:

host1(config-if)#tunnel mpls diff-serv phb-id standard 0x0000 exp-bits 0

PHB-ID–to–EXP mapping for the af1 traffic class:

host1(config-if)#tunnel mpls diff-serv phb-id standard 10 exp-bits 1

host1(config-if)#tunnel mpls diff-serv phb-id standard 12 exp-bits 2

host1(config-if)#tunnel mpls diff-serv phb-id standard 14 exp-bits 3

PHB-ID–to–EXP mapping for the af2 traffic class:

host1(config-if)#tunnel mpls diff-serv phb-id standard 18 exp-bits 4

host1(config-if)#tunnel mpls diff-serv phb-id standard 20 exp-bits 5

host1(config-if)#tunnel mpls diff-serv phb-id standard 22 exp-bits 6

PHB-ID–to–EXP mapping for the ef traffic class:

host1(config-if)#tunnel mpls diff-serv phb-id standard 46 exp-bits 7

Define classifier control lists to classify the incoming packets into classifier groups. Although not shown here, for each CLACL you must define the rules that will select the appropriate incoming packets: be, af1, af2, or ef.

host1(config)#classifier-list be-packets

host1(config)#classifier-list af1-packets

host1(config)#classifier-list af2-packets

host1(config)#classifier-list ef-packets

Define a policy that maps the selected packets into traffic classes. For the assured forwarding classes, this example uses rate limit profiles to set the colors.

host1(config)#policy-list classify-packets

host1(config-policy-list)#traffic-class best-effort classifier-group bf-packets

host1(config-policy-list)#traffic-class ef classifier-group ef-packets

host1(config-policy-list)#traffic-class af1 classifier-group af1-packets

host1(config-policy-list)#traffic-class af2 classifier-group af2-packets

host1(config-policy-list)#rate-limit-profile af1-profile classifier-group af1-packets

host1(config-policy-list)#rate-limit-profile af2-profile classifier-group af2-packets

host1(config)#rate-limit-profile af1-profile

host1(config-rate-limit-profile)#committed-rate 6000000

host1(config-rate-limit-profile)#committed-burst 1000000

host1(config-rate-limit-profile)#peak-rate 8000000

host1(config-rate-limit-profile)#peak-burst 1000000

host1(config)#rate-limit-profile af2-profile

host1(config-rate-limit-profile)#committed-rate 8000000

host1(config-rate-limit-profile)#committed-burst 1500000

host1(config-rate-limit-profile)#peak-rate 12000000

host1(config-rate-limit-profile)#peak-burst 1000000

You attach the policy to the ingress interface of the ingress router. As packets arrive, they are classified with the internal traffic class/color combination and forwarded into the appropriate queues in the fabric. When the packets are sent into the tunnel out of the ingress router, the EXP bits are set according to the router-generated policy (in this example called mpls-exp-setting) that the JUNOSe software automatically attached to the tunnel.

Configuration on the Ingress and Transit Routers

When the tunnel is established, the JUNOSe software automatically creates an output policy to map traffic-class/color combinations to EXP bits and attaches the policy to the outgoing segment of the tunnel. The JUNOSe software generates classifier list and policy list names, and creates the EXP-setting policy as if the following commands were entered:

NOTE: You do not actually issue these commands; they represent the behavior automatically performed by the router.

host1(config)#mpls classifier-list be-green traffic-class best-effort color green

host1(config)#mpls classifier-list ef-green traffic-class ef color green

host1(config)#mpls classifier-list af1-green traffic-class af1 color green

host1(config)#mpls classifier-list af1-yellow traffic-class af1 color yellow

host1(config)#mpls classifier-list af1-red traffic-class af1 color red

host1(config)#mpls classifier-list af2-green traffic-class af2 color green

host1(config)#mpls classifier-list af2-yellow traffic-class af2 color yellow

host1(config)#mpls classifier-list af2-red traffic-class af2 color red

host1(config)#mpls policy-list mpls-exp-setting

host1(config-policy-list)#mark 0 classifier-group be-green

host1(config-policy-list)#mark 1 classifier-group af1-green

host1(config-policy-list)#mark 2 classifier-group af1-yellow

host1(config-policy-list)#mark 3 classifier-group af1-red

host1(config-policy-list)#mark 4 classifier-group af2-green

host1(config-policy-list)#mark 5 classifier-group af2-yellow

host1(config-policy-list)#mark 6 classifier-group af2-red

host1(config-policy-list)#mark 7 classifier-group ef-green

 NOTE: For a topology-driven LSP, you have to configure and apply the classifier list and policy list manually.



 

Configuration on the Transit and Egress Routers

When the tunnel is established, the JUNOSe software automatically creates an input policy to match the EXP bits and map them to the traffic-class/color combinations and attaches the policy to the incoming segment of the tunnel. The JUNOSe software generates classifier list and policy list names, and creates the policy as if the following commands were entered:

NOTE: You do not actually issue these commands; they represent the behavior automatically performed by the router.

host1(config)#mpls classifier-list bf-packets exp 0

host1(config)#mpls classifier-list af11-packets exp 1

host1(config)#mpls classifier-list af12-packets exp 2

host1(config)#mpls classifier-list af13-packets exp 3

host1(config)#mpls classifier-list af21-packets exp 4

host1(config)#mpls classifier-list af22-packets exp 5

host1(config)#mpls classifier-list af22-packets exp 6

host1(config)#mpls classifier-list ef-packets exp 7

host1(config)#mpls policy-list mpls-exp-matching

host1(config-policy-list)#traffic-class best-effort classifier-group bf-packets

host1(config-policy-list)#traffic-class af1 classifier-group af11-packets

host1(config-policy-list)#traffic-class af1 classifier-group af12-packets

host1(config-policy-list)#traffic-class af1 classifier-group af13-packets

host1(config-policy-list)#traffic-class af2 classifier-group af21-packets

host1(config-policy-list)#traffic-class af2 classifier-group af22-packets

host1(config-policy-list)#traffic-class af2 classifier-group af23-packets

host1(config-policy-list)#traffic-class ef classifier-group ef-packets

host1(config-policy-list)#color green classifier-group af11-packets

host1(config-policy-list)#color green classifier-group af21-packets

host1(config-policy-list)#color yellow classifier-group af12-packets

host1(config-policy-list)#color yellow classifier-group af22-packets

host1(config-policy-list)#color red classifier-group af13-packets

host1(config-policy-list)#color red classifier-group af23-packets

 NOTE: For a topology-driven LSP, you must configure and apply the classifier list and policy list manually.



 

The packets are forwarded to the appropriate fabric queue according to the traffic class/color combination. On a transit router, when the packet is forwarded out of the tunnel, the router-generated output policy then sets the EXP bits back according to the traffic class/color combination. Typically, the effect of the EXP bits to traffic class/color combination to EXP bits is no change.

On an egress router, where the tunnel terminates, no router-generated output policy is attached, and the packets pass out of the router subject to any manually configured IP policy management applied to their traffic class/color combination.