Section 6.2. QoS in IPv6 Protocols

6.2. QoS in IPv6 Protocols

The designers of IPv6 have focused not on requiring specific mechanisms for QoS, but on offering as much flexibility as possible to support different QoS mechanisms. This section describes the elements in the IPv6 header and the Extension headers that can be used for QoS services.

6.2.1. IPv6 Header

There are two fields in the IPv6 header that can be used for QoS: the Traffic Class and the Flow Label field.

6.2.1.1. Traffic Class

The use of the 1-byte Traffic Class field is specified in RFC 2474. As already mentioned, this RFC introduces the term "DS field" for the Traffic Class field. The goal of this specification is that DiffServ routers have a known set of DS routines, which are determined by the value in the DS field. These DSCP values are mapped to Per-Hop Behaviors (PHB) and can be either performance- or class-based. Figure 6-1 shows the DS field.

Figure 6-1. Format of the DS field

The DSCP field within the DS field (the six most significant bits of the DS field) is used for the codepoint, which specifies the PHB. With this field, 64 different codepoints can be specified. This codepoint pool has been divided into three parts to control the assignment of PHBs. Table 6-1 shows the division of the DSCP pools.

Table 6-1. The codepoint pools

Pool	Codepoint space	Assignment policy
1	xxxxx0	Standard use
2	xxxx11	Experimental/local use
3	xxxx01	Experimental/local use; potential standard use in the future

A pool of 32 recommended codepoints (pool 1) is assigned through formal standardization; a pool of 16 more codepoints (pool 2) is reserved for experimental or local use; the final pool of 16 codepoints (pool 3) is initially available for experimental or local use but should be used as an overflow pool if pool 1 is used up.

The PHBs specify how packets should be forwarded. A default PHB denominated by an all-zeros DS codepoint must be provided by any DS router. The default PHB describes the common, best-effort forwarding behavior available in existing routers. Such packets are forwarded without adhering to any priority policy; in other words, the network will deliver as many of these packets as possible as soon as possible, based on existing resources such as memory or processing capacity. Packets received with an undefined codepoint should also be forwarded as though they were marked for the default behavior.

The DS field does not specifiy PHBs; it specifies codepoints. The number of codepoints is limited to 64, whereas the number of PHBs is unlimited. There are recommended mappings of codepoints to PHBs. These mappings can be defined individually within administrative domains, which makes the number of possible PHBs unlimited. The coding rules for PHB IDs are specified in RFC 3140, "Per Hop Behavior Identification Codes." RFC 2597 defines a PHB group called Assured Forwarding (AF); RFC 3246 defines a PHB called Expedited Forwarding (EF).

Recommended codepoints and PHB IDs are assigned by IANA. The list of codepoints can be found at http://www.iana.org/assignments/dscp-registry, and the list of PHB IDs at http://www.iana.org/assignments/phbid-codes.

Figure 6-2 shows the DS field in a trace file.

Figure 6-2. The DS field in a trace file

This is a RIPng (RIP Next Generation) Response from our Cisco router. It is sent to the RIP Routers Multicast address of FF02::9. The DS field is set to 0xE0 (decimal notation 224, binary notation 1110 0000), which is decoded by Sniffer with Preferential Forwarding.

The remaining two bits of the DS field (see Figure 6-1) are not used according to RFC 2474, and are specified in RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP." They provide four possible codepoints (00 to 11) that are used for Congestion Notification. Usually the overload of a router could only be determined based on packet loss. With the use of these Congestion Notification Codepoints, a router can signal overload before packet loss. This method is similar to Frame Relay's use of BECNs and FECNs (Backwards and Forwards Explicit Congestion Notification).

The two bits are used as follows:

• 00: Packet does not use ECN.

• 01/10: Sender and receiver are ECN-enabled.

• 11: Router signals congestion.

6.2.1.2. Flow Label

The 20-bit Flow Label field in the IPv6 header may be used by a source to label packets for which it requests special handling by the IPv6 routers, such as nondefault QoS or real-time service. A flow label is assigned to a flow by the flow's source node. Between a sender and a receiver, there can be multiple flows active in parallel, along with the exchange of packets with no QoS requirements. New flow labels must be chosen randomly from the range 00001 to FFFFF. The purpose of the random allocation is to make any combination of bits within the Flow Label field suitable for use as a hash key by routers for looking up the state associated with the flow.

