WO2022220926A1

WO2022220926A1 - Application aware networks with dns qos extension and semantic addressing

Info

Publication number: WO2022220926A1
Application number: PCT/US2022/017567
Authority: WO
Inventors: Haoyu Song; Donald Eggleston Eastlake, Iii
Original assignee: Futurewei Technologies, Inc.
Priority date: 2022-02-23
Filing date: 2022-02-23
Publication date: 2022-10-20

Abstract

A method for requesting a Quality of Service (QoS) implemented by a client device. The method includes the client device encoding a QoS request in a domain name system (DNS) query. The client device transmits the DNS query to a DNS server. The client device receives an answer to the transmitted DNS query from the DNS server. The answer includes at least one DNS resource record (RR) that includes information that satisfies the QoS request in the query. The client device connects to a service using the information from the at least one DNS RR.

Description

APPLICATION AWARE NETWORKS WITH DNS QOS EXTENSION AND

SEMANTIC ADDRESSING

BACKGROUND

[0001] The Domain Name System (DNS) is the hierarchical and decentralized naming system used to identify computers, services, and other resources reachable through the Internet or other computer network such as Internet Protocol (IP) networks. The resource records contained in the DNS associate domain names with other forms of information including IP addresses.

SUMMARY

[0002] A first aspect relates to a method for requesting Quality of Service (QoS) implemented by a client device. The method includes the client device encoding a QoS request in a DNS query. The client device transmits the DNS query to a DNS server. The client device receives an answer to the transmitted DNS query from the DNS server. The answer includes at least one DNS resource record (RR) that includes information that satisfies the QoS request in the query. The client device connects to a service using the information from the at least one DNS RR.

[0003] Optionally, in a first implementation according to the first aspect, the information is an IP address.

[0004] Optionally, in a second implementation according to the first aspect or any implementation thereof, the DNS query comprises a modified domain name comprising the QoS request encoded with a domain name.

[0005] Optionally, in a third implementation according to the first aspect or any implementation thereof, the modified domain name comprises the QoS request prepended to the domain name.

[0006] Optionally, in a fourth implementation according to the first aspect or any implementation thereof, the method further includes the client device prepending the QoS request to the domain name in one of a hexadecimal format or a base32 format that indicates a set of QoS requirements.

[0007] Optionally, in a fifth implementation according to the first aspect or any implementation thereof, the method further includes the client device prepending the QoS request to the domain name as a predetermined QoS profile that indicates a predefined set of QoS requirements. [0008] Optionally, in a sixth implementation according to the first aspect or any implementation thereof, the QoS request comprises set of QoS requirements, wherein a particular QoS requirement of the set of QoS requirements has a first field in the QoS request indicating the particular QoS requirement, a second field indicating a data size encoding for the particular QoS requirement in the QoS request, and a third field according to the data size encoding that specifies a value for the particular QoS requirement.

[0009] Optionally, in a seventh implementation according to the first aspect or any implementation thereof, the set of QoS requirements comprises a latency limit.

[0010] Optionally, in an eighth implementation according to the first aspect or any implementation thereof, the set of QoS requirements comprises a bandwidth requirement.

[0011] Optionally, in a ninth implementation according to the first aspect or any implementation thereof, the set of QoS requirements comprises a packet loss limit.

[0012] Optionally, in a tenth implementation according to the first aspect or any implementation thereof, the method further includes the client device encoding a protocol requirement as part of the DNS query.

[0013] Optionally, in an eleventh implementation according to the first aspect or any implementation thereof, the method further includes the client device encoding a service type requirement as part of the DNS query.

[0014] Optionally, in a twelfth implementation according to the first aspect or any implementation thereof, the QoS request comprises one or more QoS prefixes.

[0015] In an embodiment, a second aspect relates to a method for satisfying a QoS request implemented by a DNS authoritative server. The method includes the DNS authoritative server receiving, from a client device, a modified DNS request comprising a QoS request. The DNS authoritative server identifies one or more services that satisfy the QoS request. The DNS authoritative server sends to the client device at least one DNS resource record (RR) corresponding to one or more services that satisfies the QoS request.

[0016] In a first implementation form of the computer-implemented method according to the second aspect, the at least one DNS RR includes IP addresses.

[0017] In a second implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the QoS request is encoded in a modified domain name in the modified DNS request. [0018] In a third implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the modified domain name comprises the QoS request prepended to a domain name.

[0019] In a fourth implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the QoS request is in one of a hexadecimal format or base32 format that indicates a set of QoS requirements.

[0020] In a fifth implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the QoS request comprises one or more QoS requirements, wherein each QoS requirement has a first field indicating a particular QoS requirement, a second field indicating a data size encoding for the particular QoS requirement in the QoS request, and a third field according to the data size encoding that specify a value for the particular QoS requirement.

[0021] In a sixth implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the QoS request indicates a predefined set of QoS requirements.

[0022] In a seventh implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the set of QoS requirements or predefined set of QoS requirements comprises a latency limit.

[0023] In an eighth implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the set of QoS requirements or predefined set of QoS requirements comprises a bandwidth requirement.

[0024] In a ninth implementation form of the computer-implemented method according to the second aspect or any preceding implementation form of the second aspect, the set of QoS requirements or predefined set of QoS requirements comprises a packet loss limit.

[0025] A third aspect relates to an apparatus that includes a memory storing instructions; and a processor coupled to the memory. The processor is configured to execute the instructions to cause the apparatus to perform any of the preceding aspects or any preceding implementation of the preceding aspects.

