Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries

2.2.1. Service Requirement TLV Encoding

Each TLV expressing a service requirement can be thought of as being binarily encoded as shown in Figure 1 although the specified encoding below in a DNS label is more readable.¶

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|     Type      |    Length     |
+---+---+---+---+---+---+---+---+
|  Value (Length Bytes Long)    .
.                               .
.                               .
.................................

Type:

4-bit unsigned integer indicating the type of service requirement.¶

Length:

4-bit unsigned integer indicating the length of the value associated with the service requirement in bytes. The presence of an explicit length makes it possible to skip unknown / unimplemented service requirements.¶

Value:

The value, if any, associated with the service requirement.¶

Although the DNS does not constraint the octet values within a label, for ease of use and due to user interface restrictions, label octets are commonly limited to a subset of printing ASCII [RFC0020] character values. Furthermore, for name matching purposes, the DNS does not distinguish between octets having the upper case and lower case codes for an ASCII letter and in some cases the storage of a label in the DNS and/or its later retrieval may change the value of an octet in that label between the values for upper and lower case version of an ASCII letter [RFC4343].¶

To avoid possible problems with this DNS case insensitivity or possibly problematic byte values such as zero, the TLV or sequence of TLVs is included in the DNS name label in hexadecimal notation with one hex digit per byte using ASCII [RFC0020]. For "A" through "F", either upper or lower case may be used. Although there are more compact encoding that avoid most of these problems, for example as a customization of Bootstring similar to Punycode [RFC3492] or Base32 [RFC4648], hexdecimal is used for simplicity, to make the encoding into names more easily readable for debugging and other purposes, and to provide ample reserved code points for future extensions.¶

Such future extensions MUST use the same four prefix bytes and be structured as TLVs but may assign meaning to Type byte values reserved in this document and may extend the meaning of the Length to accomodate longer values by allowing letters "G" through "Z" (or "g" through "z") indicating Value length of 17 through 36 bytes. Length byte MUST NOT be any value than "0" through "9", "A" through "Z", or "a" through "z" and if such a prohibited value ocurrs, that TLV and the reaminder of he label MUST be ignored.¶

2.2.2. Requirements Types and Value Encoding

The following types of QoS requirements are initially defined. If more than one requirements TLV of the same type occurs in a DNS name, all but the first (leftmost) occurrance MUST be ignored.¶

Coarse: A general indication of the most important service being sought encoded as a one byte integer patterned after the IPv4 ToS (Type of Service) value specified in [RFC1349]. (This is "coarse" in contrast with the more precise service requirements defined further below.) The following coarse values are defined:¶

0x00 - Normal service.¶

0x01 - Minimize cost.¶

0x02 - Maximize reliability.¶

0x04 - Maximize throughput.¶

0x08 - Minimize delay.¶

0x10 - Minimize jitter.¶

Bandwidth: The bandwidth requirement is encoded as a float32 (32-bit IEEE floating point format [ieee754] number). The unit is bits per second.¶

Delay: The delay requirement is encoded in 24-bit integer format. The unit is microseconds.¶

Jitter: The jitter (i.e., delay variation) is encoded in 24-bit integer format. The unit is microseconds.¶

Loss Rate: This lost rate (i.e., the percentage of packet loss) is encoded in 24-bit integer format. The basic unit is 0.000001% (i.e., one packet drop per 100 million packets), where (2^24 - 2) = 16.777214% is the largest loss rate defined, 2^24-1 means no loss rate requirement, and 0 means the drop rate should be smaller than 0.000001%.¶

Using IEEE 32-bit floating point for the values when appropriate provides a compact notation that can encode up to approximately 10^38 and down to approximately 10^-38 with 6 to 9 significant digits of precision [ieee754].¶

2.2.3. Complete QoS DNS Names

The on-the-wire encoding of a domain name beginning with a service requirement label would be as shown in Figure 2 below. (In the DNS wire encoding, each label is preceded by a byte that indicates its length.)¶

+-------+-------+-----+   +-----+--------------------------------+
|length |prefix |TLV1 |...|TLVn |Encoded Remainder of Domain Name|
+-------+-------+-----+   +-----+--------------------------------+

Alternatively, service requirements could split among a sequence of two or more labels in a DNS name to be queried, as shown in Figure 3.¶

+-------+------+----+   +-------+------+----+-----------------+
|length |prefix|TLV1|...|length |prefix|TLVn|Remainder of Name|
+-------+------+----+   +-------+------+----+-----------------+

A display presentation of a DNS name requesting a coarse QoS requirement for minimum delay for communication with example.com would be as shown in Figure 4.¶

                 qs--  Prefix
                    1  TLV Type
                    1  TLV Length
                   08  TLV Value
          example.com  Remainder of domain name

qs--1108.example.com.  Complete domain name

4.1.1. R-LDH Registry

IANA is requested to create a registry on the Domain Name System (DNS) Parameters webpage as follows:¶

Name: DNS Restricted LDH (R-LDH) Label Prefixes¶

Registration Procedure: Expert Review¶

Reference: [this document]¶

4.1.2. R-LDH Expert Guidance

In reviewing applications for the assignment of an R-LDH prefix, the Expert should keep in mind the following guidance:¶

1. The use of labels with the requested prefix must be documented in an Internet Draft or RFC,¶
2. not significantly duplicate the use of any other R-LDH prefix,¶
3. not require any changes to DNS protocol messages or DNS mechanisms such as the handling of CNAME or DNAME RRs or wildcards, and¶
4. provide a substanial additional capability.¶
5. Prefixes where the first or second character is any of the digits "0", "1", and "5" or the letters "O", "I", and "L" should not be assigned, due to the possibilities of confusion, unless there are strong reasons to use these characters.¶
6. Assignment of more than one R-LDH for a purpose is prohibited. The remainder of an R-LDH label MUST include an appropriate extension mechanism such as a version number or multiple unassigned code points such that later versions or extensions can be accodated without the assignment of a new R-LDH label. If it is necessary to distinguish sub-uses under an R-LDH prefix, this should be done by encoding within the R-LDH label after the prefix or by a further label or labels before and/or after the R-LDH label, such as a label beginning with underscore ("_").¶

4.2.1. Coarse Requirements Label Values

IANA is requested to create a sub-registry on the Domain Name System (DNS) Parameters webpage under the Requirements Label Type Codes registry as follows:¶

Name: DNS QoS Coarse Requirements Label Values¶

Registration Procedure: Expert review¶

Reference: [this document]¶