Quality of Service (QoS) (IPv6)

The enterprise networks of today are designed to be complex global communications infrastructures. These networks are the platform to enable a multitude of applications and services. QoS protocols have the task of providing different application streams with priorities and metrics such as

■ Bandwidth

■ Delay

■ Interpacket delay variation (jitter)

■ Packet loss

The following sections discuss the differences between IPv6 and IPv4 QoS, extension headers, and IPv4 and IPv6 coexistence. This provides a better understanding of QoS implementation for both protocols, which is useful when planning migration.

Differences Between IPv6 and IPv4 QoS

Differences between implementations of QoS in IPv4 and IPv6 mostly revolve around the traffic-classification process, where packets or flows are differentiated through the use of various parameters such as IP source address, IP destination address, Differentiated Services Code Point (DSCP), or IP precedence values and other higher-level protocol types. After they are classified, the packets can be processed according to a policy that reflects their service level. Table 4-2 summarizes the differences between IPv4 and IPv6 for QoS mechanisms.

Table 4-2 Differences Between IPv4 and IPv6 for QoS Mechanisms

QoS Mechanism Implementation		IPv4	IPv6
Classification	Precedence	Y	Y
	DSCP	Y	Y
Marking	Class-based marking	Y	Y
	Committed Access Rate	Y	Y
	Policy-based routing	Y	Y
Policing and	Rate limiting	Y	Y
shaping	Class-based policing	Y	Y
	Generic traffic shaping	Y	N
	Frame Relay traffic shaping	Y	Y
Congestion	Weighted Random Early	Y	Y
avoidance	Detection
Congestion	First In First Out	Y	Y
management	Priority queuing	Y	Y (Legacy method not supported)
	Custom queuing	Y	N
	Low-latency queuing	Y	Y

The type of service (ToS) field in the IPv4 packet header is mapped identically to the Traffic Class field in IPv6, and it is used in the same fashion. With IPv6, however, several additional classifiers must be considered, all related to the IPv6 packet header format:

■ Protocol type or version: Because of the anticipated coexistence of the two protocols, it is worth considering the case where different service levels are applied to IPv4 and IPv6 traffic. The Protocol Type field can distinguish between the two protocols. Additionally, more discrete classifications can be done for the traffic for each protocol type.

■ Flow label: The flow label is unique to IPv6 and was originally intended for use with resource-reservation-based QoS architectures. It was meant to enable routers to easily recognize a flow for which the resources were reserved. RFC 3697 documents the flow label specifications. This field has the advantage of being located before the Source Address and the Destination Address fields, and that placement helps reduce lookup delays.

Table 4-3 highlights the differences between IPv4 and IPv6 headers.

Table 4-3 IPv4 and IPv6 Header Comparison

IPv4 Header Field	IPv6 Header Field
Version	Different version number. Field is the same.
Header Length	Removed in IPv6. Fixed at 40 bytes.
Total Length	Payload Length.
Identification, Flags, Fragment Offset	Removed in IPv6.
Time-to-Live (TTL)	Hop Limit.
Protocol	Next Header.
Header Checksum	Removed in IPv6.
Source Address	Source Address (size is 128 bits).
Destination Address	Destination Address (size is 128 bits).
Options	Removed with IPv6 extension headers.
Type of Service	Traffic Class.

IPv6 Extension Headers

In an IPv6 datagram, one or more extension headers might appear before the encapsulated payload. These headers provide an efficient and flexible method to create IPv6 datagrams. Only special-purpose fields are put into extension headers when needed. The IPv4 header had a provision for options, and it would have been possible to use options for IPv6 as well. However, a better design was needed for certain sets of information, such as fragmenting and other common functions. Options are still needed for IPv6 because they are used to provide even more flexibility. Extension headers are included in an IPv6 datagram; they appear one after the other following the main header, as illustrated in Figure 4-5.

Two IPv6 extension headers can be used for QoS requirements:

■ The routing extension header can request a specific route based on the requester’s knowledge of the network topology and QoS-sensitive parameters such as possible throughput.

■ The hop-by-hop header is the only extension header that must be fully processed by all the devices in the path of the QoS-sensitive data. The use of this header enables faster processing by the network device because there is no analysis of higher-lever protocols. Network devices that cannot recognize this header are required to ignore and continue processing the header. Network devices are not allowed to change this header while the packet is in transit.

Figure 4-5 IPv6 Packet with Extension Headers

IPv4 and IPv6 Coexistence

There are two approaches possible with the coexistence of IPv4 and IPv6:

■ IPv6 traffic is treated differently than IPv4 by using two different QoS policies.

■ IPv6 traffic is treated the same as IPv4 by using a single QoS policy that classifies and matches on both protocols.

The per-hop behaviors (PHB) for the two protocols might be different under the following considerations:

■ IPv4 traffic is revenue generating, and it most likely is more important for the business than the IPv6 traffic, at least in the beginning. In that case, you might choose to prioritize the IPv6 traffic lower than IPv4 and provide fewer resources for it.

■ IPv4 and IPv6 traffic might have to observe different PHBs depending on traffic patterns used by various applications.

In these cases, different classes and policies should be defined for each traffic type.

With transition mechanisms, the IPv6 traffic can leverage the deployed QoS of the traversed IPv4 infrastructure. In some circumstances, the IPv6 traffic might also lose its markings after crossing the IPv4 network.

As applications demand higher performance from an enterprise network, differentiating at the network layer protocol has lost its relevance. End users running a particular application (for example, video) do not care about the network layer being used and expect the same level of network quality irrespective of the network layer protocol. This approach also reduces the management overhead for the QoS deployment. For implementing QoS at Layer 2, it is recommended that no differentiation should be made between the two protocol types.