[0026] For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure. [0027] These and other features, and the advantages thereof, will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF DRAWINGS

[0028] To describe the technical solutions in the embodiments of the present disclosure more clearly, the following briefly describes the accompanying drawings for describing the embodiments. It is clear that, the accompanying drawings in the following description show merely some embodiments of the present disclosure, and an ordinary person skilled in the art may derive other drawings from these accompanying drawings.

[0029] FIG. 1 is a schematic diagram depicting a DNS resolution process according to an embodiment of the present disclosure.

[0030] FIG. 2 is a diagram illustrating an example of a DNS query in accordance with an embodiment of the present disclosure.

[0031] FIG. 3 is a diagram illustrating the QoS label in accordance with an embodiment of the present disclosure.

[0032] FIG. 4 is a diagram illustrating an example of a DNS query in accordance with an embodiment of the present disclosure.

[0033] FIG. 5 is a flowchart illustrating a method for requesting QoS in a DNS query in accordance with a disclosed embodiment of the present disclosure.

[0034] FIG. 6 is a flowchart illustrating a method for satisfying a QoS request in a DNS query in accordance with a disclosed embodiment of the present disclosure.

[0035] FIG. 7 is a schematic diagram of an apparatus configured to implement one or more of the methods disclosed herein according to an embodiment of the disclosure.

DESCRIPTION OF EMBODIMENTS

[0036] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0037] Application-aware networks can provide differentiated services to specific applications to meet their QoS requirements. QoS means one or more guaranteed network performance level. Such requirements may include latency, packet loss, bandwidth, jitter limits, cost, and security. The methods include multipath, slicing, segment routing, traffic engineering, packet marking, etc. However, it is difficult for an application to express the application’s QoS requirements to the network and for the network to inform applications that some measures have been taken. The disclosed embodiments seek to enable applications to directly express one or more QoS requirements, if necessary, and enable the appropriate QoS treatment to be automatically applied to the application’ s network connections, without modifying the socket interface or introducing other out-of-band approaches.

[0038] Accordingly, the present disclosure provides various embodiments of systems and methods for requesting one or more QoS requirements in a DNS query. ADNS query is a request for information sent from a client device to a DNS server. The disclosed embodiments support application aware networking without changes to basic application programming interfaces (APIs) and the DNS protocol. In particular, the disclosed embodiments enable an application on a client device to express QoS preferences or requirements through a DNS query by extending the DNS query to include the QoS requirements. In an embodiment, the DNS returns an answer that includes one or more semantic addresses, which imply the provided QoS guarantee. The semantic address may include a segment list for segment routing (SR) and an Internet protocol (IP) address with semantic bits for QoS. The application then sends packets using the semantic address. The network identifies and responds to the semantic address (e.g., by performing multipath, slicing, segment routing, traffic engineering, packet marking, etc.). In an embodiment, when the network cannot satisfy one or more of the requested QoS requirements, the network returns the best-effort address result. The DNS result can be bound to a flow and effective for the lifetime of the flow.

[0039] The DNS is a distributed database system that stores data under hierarchical domain names and supports redundant servers, data caching, and security features. This data is formatted into resource records (RRs) whose content type and structure are indicated by the RR Type field. The RRs contained in the DNS associate domain names with other forms of information including IP addresses.

[0040] In addition, DNS names and data are defined as being in a Class, where the same name could mean different things in different Classes. Even RR Types, unless the Type has been defined as being Class independent, could indicate different kinds of data in different Classes. However, the only Class that is widely supported by existing DNS implementations or deployments is the “IN” or Internet Class.

