8.3 DSCP, Traffic Class, and Priority Bits

8.3.1 Differentiated Services

In the mobile backhaul, transport level quality of service (QoS) solutions are based on the Differentiated Services (DiffServ) approach which provides a relative service differentiation for connections aggregated into a limited number of well defined QoS classes based on the DiffServ code point (DSCP) encoded into each IP packet's header. 3GPP requires the use of DSCPs and a mapping of traffic categories into DSCPs as the means of transport layer QoS marking.

Traffic handling and scheduling decisions at the transport nodes are made based on the DSCP, that is, the network nodes differentiate the traffic based on its class marked by the DSCP. For each class a separate handling and forwarding policy is defined that is referred to as PHB (Per Hop Behaviour). Connections belonging to the same service class should be marked with the same DSCP in order to ensure the same level of service.

Differentiated Services (DS) classifies and conditions traffic at the network boundary (ingress), and assigns it to a behavior aggregate. The behavior aggregate is marked by a DS codepoint (DSCP). Network nodes then forward and schedule the packet according to the marked codepoint.

A DS domain consists of boundary nodes and interior nodes. Boundary nodes classify and condition traffic at the ingress. DS domain nodes then select the per-hop-behaviour according to the DS codepoint marking. A DS domain is managed typically by a single entity but may consist of multiple networks. To support Differentiated Services between DS domains, Service Level Agreements (SLAs) are needed.

A classifier/conditioner is shown in Figure 8.8. Classifier matches incoming packets against a rule. At its simplest it is the DS codepoint field but can consist of other header fields, such as source and destination addresses, port numbers, protocol info and so forth.

Traffic profile is needed to decide, whether the incoming traffic is in-profile or out-of-profile, with a meter, which measures the incoming traffic. Packets which are out-of-profile, may be subject for further conditioning, e.g. queueing, discarding, re-marking, or other actions. Shaper may queue the packet in order to make it comply with the profile. Alternatively a non-conforming packet can be dropped.

In general in backhaul, marking should be done by the radio access nodes as the markers should follow the mapping rules of radio QoS parameters to their transport counterparts. The required information is available at the radio access nodes. This is one of the means to ensure consistent end-to-end QoS provisioning.

Obviously, classification and conditioning has a lot to do with trust. If traffic sources are known to behave well and can be trusted, there is less need for classification and conditioning at the subsequent nodes. When traffic crosses an organizational boundary or administrative domain, it is more likely to be classified, re-marked and maybe policed.

DSCP has meaning only over a given network domain, therefore the marking is done at the boundary. When traffic is handed over to the next domain, re-mapping/re-writing of the DSCP might be required in order to ensure end-to-end consistency. The subsequent network nodes can then use appropriate buffer and scheduler management functions and traffic conditioning, to realize the service. The specification does not intend to specify algorithms or functionality of how to realize the required behaviour, but the characteristics of the service.

DSCP itself is a number between 0 and 63 (decimal). Approximately half of the values are standardized (recommended), the other part is for local definition.

The starting point for QoS marking and differentiation is the DS field of the IP header for the packet based mobile backhaul. This is also specified in 3GPP. Mobile network elements, such as eNodeB, support DSCP marking. How the DSCP is derived, is discussed separately for each radio technology.

When the DS field of the IP packet is marked by the mobile network node, e.g. a eNodeB, subsequent DS nodes can then forward the packet accordingly. The eNodeB may also mark the related fields in the headers of other protocol layers, e.g. in the Ethernet frame using the priority bits (Assuming an IEEE802.1Q tagged frame).

8.3.2 IPv6

IPv6 supports the same DiffServ architecture as IPv4 does. In the mobile backhaul, the marking of DSCPs is performed as in the case of IPv4. For DiffServ, the field in the IPv6 header is called Traffic Class (TC).

The end user IP traffic, whether IPv4 or IPv6, is tunneled within GTP-U (and other protocols, depending on the radio network technology) transparently over the radio network.