Hosts or routers that do not support the functions of the Flow Label field (most of today's applications, which will not be modified to use the Flow Label, or which do not need QoS handling) are required to set the field to all zeros when sending a packet, to pass the field on unchanged when forwarding a packet, and to ignore the field content when receiving a packet.

All packets belonging to the same flow must be sent with the same IP Source address, IP Destination address, identical source and destination ports, and a nonzero flow label. If any of these packets includes a Hop-By-Hop Options header, they all must be originated with the same Hop-By-Hop Options header contents (excluding the Next Header field of the Hop-By-Hop Options header, which is allowed to differ). If any packet includes a Routing Extension header, they all must be created with the same contents in all Extension headers up to and including the Routing Extension header (again excluding the Next Header field in the Routing Extension header). The routers or receivers are allowed to verify that these conditions are satisfied. If a violation of these consistency rules is detected, a corresponding error message is returned, indicating the exact location of the rule violation.

The handling of the flow label on routers is efficient, and when IPsec is used, it is always available because the IPv6 header is not encrypted by ESP or authenticated by AH (in transport mode). This implies that the integrity of the information in the DS field cannot be guaranteed by IPsec.

RFC 3697, "IPv6 Flow Label Specification," is a new specification of the Flow Label. A flow is defined as a sequence of packets from a sender to a specific unicast, anycast, or multicast address labeled as a flow by the sender. A flow is not necessarily associated with a transport connection. A host running multiple sessions with another host should be able to assign a different flow label to each session. Where the original specification defines a flow based on five criteria, the new specification definies a flow based on three criteria (Source and Destination address and flow label). The reason for this is that these three fields are always available for examination by routers, whereas the source and destination port number can be hidden by ESP.

6.2.2. IPv6 Extension Headers

As outlined earlier, two IPv6 Extension headers can be used to signal QoS requirements:

• The Routing Extension header can be used to request a specific route by indicating a sequence of nodes to be used (a "loose source route" in IPv4 terminology). However, use of this Extension header requires the requester to have knowledge about the preferred route (i.e., the network topology and QoS-sensitive parameters, such as possible throughput, etc.). To discourage attacks on the routing system, a packet sent in response to a received packet that included a routing header must not include a routing header that was automatically generated by "reversing" the received routing header (as is often done in IPv4 loose source routing) unless the integrity and authenticity of the received source IP address and routing header can be verified (e.g., via an Authentication Extension header in the received packet).

• The Hop-By-Hop Options header can be used to transport a maximum of one router alert signaling message per IP packet (RFC 2711) to every router on the path of QoS-sensitive traffic, indicating that each router should specifically process the IP packet. The use of the Hop-By-Hop Options header allows fast processing by the router because no analysis of higher-level protocol headers is required. Routers that are unable to recognize the router alert option type are required to ignore this option and continue processing the header. Also, routers are not allowed to change the option while the packet is in transit. Router alert types that have been defined so far are shown in Table 6-2.

Table 6-2. Currently defined router types

Value	Description
0	IP packet contains a Multicast Listener Discovery message.
1	IP packet contains an RSVP message.
2	IP packet contains an Active Networks messagethe sender is attempting to load a program into the router for executing customized functions.
3-35	IP packet contains an Aggregated Reservation Nesting Level (RFC 3175, RSVP)
36-65,535	Reserved to IANA for future use.

A detailed description of these headers can be found in Chapter 2. An updated list of router alert types can be found at http://www.iana.org/assignments/ipv6-routeralert-values.

6.2.3. IPv6 Label Switch Architecture (6LSA)

One new proposal using the Flow Label field is the IPv6 Label Switch Architecture (6LSA). A new usage of the Flow Label field is proposed, the 6LSA architecture is described, and a method of binding packets to Forwarding Equivalence Classes (FECs) is discussed.

The 6LSA architecture is similar in many respects to Multiprotocol Label Switching (MPLS). Labels are assigned to IPv6 packets, which are then used to provide QoS services across a 6LSA domain. 6LSA uses the Flow Label field instead of a shim header, however, to carry the label information, thus avoiding fragmentation and certain performance issues, as well as providing an end-to-end layer 3 tag for QoS.

The 6LSA architecture is still a very new concept and will need to go through peer review in the IETF before it is finalized. While its ultimate acceptance and deployment are unknown, its development is a sign that the QoS community for IPv6 continues to work on providing better models.