[0041] Domain names comprise a sequence of labels with labels further to the right being at a higher level in the name hierarchy and labels to the left of a particular label identifying nodes in the hierarchical tree of nodes below that particular label. Each label is limited to 63 octets in length and the zero-length null label is reserved to identify the root node. In a complete, valid domain name, the sum of the length of each label in the name plus one octet of overhead per label (including the terminating null label) may not exceed 255 octets. The DNS is a binary clean protocol permitting any octet value within a label (including, for example, octets consisting of all zero bits or all one bits), but for ease in use and due to user interface restrictions, labels are commonly limited to American Standard Code for Information Interchange (ASCII) character values (see Internet Engineering Task Force (IETF) Request for Comments (RFC) 0020 by V. Cerf entitled “ASCII format for Network Interchange” published October 16, 1969). Furthermore, for name matching purposes, the DNS does not distinguish between octets having the upper-case and lower-case codes for an ASCII letter. In some cases, the storage of a label in the DNS and/or later retrieval of the label may change the value of an octet in that label between the values for upper-case and lower-case version of an ASCII letter (see IETF RFC 4343 by D. Eastlake 3^rd entitled “Domain Name System (DNS) Case Insensitivity Clarification” published January 2006). [0042] DNS data is divided into zones. Each zone has an apex node and a Class and consists of the nodes below that apex in the DNS name tree for that Class excluding the names in that zone that are inside any sub-zone. Any designated name in a zone may be made the apex zone of a sub-zone excluding all names below the designated node from the zone. DNS data security works at the zone level so that the authority for a zone may authenticate a retrieved set of RRs or may authenticate that there are no RRs of the type queried at the name queried. Pairwise security may also be available to provide security features for messages or transactions between DNS clients/servers that are communicating directly with each other. [0043] The most common use of the DNS is to map from a host name or a domain name to an IP address. The term host name is often used interchangeably with domain name, but there are subtle differences between the two. All hostnames are domain names, but not all domain names are host names. A hostname of a particular system may have one or more IP addresses associated with the hostname as might a domain name that is not a host name. A host name may be a DNS name whose first label is composed entirely of digits, letters, and hyphens and that does not begin or end with a hyphen. There are RR Types for storing Internet Protocol version 4 (IPv4) (Type “A”), Internet Protocol version 4 (IPv6) (Type “AAAA”), and other kinds of addresses. Querying a host name for an address type returns the set of all RRs at that name with that type. Usually, the client will select randomly from among these RRs for the address that the client will use. For example, querying the DNS name “foo. example” for type AAAA would return the set of AAAA records, which are records providing an IPv6 address, at that name. Applications using widely deployed APIs to obtain the address of a host or service use Class IN and RR Types of A or AAAA. [0044] As an extension to the above, DNS provides for mapping of a service, and a protocol to access that service, into an IP address and a port number. The extension uses a DNS RR for specifying the location of services (DNS SRV) (see IETF RFC 2782 by A. Gulbrandsen, et al, entitled “ADNS RR for specifying the location of services (DNS SRV)” published February 2000) whose data portion includes a priority, weight, port, and target name. A query may be done with query type SRV and the name being queried structured as “ service. _proto. name” where “ service” is the service name desired and “ _proto” is the protocol to be used both prefixed with an underscore character. For example, a query of type SRV for “_ldap._tcp.example.com” would be a query for information on contacting the Lightweight Directory Access Protocol (LDAP) service via the Transmission Control Protocol (TCP) as associated with the name “example.com.” When a client processes the set of such RRs returned by a query for RR type SRV, the client selects at random from among those RRs with the highest priority for initial connection attempts and may try lower priority SRV RRs when a connection based on a higher priority SRV RRs fails. Within a priority, RRs to try are selected at random, but with the probability of selecting any particular RR proportional to the weight field in that RR. The client would use the “target name” field in the SRV result in a second DNS query to obtain the IP address to contact using the protocol specified in the name queried for the SRV type and with the port number returned in the SRV result. [0045] The DNS is effectively a “store and forward” protocol. Typically, a client issues a query to some local sever. When that server is authoritative for the data being sought, the server can directly respond with the data. When the server is not authoritative for the data sought, depending on the server, the server can return a referral (e.g., a pointer to a server that should be able to return a better answer) or, when the server has an unexpired cached answer, the server can return the cached answer. When the server does not have a cached answer, in a process called “recursion,” the server may construct a query and send the query to another server on behalf of the client. The server subsequently receives and possibly caches the results of that query, and returns those results to the client. A server which issues such queries to other servers on behalf of a client may be called a “caching” or “recursive” server.

[0046] RRs as returned include a time-to-live (TTL) in seconds. The TTL controls how long the data is held in cache by a non-authoritative DNS server before the data expires. A TTL of zero indicates that an answer is only to be used in responding to a single query.

[0047] DNS provides a variety of ways to include information in a query. These include “meta-RRs” which are RRs included in an additional information section of a query and are only forwarded one hop. Thus, meta-RRs would not be forwarded by a recursive server. Such meta- RRs include the option (“OPT”) RR and RRs that can provide one-hop security to authenticate queries and responses (“TSIG”, “SIG(0)”, etc.). Other information in a query such as the domain name under which RRs are being queried, the RR Type for which RRs are being queried, and the class are inherent parts of the query and would, for example, be forwarded by a caching recursive server when the server does not have an unexpired cached answer.

[0048] To illustrate a DNS resolution process, FIG. 1 is a schematic diagram depicting a DNS resolution process 100 according to an embodiment of the present disclosure. The DNS resolution process 100 translates a domain name or host name to one or more IP addresses. A domain name identifies a node in the DNS hierarchy. Each domain name has a human readable text string equivalent (e.g., weather.com) and one or more IP addresses may be stored at the identified DNS node. The one or more IP addresses may be used in IP protocol messages. An IP address is assigned to each device on the Internet. DNS servers eliminate the need for humans to memorize IP addresses such as 192.168.1.1 (for IPv4), or more complex newer alphanumeric IP addresses such as 2400:cb00:2048:l::c629:d7a2 (for IPv6). [0049] In the depicted embodiment, a client device 102 executes one or more applications or programs that require or request a connection to a service associated with a particular domain name. The client device 102 may be any type of device or system including, but not limited to, Internet of Things (IoT) devices, computers, smartphones, and connected vehicles. Examples of applications may include, but are not limited to, web browser applications, video streaming applications, financial applications, map and/or traffic applications, and weather applications. As stated above, applications may deploy APIs to obtain the address of a host or service. To obtain the address of a host or service, the client device 102 transmits a DNS query containing a domain name as indicated by arrow 1 in FIG. 1. As will be further described, in accordance with the disclosed embodiments, the DNS query may include a QoS request. A QoS request is a request for one or more guaranteed network performance levels associated with a service corresponding to the domain name. The one or more guaranteed network performance levels are referred to as QoS requirements. Such QoS requirements may include latency, packet loss, bandwidth, jitter limits, cost, and security.