One QoS related difference in a mobile backhaul IPv6 application is the larger header size of IPv6. This needs to be taken into account when calculating the required bandwidth on lower layers and on physical links. Without extension headers, IPv6 header is 40 bytes, as opposed to a 20 byte header (minimum) of IPv4.

8.3.3 Per-Hop Behaviours

Per-hop-behaviours include the Default or Best Effort Behaviour, Expedited Forwarding, and Assured Forwarding.

Default behaviour (Code 000000) marks Default Per-Hop Behaviour or the best effort class. No specific guarantees are given.

Expedited forwarding (EF) is meant for traffic of low latency, low loss and assured bandwidth. It should be able to replicate a point-to-point service end-to-end over the Differentiated Services domain, however the end-to-end behaviour is not in the scope of the definition of the EF PHB. EF traffic should not be queued (buffered) and in order to avoid buffering, the service rate should be at least equal to the arrival rate. EF PHB is meant to address guaranteeing the service rate. Traffic conditioning is needed to make sure that the arrival rate is bounded. EF is recommended to use the DS codepoint 101110. Packets marked with the EF codepoint must not be demoted, and if the code point is changed, the new codepoint must satisfy the EF PHB requirements.

EF PHB can e.g. be implemented as a strict priority queue, which is serviced whenever there are packets to be sent, but other queue implementations are possible, as long as the requirements of the EF PHB are met.

Assured Forwarding (AF) classes are shown in Figure 8.9. An AF PHB group consists of four classes, each of which supports three drop precedences. AF classes are not allowed to be aggregated together, and a minimum amount of resources must be allocated to each implemented classes. Excess resources may be allocated to the classes, the algorithm of how this is done is not covered in the specification. Traffic conditioner may modify the drop precedence, and also allocate traffic to another class.

Short term congestion (bursts) can be handled by queuing packets. An AF Implementation attempts to minimize long term congestion within each class, with an active queue management algorithm. Examples of such algorithms are Random Early Discard (RED)¹ and Weighted RED (WRED). Dropping algorithm should be insensitive to the packet bursts, and react to the long term congestion. AF PHB can be implemented e.g. with a weighted round-robin scheduler.

8.3.4 Recommended Use of DSCPs and Treatment Aggregates

For the DSCPs, a recommendation for usage is provided in RFC 4594. Recommended values help interoperation at the administrative domain boundaries. This does not yet provide a direct answer on how to map the mobile backhaul traffic. The basic principle with DSCP allocation however becomes clear.

Network control means routing and other network control traffic that is essential in keeping the network operational. OAM traffic is also network control traffic, although it is separated in Table 8.1. Network control traffic is network operator's (service provider's) traffic, instead of user traffic.

Table 8.1 Recommendation for DSCPs [29].

User traffic includes different types of services, and also user signalling (example is IP telephony signalling) with demands for loss, delay, and jitter that are specific to the service.

Default forwarding (marked standard) means a best effort (BE) service. This service is defined for the background low priority data traffic that is elastic.

Assured Forwarding is an ‘enhanced best effort’ service. Multiple DSCP values are provided for identification of the traffic. A common queue stores the aggregate, and an active queue management (e.g. RED or WRED) is used to protect the network and limit the delays.

CS stands for Class Selector, defined for IPv4 precedence queuing in RFC1812. Differentiated Services maintains a level of backwards compatibility to the Class Selectors. Class selector uses three bits.

Another informational RFC, RFC 5127, proposes that the service classes as presented, are mapped into treatment aggregates. The benefit is in reduction of different behaviours that the network nodes need to support. The supported service classes are aggregated into treatment aggregates. RFC5127 discusses four treatment aggregates: Network control, Real-time, Assured elastic and Elastic. See Table 8.2.

Table 8.2 Treatment aggregates [30].

Multiple DSCP values are in Table 8.2 collected into an aggregate, except for the Network control aggregate, which includes only Class selector 6. Real-time traffic maps into a per-hop-behaviour of EF (Expedited Forwarding). Assured elastic uses Assured Forwarding, while Elastic is a Default or Best Effort – class.