[0050] A DNS recursive resolver 104 receives the DNS query from the client device 102. The DNS recursive resolver 104 is a server that accepts a recursive query and processes the response by making the necessary requests. In a recursive query, the client device 102 relies on a DNS server (typically the DNS recursive resolver 104) to respond to the client device 102 with either the requested RR or an error message when the resolver cannot find the resource record. As stated above, DNS recursive resolver 104 is a server that issues queries to other servers on behalf of the client 102. In an embodiment, the DNS recursive resolver 104 issues a series of requests until the DNS recursive resolver 104 reaches the authoritative DNS nameserver for the requested record (or times out or returns an error when no record is found).

[0051] For instance, as indicated by arrow 2, the DNS recursive resolver 104 first queries a DNS root nameserver 106. As stated above, DNS data is divided into zones. The DNS root nameserver 106 is a DNS nameserver that operates in the root zone. All DNS lookups start at the root zone. For instance, the DNS recursive resolver 104 stores a list of all the IP root server addresses. Whenever a DNS lookup is initiated, the first communication performed by the DNS recursive resolver 104 is with one of the DNS root servers unless it has the information that it would request from the root server cached. The DNS root nameserver 106 can answer queries for records stored or cached within the root zone. Assuming, the DNS root nameserver 106 cannot provide an answer to the query, the DNS root nameserver 106 responds, as indicated by arrow 3, to the DNS recursive resolver 104 with the address of a DNS top level domain (TLD) nameserver 108, which stores the information for domains under the DNS TLD nameserver 108. Atop-level domain is one of the domains at the highest level in the hierarchical DNS of the Internet after the root zone. Examples of top-level domains include .com, .org, .net, .gov, and .edu. [0052] The DNS recursive resolver 104 then sends a query request to the DNS TLD nameserver 108 as indicated by arrow 4. The DNS TLD nameserver 108 can provide an answer to the query request when the answer was previously cached, and the data has not expired. As stated above, DNS RRs can only be cached for a set amount of time according to the TTL specified in the DNS RRs. Assuming, the DNS TLD nameserver 108 cannot provide an answer to the query, the DNS TLD nameserver 108 responds, as indicated by arrow 5, with an IP address of a DNS authoritative nameserver 110 that can provide an answer to the query.

[0053] The DNS recursive resolver 104 then sends a query request, as indicated by arrow 6, to the DNS authoritative nameserver 110. The DNS authoritative nameserver 110 is a server that actually holds, and is responsible for, DNS RRs. The DNS authoritative nameserver 110 is at the bottom of the DNS lookup chain that will respond, as indicated by arrow 7, with the queried RR or RRs that includes one or more IP address that maps to the queried host or domain name. Although not shown, in some instances, where the query is for a subdomain such as “foo.example.com,” an additional nameserver will be added to the sequence after the DNS authoritative nameserver 110, which is responsible for storing the subdomain’s records.

[0054] The DNS recursive resolver 104 then responds to the client device 102, as indicated by arrow 8, with the answer to the initial query. In an embodiment, the answer includes at least one DNS RR comprising information such as an address that satisfies the QoS request in the initial query.

[0055] As indicated by arrow 9, the client device 102, or an application executing on the client device 102, connects to a service (e.g., a server 120) using the information from at least one DNS RR. The server 120 provides data back to the client device 102 as indicated by arrow 10.

[0056] The disclosed embodiments piggyback on top of the above-described DNS resolution process to support application aware networking without changes to basic APIs and the DNS protocol. In particular, the disclosed embodiments enable an application on the client device 102 to express QoS preferences or requirements through a DNS query by extending the DNS query to include one or more QoS requirements such as, but not limited to, latency, packet loss, bandwidth, jitter limits, cost, and security. In an embodiment, the DNS returns an answer that includes one or more semantic addresses, which imply the provided QoS guarantee.

[0057] FIG. 2 is a diagram illustrating an example of a DNS query 200 in accordance with an embodiment of the present disclosure. In an embodiment, an application expresses one or more QoS requirements (e.g., latency, bandwidth) for a destination or service name using the DNS query 200 by encoding those requirements in one or more QoS labels such as in QoSlabell 202 and in QoSlabel2 204 in the DNS query 200. The one or more QoS labels proceed a domain name 206 (e.g., example.com) in the DNS query 200. The one or more QoS labels (e.g., QoSlabell 202) in the queried DNS name may incorporate a field indicating QoS requirements or a sequence of fields indicating the QoS requirements.

[0058] As an example, FIG. 3 is a diagram illustrating the QoSlabell 202 in accordance with an embodiment of the present disclosure. In an embodiment, the QoSlabell 202 includes a fixed readable QoS prefix 210 to indicate that a DNS query includes a QoSlabel that specifies a QoS requirement. An example of the QoS prefix 210 could be “qs— ” as shown in FIG. 3. Other prefixes may be also used to indicate that a DNS query includes a QoSlabel. The QoS prefix 210 may be analogous to the fixed prefix “xn— ” added to be beginning of internationalized domain names.

[0059] In an embodiment, following the QoS prefix 210, the QoSlabell 202 includes a first field 212, second field 214, and the third field 216. In other embodiments, the QoSlabell may include more or less fields than depicted in FIG. 3. In an embodiment, such one or more fields could be in a fixed order and format, or each such field could be preceded by an indication of a field type and format. For example, a field can be preceded by an octet having the field type indicated in the field’s high order nibble and field format and length in the field’s low order nibble. A nibble is half a byte. Low order nibble are the bits 0-3 and high order nibble are bits 4-7. In an alternative embodiment, there could be a combination of one or more fields in a fixed order or position and format along with one or more fields labeled as to their type and format. An example format would be the Institute of Electrical and Electronics Engineers (IEEE) 32-bit floating point for the values when appropriate as the format provides a compact notation that can encode up to approximately 10³⁸ and down to approximately 10 ³⁸ with 6 to 9 significant digits of precision [see “IEEE Standard for Binary Floating-Point Arithmetic,” in ANSI/IEEE Std 754-1985, vol, no., pp.1-20, 12 Oct. 1985] Alternatively, other numeric formats may be used for QoS requirements. Such QoS parameter type and value sequences are essentially binary data. To avoid possible problems with DNS case insensitivity (see RFC 4343) or sensitivity, due to implementation bugs, to a byte of all zero bits in a label, or the like unusual non-ASCII bytes, such data should be encoded and avoid problematic values in the encoded result. One such method would be to encode the data as hexadecimal. In another embodiment, the data may be encoded using base32 (see IETF RFC 4648 entitled “The Basel6, Base32, and Base64 Data Encodings” by S. Josefsson published October 2006) without any trailing padding characters. Yet, in another embodiment, the Bootstring (see IETF RFC 3491 entitled “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)” by P. Hoffman, et al, published March 2003) algorithm with appropriate parameters (similar to the Punycode (see IETF RFC 3492 entitled “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)” by A. Costello published March 2003) profiling of Bootstring, but for QoS requirements) may be used for encoding the QoS requirements. Such encoding may expand the data byte by about a factor of two into name bytes.

[0060] In an embodiment, the first field 212 contains data indicating the particular QoS requirement, the second field 214 contains data indicating a data size encoding for the particular QoS requirement in the QoS request, and the third field 216, according to the data size encoding specified in the second field 214, contains data that specifies a value for the particular QoS requirement. The terms first, second, and third do not imply any particular order. For example, a QoS requirement for a bounded latency with a minimum bandwidth could be represented as a sequence of 10 bytes, each requirement indicated by a requirement type/format byte followed by 4 bytes of value in IEEE 32-bit floating point format. Processed through an encoding method such as hexadecimal and prefixed by “qs— ”, the resulting ASCII character string would be 24 bytes long and suitable for use as a label in a DNS query.

[0061] In an embodiment, general indications of the relative type of service desired, such as “low latency” or “high bandwidth”, could be encoded into a few bits or a byte similar to the IPv4 Type of Service byte (see IETF RFC 1349 “Type of Service in the Internet Protocol Suite” by P. Almquist published July 1992) or the Differentiated Services IP header field (see IETF RFC 2474 “Definition of the Differentiated Services Field (DS Field) in IPv4 and IPv6 Headers” by K. Nichos, et al, published December 1998) or any similar encodings. [0062] In an embodiment, other types of labels beginning with the underscore character to indicate a service or a protocol desired could also be included with a QoS requirements label or labels in a domain name to be queried. For example, FIG. 4 is a diagram illustrating an example of a DNS query 400 in accordance with an embodiment of the present disclosure. The DNS query 400 includes the modified domain name “qs— (QoSparameters) ldap. _tcp.example.com” comprising a QoS prefix qs— 412 followed by QoSparameters 414 that specify one or more QoS requirements. The QoSparameters 414 may be specified in one or more fields. The ldap prefix 416 and the _tcp prefix 418 specify a query for information on contacting the Lightweight Directory Access Protocol (LDAP) service via the Transmission Control Protocol (TCP) protocol as associated with the domain name “example.com” 420 and having a particular QoS requirement as specified by the QoSparameters 414. Other prefixes may also be included in the modified domain name or the order of prefixes could be different such as a service label and a protocol label followed by a QoS requirements label followed by the rest of the domain name. Since QoS requirements can occur in more than one label in a domain name, such QoS requirements labels could occur both before and after service and/or protocol labels. For example, in another alternative embodiment, a DNS name with QoS requirements encoded into one or more labels of that name is used in a DNS query for an SRV RR or for some other type of RR.

[0063] In one embodiment, the DNS server maintains the binding between the name and several semantic addresses. The DNS server returns a semantic address which implies the provided QoS assurances. The semantic address contains not only the destination address, but also extra information about the treatment to the packet. Each semantic address represents that some QoS requirements can be satisfied. The semantic addresses can be dynamically computed or statically configured. Based on the query, the DNS server returns a set of semantic addresses which can meet the application’s QoS requirement and may return an error when the requirement cannot be met.

[0064] Once the client device, or more particularly, the application executing on the client device receives the reply, the application may simply use the address to forward the packet. The disclosed embodiments may be effective for applications that are ignorant of this QoS requesting scheme. In some embodiments, the application may decode packet labeling or handling information from the returned address and obtain a desired QoS by using such information. The semantic address may be cached for the lifetime of the flow. In an alternative embodiment, the DNS response TTL may indicate the period of time for which the semantic address will provide the QoS assurances, and the application may again query the DNS at or shortly before the end of the time to refresh the semantic address or obtain a new one that will be effective for a future interval. When an edge router receives the packet, the edge router may apply the QoS treatment to the packet according to the semantic address. In another embodiment, an application might query with QoS requirements for an RR type that returns other information as to how to obtain service meeting those requirements.