8.3.5 DSCP in IP Tunnels

IP is in some cases tunnelled, so that the DSCP marking of the inner IP packet is not visible. In the mobile backhaul, one such type of an application is with the use of IPSec. In the IPSec tunnel mode, the complete IP packet is encapsulated within a new IP packet with a new IP header, and an AH/ESP header. The inner packet DSCP value can be copied to the outer packet DSCP field, so that DS nodes are able to support QoS, even though the inner packet header is not available. RFC2983 provides a discussion of Differentiated Services and tunnels.

Note that the end user level IP packet is tunneled with GTP-U (and/or other radio network layer protocols, depending on the radio network technology) through the radio network. In this case, the DSCP from the inner IP packet is not directly copied to the backhaul layer IP header. The inner (end user) IP packet is carried transparently over the radio network. QoS marking for the backhaul layer IP header originates from the radio network layer QoS parameters.

8.3.6 Use of DSCPs for Mobile Backhaul

The traffic types existing depend on the radio network technology. In 3G, there are more traffic types than in LTE, due to the Iub interface and the functional split between the RNC and the NodeB.

The recommendations discussed for DSCP usage need to be adapted for the radio network application, and thus example mappings are studied in later sections further for each of the radio technologies.

Even with user traffic, there are additional requirements due to constraints set by the radio network architecture. In 2G, this is due to the BSC and the BTS, and the radio L2 protocols in between over the Abis. As an example, carrying the traffic for a file download via GPRS on a pseudowire requires real-time delivery for the pseudowire, due to the scheduling in the BSC. The end user application itself – file download – has less strict requirements. The general mapping principles discussed are adapted to cope also with the constraints due to the radio technologies.

One topic is the mapping of voice traffic compared to the mapping of radio network control traffic – such as NBAP in 3G and S1-AP in LTE. Voice traffic has stringent requirements regarding delay and delay variation. To provide this service with good quality to the end user, voice traffic is given priority over the control plane traffic. The control plane traffic is tolerant for delay and delay variation, while voice needs deterministic service.

Control plane traffic however needs to have an amount of bandwidth, otherwise the signaling messages will not get through. When voice is marked with DSCP 46 (EF) and radio network control plane traffic with DSCP 34 (AF41), there must be an assurance that the radio network control plane does not starve.

Note that lately in RFC5865 an additional DSCP for voice traffic – 44 – has been proposed. The traffic would be treated as EF. RFC5865 describes different implementation possibilities regarding priorization of traffic marked DSCP 46 and those marked DSCP 44. This may open up further configuration possibilities.

8.3.7 MPLS Traffic Class

MPLS header has a 3-bit field for marking the QoS. Originally the bits were named EXP after Experimental, which caused confusion. RFC 5462 (Feb 2009) corrected this and named the bits as TC (Traffic class).

There is no recommendation on how the eight possible values should be interpreted: which traffic type should be marked with what numerical code. The label switch routers at the edge either have a default mapping between DSCPs and traffic classes, or a configuration (mapping) table is supported.

Two possible MPLS QoS marking models are defined: marking of the QoS to the TC field of the MPLS header. This type of LSP is called Explicitly TC-encoded PSC LSP, or E-LSP. PSC stands for Per Hop Behaviour Scheduling Class. Other model is L-LSP (label-only-inferred-PSC LSP), in which case the L-LSP defines the PSC, and drop precedence is marked into the TC bits.

As the number of bits available in the TC field is identical to what Ethernet IEEE802.1Q priority bits can provide, one can reuse the logic followed while defining the 802.1Q recommended value settings. This would be aligned with Differentiated Services, as the IEEE 802.1Q defined priority bit usage is aligned with Differentiated Services.

8.3.8 IEEE802.1Q Priority Bits