[0065] FIG. 5 is a flowchart illustrating a method 500 for requesting QoS implemented by a client device in accordance with a disclosed embodiment of the present disclosure. At step 502, the client device encodes a QoS request in a DNS query. In an embodiment, the DNS query includes a modified domain name. The modified domain name includes the QoS request encoded with a domain name. The QoS request may include one or more QoS requirements. In an embodiment, the one or more QoS requirements may include, but are not limited to, a latency limit, a bandwidth requirement, a packet loss limit, a jitter limit, a cost limit, or a security requirement. In an embodiment, the client device prepends the QoS request to the domain name. In an embodiment, the client device prepends the QoS request to the domain name using a hexadecimal format or a base32 format that indicates a set of QoS requirements. Other types of formats may also be suitable for the disclosed embodiments. As described in FIG. 3, the encoding for a particular QoS requirement may include a first field indicating the particular QoS requirement, a second field indicating a data size encoding for the particular QoS requirement in the QoS request, and a third field that specifies a value for the particular QoS requirement according to the data size encoding.

[0066] In some embodiments, the QoS request may include one or more QoS prefixes to indicate a particular type of requirement is included in the modified domain name. For example, the prefix “qs— ” or “_qs” or another designated prefix may be added prior to one or more QoS requirements in the modified domain name to indicate that the modified domain name includes a QoS requirement. In some embodiments, the client device can also encode a protocol requirement and/or a service type requirement in the domain name as part of the modified domain name.

[0067] In another embodiment, the client device prepends the QoS request to the domain name as a predetermined QoS profile that indicates a predefined set of QoS requirements. As a non- limiting example, there may be three predetermined QoS profiles: default, very low latency with limited bandwidth, and very high bandwidth with relaxed latency. Each QoS profile corresponds to a predefined set of QoS requirements, one not necessarily better than the other. Different types of applications may prefer different QoS requirements.

[0068] At step 504, the client device transmits the DNS query to a DNS server. As described in FIG. 1, the DNS query may be received by a DNS Recursive resolver such as DNS Recursive resolver 104, which attempts to locate a DNS Authoritative nameserver that can satisfy the DNS query. At step 506, the client device receives an answer to the transmitted DNS query from the DNS server. In an embodiment, the answer includes at least one DNS RR that includes information that satisfies the QoS request in the query. In an embodiment, the information includes a semantic address. A semantic address is an address that includes extra semantics (e.g., service or QoS information) encoded along with a destination ID in the address.

[0069] In an embodiment, the semantic address is an IP address such as an IPv4 or IPv6 address. For example, the semantic address may be a structured IPv6 address that includes additional information. For instance, in an embodiment, the semantic address may be a 128-bit IPv6 address = 120-bit host address + 8-bit QoS indicator with each code representing some specific QoS guarantee. In another embodiment, the semantic address may be a 128-bit IPv6 address with optional fields for protocol parameters to achieve desired QoS assurances. Possible fields may include 5G Network Slice Selection Assistance Information (NSSAI, 20 bits consisting of 8 bits of slice type and 12 bits of slice distinguisher), IP Differentiated Services Code Point (DSCP, as described in IETF RFC 2474 entitled “Definition of the Differentiated Services Field (DS Field) in IPv4 and IPv6 Headers” by K. Nichos, et al, published December 1998), IEEE 802 Priority Code Point (PCP, 3 bits) and/or Drop Eligibility Indicator (DEI, 1 bit) as described in “IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks,” in IEEE Std 802. IQ-1998 , vol, no., pp.1-214, 8 March 1999, and the like. The portion of the IPv6 address with optional QoS protocol parameters may be set to a fixed value such as zero when then address is used as an IPv6 address. In an embodiment, a new RR Type including an IP address and additional fields for protocol parameters may be defined to achieve the desired QoS assurances such as those listed above.

[0070] At step 508, the client device connects to a service using the information from at least one DNS RR. In some embodiments, the client device may perform one or more additional DNS queries to obtain an IP address for connecting to the service using the information from the at least one DNS RR. In an embodiment, the client device or more particularly, an application executing on the client device sends packets using the semantic address. One advantage of the disclosed embodiments is that no modification may be required to an application’s API (i.e., socket). The application does not need to be aware that the application is using a semantic address. Additionally, the DNS query that includes a modified domain name can be implemented using standard DNS process as described in FIG. 1. Only a DNS Authoritative nameserver needs to resolve the modified domain name to identify the one or more requested QoS requirements.

[0071] FIG. 6 is a flowchart illustrating a method 600 for satisfying a QoS request in accordance with a disclosed embodiment of the present disclosure. The method 600 may be implemented by a DNS authoritative server such as, but not limited to, the DNS Authoritative nameserver 110 in FIG. 1. At step 602, the DNS authoritative server receives a modified DNS request comprising a QoS request that originated from a client device. In an embodiment, the QoS request is encoded in a modified domain name in the modified DNS request. For example, the modified domain name comprises the QoS request prepended to a domain name. The DNS authoritative server decodes the QoS request to determine the parameters of the one or more requested QoS requirements. In an embodiment, the QoS request may indicate a predefined set of QoS requirements. At step 604, the DNS authoritative server identifies one or more services and/or communications methods that satisfy the QoS request. A service can be a particular server or can be a particular path to a server. For example, there may be two addresses for a server so that a request to that server follow different paths. Depending on which address is used, the QoS may be different and dependent on which path is used, and not due to the particular server. In some instances, the QoS could depend on both the particular server and the path to that server. Thus, term service is intended to encompass both a path to a server and the server. At step 606, the DNS authoritative server sends to the client device at least one DNS RR corresponding to one or more services that satisfy the QoS request. In an embodiment, the at least one DNS RR includes one or more IP addresses.