In the previous sections we focused on marking the IP packets. In many cases the access lines are Ethernet-based, possibly without a capability to investigate IP layer headers. It is useful to mark the priority also to the Ethernet frames. The IEEE802.1Q frame includes three priority bits for this.

The IEEE standard informatively defines the use of priority bits as in Table 8.3. The purpose is to facilitate interoperation and have a well defined and commonly understood way of indicating priority in the Ethernet IEEE 802.1Q frame.

Table 8.3 Priority values and their usage [32].

Traffic type	Characteristics	Acronym
background	bulk transfers, permitted but should not degrade other applications	BK
best effort	default, for unprioritized applications	BE
excellent effort	‘CEO's best effort’, delivered to its most important service (still best-effort type)	EE
critical applications	guaranteed minimum bandwidth required, traffic admitted by admission control	CA
‘video’, < 100 ms latency and jitter	video, or other applications requiring low latency	VI
‘voice’, < 10 ms latency and jitter	voice, max delay and jitter, as one-way through the LAN on a single campus	VO
internetwork control	Supports maintenance of the network over administrative domains	IC
network control	Guaranteed delivery required, supports maintenance of the network infrastructure	NC

The number of classes Ethernet bridges must have, is not defined in IEEE, so it is an implementation issue. Table 8.4 shows an example of how to map traffic, as a function of the number of queues.

Table 8.4 Use of traffic classes as a number of queues available [32].

Number of queues	Class	Traffic types
1	BE	Best effort, background, excellent effort, critical applications, voice, video, internetwork control, network control
2	BE	Best effort, background, excellent effort, critical applications,
	VO	Voice, video, internetwork control, network control
3	BE	Best effort, background, critical applications, excellent effort
	VO	Voice, video
	NC	internetwork control, network control
4	BE	Best effort, background,
	CA	critical applications, excellent effort
	VO	Voice, video
	NC	internetwork control, network control
5	BE	Best effort, background,
	CA	critical applications, excellent effort
	VO	Voice, video
	IC	internetwork control
	NC	network control
6	BK	background
	BE	best effort
	CA	critical applications, excellent effort
	VO	Voice, video
	IC	internetwork control
	NC	network control
7	BK	background
	BE	best effort
	EE	excellent effort
	CA	critical applications
	VO	Voice, video
	IC	internetwork control
	NC	network control
8	BK	background
	BE	best effort
	EE	excellent effort
	CA	critical applications
	VI	video
	VO	voice
	IC	internetwork control
	NC	network control

With only a single queue available, all traffic is best effort. With two queues, voice and other real-time traffic can be separated into its own queue. Third queue allows separating network control. With four queues, critical applications are separated from the best effort, and so on. Granularity is increased up to the maximum of eight queues (given the three priority bits). Many equipment support e.g. four to six queues, which already allows for a clear differentiation of traffic.

Some Ethernet switches support DSCP marking, i.e. IP layer information. Others may be able to only use the information encoded into the Ethernet frame header. Table 8.3 presented some guidelines. In the end, this is subject to the network operator's decision. Configuration can be expressed as a mapping from DSCPs to PCPs, since DSCPs are the source information for the marking.

A straightforward mapping is to associate each PHB with a PCP:

• BE PHB is mapped to PCP 0.
• AF1 PHB to PCP 1.
• AF2 PHB to PCP 2.
• AF3 PHB to PCP 3.
• AF4 PHB to PCP 4.
• EF PHB to PCP 5.
• Network control traffic to PCP 6.

This leaves PCP 7 unused. In some networks Ethernet frames with a PCP value 7 are discarded in order to prevent attacks.

PCPs do not support a notion of a drop precedence as defined for the AF PHBs at the IP layer. It is also possible to define a color marking by indicating two drop precedences within PCPs by using some of the PCP values for a color indication.

8.3.9 VLANs

In some cases, instead of marking QoS to the priority bits of the Ethernet IEEE 802.1Q frame, QoS is indicated by the VLAN ID. An example is an Ethernet service, which may be defined to use the VLAN ID as the source for QoS. VLAN ID may also guide mapping of the user packet flow at a PE device to a suitable service (a suitable pseudowire).

8.3.10 QoS with MEF Services

Metro Ethernet Forum (MEF) services include QoS definitions at a detailed level. MEF services, with their performance objectives, were discussed in Chapter 5. The QoS for the mobile backhaul application is addressed by the definition of the attributes of the service.

How does the mobile operator then indicate the required Class of Service at the User-to-Network (UNI) interface?

Details depend on the service. An EVC is logically the Ethernet layer connectivity between two (or more) UNIs. For the EVC, the indication for CoS may be a VLAN ID only, in which case the VLAN indicates the CoS. In this case EVC corresponds to the customer VLAN.

Alternatively, the CoS is indicated by the VLAN ID and additionally either the priority bits of the Ethernet 802.1Q frame, or the IP layer DSCP field. In this case, single EVC includes two or more classes of service.

Single CoS (color-blind policer)

If policing at the ingress is color-blind the single EVC – single CoS application for the base station requires that a guarantee is given for all of the traffic, meaning the full aggregate rate from the base station. Full aggregate traffic means all of the traffic types combined. This rate shall equal the CIR rate guaranteed in the SLA. Otherwise it cannot be ensured that critical real-time and control traffic does not suffer from policing. This approach however leads to a high value for the CIR attribute, since it now also covers background traffic.

Two CoSs (color-blind policer)

Preferably background traffic is treated as non-guaranteed traffic with an Excess Information Rate (EIR). Assuming a color-blind policer, this requires two Classes of Service. One CoS supports the real-time/control traffic with a CoS H (High) and the other one non real-time traffic with a CoS L (Low). The two CoSs are identified at the UNI by either

• two separate VLAN IDs (two EVCs), or by
• a single VLAN ID and Ethernet p-bits or DSCPs (single EVC with two CoSs).

As an example,

• with CoS High, CIR is defined and EIR is 0. CIR is the value that real-time/control traffic requires;
• with CoS Low, CIR is 0 (or a low value) and EIR is according to the traffic volume of the NRT/background types.

With multiple CoSs as above bandwidth fragmentation may become an issue. This depends on how CIR and EIR are defined in each of the classes, and what type of policing is performed by the service provider. A Hierarchical Bandwidth Profile (H-BWP) defined in MEF addresses this issue.

8.3.10.3 Single CoS (color-aware policer)

MEF 23 also specifies a way for the customer equipment (CE) to predefine traffic within CIR (green) and within EIR (yellow). This is useful, assuming that the policing function of the service provider at the PE device ingress is color-aware. Now bandwidth is used more efficiently than with color-blind policers, due to

The indication for the color-aware policer occurs by an Ethernet priority bit value or a DSCP. An example for the indication according to MEF 23 follows, with a Class of service Low.

At the Ethernet layer, as an example,

• green marking is indicated at the Ethernet frame by the least significant priority bit value of ‘1’;
• yellow marking is indicated at the Ethernet frame by the least significant priority bit value of ‘0’.

At the IP layer, similarly as an example,

• green marking is indicated at the IP header with a DSCP value of 10 (decimal) (AF11);
• yellow marking is indicated at the IP header with a DSCP value of 12 (AF12), 14 (AF13) or 0 (Default).

Additional issue is that the above marking is not by MEF defined for CoS High. A suitable CoS with color marking as in the above example would need to be selected.

The real-time and control traffic is shaped and pre-colored green by the base station when entering the service. Assuming a color-aware policer at the service provider ingress, the green frames pass through as long as they do not exceed the CIR rate at the ingress of the policer. Because of shaping, they do not exceed the CIR.² Shaping should take into account all relevant protocol overheads. These depend on what layer information is referred to with the committed information rate attribute. See Section 5.5 concerning Bandwidth profiles within MEF services.

Currently most of the MEF services available support only color-blind operation at the UNI. If this is the case, then multiple CoSs are needed in order to separate real-time/control traffic from the background.