[0072] FIG. 7 is a schematic diagram of an apparatus 700 configured to implement one or more of the methods disclosed herein according to an embodiment of the disclosure. For example, the apparatus 700 may represent the sending device 100, the receiving device 102, a client device, and/or a server as described herein. The apparatus 700 comprises ingress ports 710 and receiver units (Rx) 720 for receiving messages, a processor, logic unit, or central processing unit (CPU) 730 to process the messages, transmitter units (TX) 720 and egress ports 740 for transmitting the messages, and a memory 750.

[0073] The processor 730 is implemented by any suitable combination of hardware, middleware, and firmware. The processor 730 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or digital signal processors (DSPs). The processor 730 is in communication with the ingress ports 710, receiver units 720, transmitter units 720, egress ports 740, and memory 750.

[0074] The memory 750 comprises one or more disks, tape drives, or solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, or to store instructions and data that are read during program execution. The memory 750 may be volatile and/or non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), or static random- access memory (SRAM). In one embodiment, the memory 750 comprises a DNS QoS semantic addressing module 760. The DNS QoS semantic addressing module 760 comprises executable instructions and data configurations that when executed by the processor 730 implements the disclosed embodiments as described herein.

[0075] While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. A person skilled in the art would understand how to combine any or all of the above techniques in a vast variety of permutations and combinations.

[0076] The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0077] These disclosed embodiments improve network and application technology by enabling one or more QoS requirements to be included in a DNS query. The QoS requirements can be encoded into the DNS name being queried in a DNS query such that those requirements may be automatically forwarded to an authoritative server without interference by any intervening recursive DNS servers. The disclosed embodiments support application aware networking without changes to basic application programming interfaces (APIs) and the DNS protocol. In particular, the disclosed embodiments enable an application on a client device to express QoS preferences or requirements through a DNS query by extending the DNS query to include the QoS requirements. In an embodiment, the DNS returns an answer that includes one or more semantic addresses, which imply the provided QoS guarantee. Use of the disclosed embodiments requires no modification to application API (i.e., socket) and may be implemented using standard DNS messages and protocol. In an embodiment, the RR lookup at the authoritative server is modified unless the authoritative server is pre-configured with all the QoS labels that will be looked up. The disclosed embodiments work for IPv6/SRv6 and allows SRv6 to extend into host. In an embodiment, when Ipv6 is used, a destination can have multiple Ipv6 addresses (e.g., a common Ipv6 prefix and multiple suffixes with each encoding some specific QoS requirements). A particular SRv6 segment list (i.e., a path) can naturally reflect some QoS assurances. The disclosed embodiments apply to all network environments such as, but not limited to, data center networks, enterprise networks, and carrier backbone networks.

[0078] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, optically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method for requesting a Quality of Service (QoS) implemented by a client device, the method comprising: encoding a QoS request in a domain name system (DNS) query; transmitting the DNS query to a DNS server; receiving an answer to the transmitted DNS query from the DNS server, wherein the answer includes at least one DNS resource record (RR) comprising information that satisfies the QoS request in the DNS query; and connecting to a service using the information from the at least one DNS RR.

2. The method according to claim 1, wherein the information comprises an Internet protocol (IP) address.

3. The method according to any of claims 1-2, wherein the DNS query comprises a modified domain name comprising the QoS request encoded within a domain name.

4. The method according to claim 3, wherein the modified domain name comprises the QoS request prepended to the domain name.

5. The method according to claim 4, further comprising prepending the QoS request to the domain name in a format that indicates a set of QoS requirements, wherein the format is a hexadecimal format or a base32 format.

6. The method according to claim 4, further comprising prepending the QoS request to the domain name as a predetermined QoS profile that indicates a predefined set of QoS requirements.

7. The method according to any of claims 1-6, wherein the QoS request comprises set of QoS requirements, wherein a first QoS requirement of the set of QoS requirements has a first field in the QoS request indicating the particular QoS requirement, a second field indicating a data size encoding for the particular QoS requirement in the QoS request, and a third field that specifies a value for the particular QoS requirement according to the data size encoding.

8. The method according to any of claims 5-7, wherein the set of QoS requirements comprises a latency limit.

9. The method according to any of claims 5-8, wherein the set of QoS requirements comprises a bandwidth requirement.

10. The method according to any of claims 5-9, wherein the set of QoS requirements comprises a packet loss limit.

11. The method according to any of claims 5-10, wherein the set of QoS requirements comprises a jitter limit.

12. The method according to any of claims 5-11, wherein the set of QoS requirements comprises a cost limit.

13. The method according to any of claims 5-12, wherein the set of QoS requirements comprises a security requirement.

14. The method according to any of claims 1-13, further comprising encoding a protocol requirement as part of the DNS query.

15. The method according to any of claims 1-14, further comprising encoding a service type requirement as part of the DNS query.

16. The method according to any of claims 1-15, wherein the QoS request comprises one or more QoS prefixes.

17. An apparatus comprising: a memory configured to store instructions; and one or more processors coupled to the memory and configured to execute the instructions, which when executed cause the apparatus to: encode a Quality of Service (QoS) request in a domain name system (DNS) query; transmit the DNS query to a DNS server; receive an answer to the transmitted DNS query from the DNS server, wherein the answer includes at least one DNS resource record (RR) comprising information that satisfies the QoS request in the query; and connect to a service using the information from at least one DNS RR.

18. The apparatus according to claim 17, wherein the information comprises an Internet protocol (IP) address.

19. The apparatus according to any of claims 17-18, wherein the DNS query comprises a modified domain name comprising the QoS request encoded with a domain name.

20. The apparatus according to claim 19, wherein the modified domain name comprises the QoS request prepended to the domain name.

21. The apparatus according to claim 20, wherein the instructions when executed by the one or more processors, further cause the apparatus to prepend the QoS request to the domain name in a format that indicates a set of QoS requirements, wherein the format is a hexadecimal format or a base32 format.

22. The apparatus according to claim 20, wherein the instructions when executed by the processor, further causes the apparatus to prepend the QoS request to the domain name as a predetermined QoS profile that indicates a predefined set of QoS requirements.

23. The apparatus according to any of claims 17-22, wherein the QoS request comprises a set of QoS requirements, wherein a first QoS requirement of the set of QoS requirements has a first field in the QoS request indicating the particular QoS requirement, a second field indicating a data size encoding for the particular QoS requirement in the QoS request, and a third field that specifies a value for the particular QoS requirement according to the data size encoding.

24. The apparatus according to any of claims 21-23, wherein the set of QoS requirements comprises a latency limit.

25. The apparatus according to any of claims 21-23, wherein the set of QoS requirements comprises a bandwidth requirement.

26. The apparatus according to any of claims 21-23, wherein the set of QoS requirements comprises a packet loss limit.

27. The apparatus according to any of claims 21-23, wherein the set of QoS requirements comprises a jitter limit.

28. The apparatus according to any of claims 17-27, wherein the instructions when executed by the processor, further causes the apparatus to encode a protocol requirement as part of the DNS query.

29. The apparatus according to any of claims 17-28, wherein the instructions when executed by the processor, further causes the apparatus to encode a service type requirement as part of the DNS query.

30. The apparatus according to any of claims 17-29, wherein the QoS request comprises one or more QoS prefixes.

31. A method for satisfying a Quality of Service (QoS) request implemented by a Domain Name System (DNS) authoritative server, the method comprising: receiving a modified DNS request comprising a QoS request from a client device; identifying one or more services that satisfy the QoS request; and sending at least one DNS resource record (RR) corresponding to one or more services that satisfy the QoS request to the client device.

32. The method according to claim 31, wherein the at least one DNS RR include IP addresses.

33. The method according to any of claims 31-32, wherein the QoS request is encoded in a modified domain name in the modified DNS request.

34. The method according to claim 33, wherein the modified domain name comprises the QoS request prepended to a domain name.

35. The method according to any of claims 31-34, wherein the QoS request is in one of a hexadecimal format or base32 format that indicates a set of QoS requirements.

36. The method according to any of claims 31-35, wherein the QoS request comprises one or more QoS requirements, wherein each QoS requirement has a first field indicating a particular QoS requirement, a second field indicating a data size encoding for the particular QoS requirement in the QoS request, and a third field according to the data size encoding that specify a value for the particular QoS requirement.

37. The method according to any of claims 31-36, wherein the QoS request indicates a predefined set of QoS requirements.

38. The method according to any of claims 31-37, wherein the set of QoS requirements or predefined set of QoS requirements comprises a latency limit.

39. The method according to any of claims 31-38, wherein the set of QoS requirements or predefined set of QoS requirements comprises a bandwidth requirement.

40. The method according to any of claims 31-39, wherein the set of QoS requirements or predefined set of QoS requirements comprises a packet loss limit.

41. The method according to any of claims 31-40, wherein the set of QoS requirements or predefined set of QoS requirements comprises a cost limit.

42. The method according to any of claims 31-41, wherein the set of QoS requirements or predefined set of QoS requirements comprises a security requirement.

43. An apparatus comprising: a memory configured to store instructions; and a processor coupled to the memory and configured to execute the instructions, which when executed causes the apparatus to: receive a modified DNS request comprising a QoS request from a client device; identify one or more services that satisfy the QoS request; and send at least one DNS resource record (RR) corresponding to one or more services that satisfies the QoS request to the client device.

44. The apparatus according to claim 43, wherein the at least one DNS RR includes IP addresses.

45. The apparatus according to any of claims 43-44, wherein the QoS request is encoded in a modified domain name in the modified DNS request.

46. The apparatus according to claim 45, wherein the modified domain name comprises the QoS request prepended to a domain name.

47. The apparatus according to any of claims 43-46, wherein the QoS request is in one of a hexadecimal format or base32 format that indicates a set of QoS requirements.

48. The apparatus according to any of claims 43-47, wherein the QoS request comprises one or more QoS requirements, wherein each QoS requirement has a first field indicating a particular QoS requirement, a second field indicating a data size encoding for the particular QoS requirement in the QoS request, and a third field according to the data size encoding that specify a value for the particular QoS requirement.

49. The apparatus according to any of claims 43-48, wherein the QoS request indicates a predefined set of QoS requirements.

50. The apparatus according to any of claims 43-49, wherein the set of QoS requirements or predefined set of QoS requirements comprises a latency limit.

51. The apparatus according to any of claims 43-50, wherein the set of QoS requirements or predefined set of QoS requirements comprises a bandwidth requirement.

52. The apparatus according to any of claims 43-51, wherein the set of QoS requirements or predefined set of QoS requirements comprises a packet loss limit.