Application-aware networks leveraging DNS QoS extensions and semantic addressing

Abstract

A method implemented by a client device for requesting Quality of Service (QoS). The method comprises: the client device encoding a QoS request in a domain name system (DNS) query; the client device sending the DNS query to a DNS server; the client device receiving a response to the sent DNS query from the DNS server, wherein the response comprises at least one DNS resource record (RR), the at least one DNS RR comprising information satisfying the QoS request in the query; the client device connecting to a service using the information in the at least one DNS RR.

Description

Background Technology

[0001] The Domain Name System (DNS) is a hierarchical, decentralized naming system used to identify computers, services, and other resources accessible via the Internet or other computer networks (such as Internet Protocol (IP) networks). Resource records included in DNS associate domain names with other forms of information, including IP addresses. Summary of the Invention

[0002] The first aspect relates to a method implemented by a client device for requesting Quality of Service (QoS). The method includes: the client device encoding a QoS request in a DNS query; the client device sending the DNS query to a DNS server; the client device receiving a response from the DNS server to the sent DNS query, wherein the response includes at least one DNS resource record (RR), the at least one DNS RR including information satisfying the QoS request in the query; and the client device using the information in the at least one DNS RR to connect to a service.

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

[0004] Optionally, according to the first aspect or any of its implementations, in the second implementation, the DNS query includes a modified domain name, the modified domain name including the QoS request encoded using the domain name.

[0005] Optionally, according to the first aspect or any of its implementations, in a third implementation, the modified domain name includes the QoS request pre-placed in the domain name.

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

[0007] Optionally, according to the first aspect or any of its implementations, in the fifth implementation, the method further includes: the client device prepending the QoS request in the domain name as a predetermined QoS profile indicating a set of predefined QoS requirements.

[0008] Optionally, according to the first aspect or any of its implementations, in the sixth implementation, the QoS request includes a set of QoS requirements, wherein a specific QoS requirement in the set of QoS requirements includes a first field indicating the specific QoS requirement in the QoS request, a second field indicating the data size encoding of the specific QoS requirement in the QoS request, and a third field encoding the data size to specify a value for the specific QoS requirement.

[0009] Optionally, according to the first aspect or any of its implementations, in the seventh implementation, the set of QoS requirements includes latency limitations.

[0010] Optionally, according to the first aspect or any of its implementations, in the eighth implementation, the set of QoS requirements includes bandwidth requirements.

[0011] Optionally, according to the first aspect or any of its implementations, in the ninth implementation, the set of QoS requirements includes packet loss restrictions.

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

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

[0014] Optionally, according to the first aspect or any of its implementations, in the twelfth implementation, the QoS request includes one or more QoS prefixes.

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

[0016] According to the second aspect, in a first implementation of the computer implementation method, the at least one DNS RR includes an IP address.

[0017] According to the second aspect or any of the above implementations of the second aspect, in a second implementation of the computer implementation method, the QoS request is encoded in the modified domain name in the modified DNS request.

[0018] According to the second aspect or any of the above implementations of the second aspect, in a third implementation of the computer implementation method, the modified domain name includes the QoS request prepended to the domain name.

[0019] According to the second aspect or any of the above implementations of the second aspect, in a fourth implementation of the computer implementation method, the QoS request adopts a hexadecimal format or base32 format indicating a set of QoS requirements.

[0020] According to the second aspect or any of the above implementations of the second aspect, in a fifth implementation of the computer implementation method, the QoS request includes one or more QoS requirements, each QoS requirement including a first field indicating a specific QoS requirement, a second field indicating the data size encoding of the specific QoS requirement in the QoS request, and a third field encoding a value for the specific QoS requirement according to the data size.

[0021] According to the second aspect or any of the above implementations of the second aspect, in a sixth implementation of the computer implementation method, the QoS request indicates a set of predefined QoS requirements.

[0022] According to the second aspect or any of the above-described implementations of the second aspect, in a seventh implementation of the computer implementation method, the set of QoS requirements or the set of predefined QoS requirements includes latency limitations.

[0023] According to the second aspect or any of the above implementations of the second aspect, in the eighth implementation of the computer implementation method, the set of QoS requirements or the set of predefined QoS requirements includes bandwidth requirements.

[0024] According to the second aspect or any of the above implementations of the second aspect, in the ninth implementation of the computer implementation method, the set of QoS requirements or the set of predefined QoS requirements includes packet loss restrictions.

[0025] The third aspect relates to an apparatus. The apparatus 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 above aspects or any of the above-described implementations of the above aspects.

[0026] For clarity, any of the above embodiments may be combined with any one or more of the other embodiments described above to create new embodiments within the scope of this disclosure.

[0027] These and other features and their advantages will become clearer from the following detailed description in conjunction with the accompanying drawings and claims. Attached Figure Description

[0028] To more clearly describe the technical solutions in the embodiments of this disclosure, the accompanying drawings used to describe the embodiments are briefly introduced below. Obviously, the drawings in the following description only illustrate some embodiments of this disclosure, and those skilled in the art can derive other drawings based on these drawings.

[0029] Figure 1 This is a schematic diagram of a DNS resolution process provided in one embodiment of this disclosure.

[0030] Figure 2 This is an illustration of an example of a DNS query provided in one embodiment of this disclosure.

[0031] Figure 3 This is an illustration of a QoS tag provided in one embodiment of this disclosure.

[0032] Figure 4 This is an illustration of an example of a DNS query provided in one embodiment of this disclosure.

[0033] Figure 5 This is a flowchart of a method for requesting QoS in a DNS query, provided in one embodiment of this disclosure.

[0034] Figure 6 This is a flowchart of a method for satisfying QoS requests in a DNS query, provided in one embodiment of this disclosure.

[0035] Figure 7 This is a schematic diagram of an apparatus for implementing one or more of the methods disclosed herein, provided in one embodiment of the present disclosure. Detailed Implementation

[0036] First, it should be understood that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods can be implemented using any number of techniques, whether currently known or existing. This disclosure is by no means limited to the illustrative implementations, drawings, and techniques described below, including the exemplary designs and implementations illustrated and described herein, but can be modified within the full scope of the appended claims and their equivalents.

[0037] Application-aware networks can provide differentiated services to specific applications to meet their QoS requirements. QoS refers to one or more guaranteed network performance levels. These requirements can include latency, packet loss, bandwidth, jitter limits, cost, and security. Methods for achieving these requirements include multipathing, slicing, segmented routing, traffic engineering, packet tagging, etc. However, it is difficult for applications to express their QoS requirements to the network, and it is also difficult for the network to notify applications that some measures have been taken. The embodiments disclosed in this disclosure are intended to enable applications to directly express one or more QoS requirements when necessary, and to enable appropriate QoS processing to be automatically applied to the application's network connectivity without modifying the socket interface or introducing other out-of-band methods.

[0038] Therefore, this disclosure provides various embodiments of systems and methods for requesting one or more QoS requirements in a DNS query. A DNS query is a request for information sent by a client device to a DNS server. Embodiments disclosed in this disclosure support application-aware networking without altering the underlying application programming interface (API) and DNS protocol. Specifically, embodiments disclosed in this disclosure enable applications on client devices to express QoS preferences or requirements via DNS queries by extending DNS queries to include QoS requirements. In one embodiment, the DNS returns a response including one or more semantic addresses that implicitly represent the QoS guarantees it can provide. The semantic addresses may include a list of segments for segment routing (SR) and an Internet protocol (IP) address with semantic bits for QoS. The application then sends packets using the semantic addresses. The network (e.g., by performing multipathing, slicing, segment routing, traffic engineering, packet tagging, etc.) identifies and responds to the semantic addresses. In one embodiment, when the network cannot satisfy one or more requested QoS requirements, it returns a best-effort address result. The DNS result may be bound to a flow and remain in effect for the lifetime of that flow.

[0039] 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 as resource records (RRs), the content type and structure of which are indicated by the RR type field. The RRs included in DNS associate domain names with other forms of information, including IP addresses.

[0040] Furthermore, DNS names and data are defined within a single category, but the same name can have different meanings in different categories. Even the RR type can indicate different types of data in different categories unless the type has been defined as category-independent. However, the only category widely supported by existing DNS implementations or deployments is the "IN" or Internet category.

[0041] A domain name consists of a series of tags, where the rightmost tags are at higher levels in the name hierarchy, while the tags to the left of a particular tag identify the nodes in the hierarchical tree below that particular tag. Each tag is limited to 63 octets in length, with a 0-byte empty tag reserved to identify the root node. In a fully valid domain name, the sum of the length of each tag plus the overhead of one octet per tag (including the terminating empty tag) must not exceed 255 octets. DNS is a binary clean protocol that allows the use of any octet value within tags (including octets consisting entirely of 0 bits or all 1 bits), but for ease of use and due to limitations in the user interface, tags are typically limited to American Standard Code for Information Interchange (ASCII) character values ​​(see the Internet Engineering Task Force (IETF) Request for Comment (RFC) 0020, entitled "ASCII format for Network Interchange," published by V. Cerf on October 16, 1969). Furthermore, for name matching, DNS does not distinguish between octets with uppercase and lowercase ASCII letter encodings. In some cases, the value of the octets in a label may change when the label is stored in DNS and / or retrieved later, causing it to vary between uppercase and lowercase ASCII letter values ​​(see January 2006 by D. Eastlake 3). rd The IETF RFC 4343 was published with the title “Clarification of Domain Name System (DNS) Case Insensitivity”.

[0042] DNS data is divided into multiple zones. Each zone has a vertex node and a class, and includes all nodes below the vertex node in the DNS name tree for that class, but excludes names within any sub-zones of that zone. Any specified name within a zone can become a vertex zone for a sub-zone, while all names below the specified node are excluded from that zone. DNS data security operates at the zone level, so the zone's authorizing party can verify a retrieved set of RRs, and can also verify that there are no RRs of the queried type for the queried name. Pairwise security can also be used to provide security features for messages or transactions between DNS clients / servers that communicate directly with each other.

[0043] The most common use of DNS is mapping hostnames or domain names to IP addresses. The term "hostname" is often used interchangeably with domain name, but there are subtle differences. All hostnames are domain names, but not all domain names are hostnames. A hostname on a particular system may have one or more IP addresses associated with it, and a domain name that is not a hostname may also have one or more IP addresses associated with it. A hostname can be a DNS name whose first label consists entirely of numbers, letters, and hyphens, and does not begin or end with a hyphen. Various types of Records Records (RRs) exist to store addresses for Internet Protocol version 4 (IPv4) ("A" type), Internet Protocol version 6 (IPv6) ("AAAA" type), and other types. Querying the address type of a hostname returns the set of all RRs of that type under that hostname. Typically, a client randomly selects the address it wants to use from these RRs. For example, querying the AAAA type of the DNS name "foo.example" returns the set of AAAA records (records providing IPv6 addresses) under that name. Applications that use widely deployed APIs to obtain the address of a host or service will use RR of type IN and A or AAAA.

[0044] As an extension of the above, DNS can map services and the protocols that access those services to IP addresses and port numbers. This extension uses DNS RRs to specify the location of services (DNS SRV) (see IETF RFC 2782, published February 2000 by A. Gulbrandsen et al., entitled "A DNS RR for specifying the location of services (DNS SRV)"). The data portion of the service location includes priority, weight, port, and target name. The query type can be SRV, and the query name has the structure "_service._proto.name", where "_service" is the desired service name, and "_proto" is the protocol to be used, both prefixed with an underscore character. For example, an SRV query for "_ldap._tcp.example.com" is a query for information about contacting a Lightweight Directory Access Protocol (LDAP) service via Transmission Control Protocol (TCP), associated with the domain name "example.com". When a client processes the set of RRs returned by querying an SRV type, it randomly selects the highest-priority RR from these RRs for the initial connection attempt. If a connection based on a higher-priority SRV RR fails, the client may try a lower-priority SRV RR. Within the priority range, the RR to be tried is randomly selected, but the probability of selecting any particular RR is proportional to the weight field in that RR. The client uses the "Target Name" field from the SRV results in the second DNS query to obtain the IP address to contact using a protocol specified in the name of the SRV type used for the query, and the port number is included in the returned SRV results.

[0045] DNS is essentially a "store-and-forward" protocol. Typically, a client sends a query to a local server. When the server is authorized to provide the queried data, it can respond directly with that data. When the server is not authorized to provide the queried data, depending on the server, it may return a recommendation (e.g., a pointer to a server that should be able to return a better response), or, if the server has a cached response that hasn't expired, it may return that cached response. When the server doesn't have a cached response, in a process called "recursion," the server can construct a query and send it to other servers on behalf of the client. These other servers then receive and may cache the results of the query, and return those results to the client. Servers that send such queries to other servers on behalf of clients can be called "caching" or "recursive" servers.

[0046] The returned RR includes the time-to-live (TTL) in seconds. TTL controls how long a non-authoritative DNS server caches data before it expires. A TTL of 0 indicates that the response can only be used to respond to a single query.

[0047] DNS provides several methods for including information in queries. These methods include "meta-RRs," which are RRs included in the additional information section of a query and are forwarded only once. Therefore, recursive servers do not forward meta-RRs. These meta-RRs include option ("OPT") RRs and RRs that can provide one-hop security for authenticating queries and responses ("TSIG", "SIG(0)", etc.). Other information in the query (e.g., the domain name of the RR being queried, the RR type of the RR being queried, and the category) is inherent to the query; for example, cached recursive servers may forward this information if the server does not have an unexpired cached response.

[0048] To illustrate the DNS resolution process, Figure 1 This is a schematic diagram of a DNS resolution process 100 provided in one embodiment of this disclosure. The DNS resolution process 100 translates a domain name or hostname into one or more IP addresses. A domain name is used to identify a node in the DNS hierarchy. Each domain name has an equivalent human-readable text string (e.g., weather.com), and one or more IP addresses can be stored in the identified DNS node. One or more IP addresses can be used in IP protocol messages. Every device on the Internet is assigned an IP address. DNS servers do not require humans to remember IP addresses, such as 192.168.1.1 (corresponding to IPv4), or more complex new alphanumeric IP addresses, such as 2400:cb00:2048:1:c629:d7a2 (corresponding to IPv6).

[0049] In the described embodiment, client device 102 executes one or more applications or programs that request or require connection to a service associated with a specific domain name. Client device 102 can 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 transportation applications, and weather applications. As described above, the application may deploy an API to obtain the address of a host or service. To obtain the address of a host or service, client device 102 sends a DNS query including the domain name, such as... Figure 1 As shown by arrow 1 in the diagram. As detailed below, according to embodiments disclosed in this disclosure, a 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 a domain name. The one or more guaranteed network performance levels are referred to as QoS requirements. These QoS requirements may include latency, packet loss, bandwidth, jitter limits, cost, and security.

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

[0051] For example, as shown by arrow 2, DNS recursive resolver 104 first queries DNS root name server 106. As mentioned above, DNS data is divided into multiple zones. DNS root name server 106 is a DNS name server operating in the root zone. All DNS lookups begin in the root zone. For example, DNS recursive resolver 104 stores a list of all IP root server addresses. Whenever a DNS lookup is initiated, DNS recursive resolver 104 performs its first communication with one of the DNS root servers, unless DNS recursive resolver 104 has already cached the information requested from the root server. DNS root name server 106 can respond to queries for records stored or cached in the root zone. Assuming DNS root name server 106 cannot respond to a query, as shown by arrow 3, DNS root name server 106 responds to DNS recursive resolver 104 using the address of DNS top-level domain (TLD) name server 108, which stores information about the domains under DNS TLD name server 108. Top-level domains are one of the highest-level domains in the hierarchical DNS of the Internet, second only to the root zone. Examples of top-level domains include .com, .org, .net, .gov, and .edu.

[0052] Then, as indicated by arrow 4, the DNS recursive resolver 104 sends a query request to the DNS TLD name server 108. The DNS TLD name server 108 can provide a response to the query request if a previously cached response has been found and the data has not expired. As mentioned above, a DNS RR can only be cached for a limited time according to the TTL specified in the DNS RR. If the DNS TLD name server 108 is unable to provide a response to the query, then, as indicated by arrow 5, the DNS TLD name server 108 responds using the IP address of the DNS authoritative name server 110, which can provide a response to the query.

[0053] Next, as indicated by arrow 6, the DNS recursive resolver 104 sends a query request to the DNS authoritative name server 110. The DNS authoritative name server 110 is the server that actually stores and is responsible for the DNS lookup records. The DNS authoritative name server 110 is at the bottom of the DNS lookup chain, and as indicated by arrow 7, it responds with one or more queried RRs, including one or more IP addresses mapped to the queried hostname or domain name. Although not shown, in some cases, if the query is for a subdomain such as "foo.example.com", an additional name server is added after the DNS authoritative name server 110; this name server is responsible for storing the subdomain records.

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

[0055] As shown by arrow 9, client device 102 or an application running on client device 102 connects to the service (e.g., server 120) using information from at least one DNSRR. As shown by arrow 10, server 120 provides data back to client device 102.

[0056] The embodiments disclosed in this disclosure utilize the DNS resolution process described above to support application-aware networks without altering the underlying API and DNS protocol. Specifically, the embodiments disclosed in this disclosure enable applications on client device 102 to express QoS preferences or requirements via DNS queries by extending DNS queries to include one or more QoS requirements (e.g., but not limited to latency, packet loss, bandwidth, jitter limits, cost, and security). In one embodiment, the DNS returns a response including one or more semantic addresses that implicitly represent the QoS guarantees it can provide.

[0057] Figure 2 This is an illustration of an example of a DNS query 200 provided in one embodiment of this disclosure. In one embodiment, an application uses DNS query 200 to express one or more QoS requirements (e.g., latency, bandwidth) for a destination or service name by encoding these requirements in one or more QoS labels (e.g., QoSlabel1 202 and QoSlabel2 204 in DNS query 200). In DNS query 200, one or more QoS labels precede the domain name 206 (e.g., example.com). One or more QoS labels in the queried DNS name (e.g., QoSlabel1 202) may include a field indicating QoS requirements or a series of fields indicating QoS requirements.

[0058] For example, Figure 3 This is an illustration of a QoS label1 202 provided in one embodiment of this disclosure. In one embodiment, QoS label1 202 includes a fixed, readable QoS prefix 210, which is used to indicate that a DNS query includes a QoS label specifying QoS requirements. An example of the QoS prefix 210 could be... Figure 3 The “qs--” shown in the example. Other prefixes can also be used to indicate that DNS queries include QoS labels. The QoS prefix 210 can be similar to the fixed prefix “xn--” added to the beginning of an internationalized domain name.

[0059] In one embodiment, after the QoS prefix 210, QoSlabel1 202 includes a first field 212, a second field 214, and a third field 216. In other embodiments, QoSlabel1 may include a... Figure 3 More or fewer fields as described in the text. In one embodiment, one or more such fields may take a fixed order and format, or each field may be preceded by an indication of its field type and format. For example, a field may be preceded by an octet whose field type is indicated in the field's higher-order nibble, and whose field format and length are indicated in the field's lower-order nibble. A nibble is half a byte. The lower-order nibble is bits 0 to 3, and the higher-order nibble is bits 4 to 7. In an alternative embodiment, one or more fields taking a fixed order or position and format may be combined with one or more fields labeled with their type and format. An exemplary format is the Institute of Electrical and Electronics Engineers (IEEE) 32-bit floating-point value (if suitable), as this format provides a compact representation that can encode a maximum of approximately 10^32 floating-point values. 38 The minimum coded value is approximately 10. –38The precision is six to nine decimal places [see "IEEE Standard for Binary Floating-Point Arithmetic" on pages 1-20 of ANSI / IEEE Std754-1985, October 12, 1985]. Alternatively, QoS requirements can use other numeric formats. These QoS parameter types and value sequences are essentially binary data. To avoid problems that may arise from DNS case insensitivity (see RFC 4343) or from implementation errors that are sensitive to all-zero bytes or uncommon non-ASCII bytes in the tag, this data should be encoded, and problematic values ​​should be avoided in the encoded result. One approach is to encode the data in hexadecimal. In another embodiment, the data can be encoded using base32 (see IETF RFC 4648, titled "The Base16, Base32, and Base64 Data Encodings," by S. Josefsson, October 2006), without any trailing padding characters. However, in another embodiment, the QoS requirements can be encoded using a Bootstring algorithm with appropriate parameters (similar to Bootstring analysis using Punycode (see IETF RFC 3492, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)" by A. Costello, March 2003, but specifically for QoS requirements) (see IETF RFC 3491, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)" by P. Hoffman et al., March 2003). This encoding can expand the data bytes approximately by two times, transforming them into name bytes.

[0060] In one embodiment, the first field 212 includes data indicating a specific QoS requirement, the second field 214 includes data indicating the data size encoding of the specific QoS requirement in the QoS request, and the third field 216 includes data encoded as a value specified for the specific QoS requirement according to the data size specified in the second field 214. The terms "first," "second," and "third" do not indicate any particular order. For example, a QoS requirement for limited latency and minimum bandwidth can be represented as a 10-byte sequence, each requirement indicated by a requirement type / format byte followed by a 4-byte value in IEEE 32-bit floating-point format. After processing using encoding methods such as hexadecimal, the ASCII string prefixed with "qs--" is 24 bytes long, suitable for use as a tag in a DNS query.

[0061] In one embodiment, a general indication of the desired service of a particular type (e.g., “low latency” or “high bandwidth”) may be encoded as a few bits or a single byte, similar to the IPv4 type of service byte (see IETF RFC 1349, entitled “Type of Service in the Internet Protocol Suite”, published by P. Almquist in July 1992) or the Differentiated Services IP Header field (see IETF RFC 2474, entitled “Definition of the Differentiated Services Field (DS Field) in IPv4 and IPv6 Headers”, published by K. Nichos et al. in December 1998) or any similar encoding.

[0062] In one embodiment, other types of tags that begin with an underscore character and indicate the required service or protocol may also be included in the domain name being queried along with one or more QoS requirement tags. For example, Figure 4This is an illustration of an example of a DNS query 400 provided in one embodiment of this disclosure. The DNS query 400 includes a modified domain name “qs--(QoSparameters)_ldap._tcp.example.com”, which includes the QoS prefix qs--412 followed by QoS parameters 414 specifying one or more QoS requirements. QoS parameters 414 can be specified in one or more fields. The _ldap prefix 416 and the _tcp prefix 418 specify a query for information about a connection via Transmission Control Protocol (TCP) to a Lightweight Directory Access Protocol (LDAP) service associated with the domain name “example.com” 420 and having specific QoS requirements specified by QoS parameters 414. The modified domain name may also include other prefixes, or the order of the prefixes may differ; for example, the service label and protocol label may appear first, followed by the QoS requirement label, and finally the rest of the domain name. Because QoS requirements may appear in multiple labels within a domain name, such QoS requirement labels may appear before and after the service label and / or protocol label. For example, in another alternative embodiment, a DNS name is used in a DNS query for an SRV RR or some other type of RR, wherein the QoS requirements are encoded in one or more tags of that name.

[0063] In one embodiment, a DNS server maintains a binding between a name and several semantic addresses. The DNS server returns a semantic address that represents the QoS guarantee provided. The semantic address includes not only the destination address but also additional information about packet processing. Each semantic address represents some QoS requirements that can be met. Semantic addresses can be dynamically calculated or statically configured. Based on the query, the DNS server returns a set of semantic addresses that can satisfy the application's QoS requirements; if the requirements cannot be met, an error may be returned.

[0064] Once the client device, particularly the application running on it, receives a response, it can simply use the address to forward packets. The embodiments disclosed in this disclosure may be effective for applications unfamiliar with this QoS request scheme. In some embodiments, the application can decode packet tagging or processing information from the returned address and use this information to obtain the desired QoS. The semantic address can be cached over the lifetime of the flow. In an alternative embodiment, the DNS response TTL can indicate the period for which the semantic address is to provide QoS guarantees; the application can query the DNS again at or shortly before the end of that period to refresh the semantic address or obtain a new address valid for future intervals. When the edge router receives a packet, it can perform QoS processing on the packet based on the semantic address. In another embodiment, the application can use the QoS request to query the RR type, returning additional information about how to obtain services that meet those requirements.

[0065] Figure 5 This is a flowchart of a method 500 for requesting QoS implemented by a client device, provided in an embodiment of this disclosure. In step 502, the client device encodes the QoS request in a DNS query. In one embodiment, the DNS query includes a modified domain name. The modified domain name includes the QoS request encoded using the domain name. The QoS request may include one or more QoS requirements. In one embodiment, the one or more QoS requirements may include, but are not limited to, latency limits, bandwidth requirements, packet loss limits, jitter limits, cost limits, or security requirements. In one embodiment, the client device prepends the QoS request in the domain name. In one embodiment, the client device prepends the QoS request in the domain name using a hexadecimal format or base32 format indicating a set of QoS requirements. Other types of formats may also be applicable to embodiments of this disclosure. Figure 3 The encoding of a specific QoS requirement may include a first field indicating the specific QoS requirement, a second field indicating the data size encoding of the specific QoS requirement in the QoS request, and a third field encoding a value for the specific QoS requirement based on the data size.

[0066] In some embodiments, a QoS request may include one or more QoS prefixes to indicate that the modified domain name includes a specific type of requirement. For example, the prefix "qs--" or "_qs" or other specified prefixes may be added before one or more QoS requirements in the modified domain name to indicate that the modified domain name includes QoS requirements. In some embodiments, the client device may also encode protocol requirements and / or type of service requirements 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 indicating a set of predefined QoS requirements. In a non-limiting example, there could be three predetermined QoS profiles: a default, a bandwidth-limited very low latency profile, and a latency-relaxed very high bandwidth profile. Each QoS profile corresponds to a set of predefined QoS requirements, and there is no hierarchy among these profiles. Different types of applications may prefer different QoS requirements.

[0068] In step 504, the client device sends a DNS query to the DNS server. For example... Figure 1 The DNS query may be received by a DNS recursive resolver (e.g., DNS recursive resolver 104), which attempts to locate a DNS authoritative name server capable of satisfying the DNS query. In step 506, the client device receives a response from the DNS server to the sent DNS query. In one embodiment, the response includes at least one DNS RR, which includes information satisfying the QoS request in the query. In one embodiment, the information includes a semantic address. A semantic address is an address that includes additional semantics (e.g., service or QoS information) encoded in the address along with the destination ID.

[0069] In one embodiment, the semantic address is an IP address such as an IPv4 address or an IPv6 address. For example, the semantic address could be a structured IPv6 address that includes additional information. For instance, in one embodiment, the semantic address could be a 128-bit IPv6 address, i.e., a 120-bit host address + an 8-bit QoS indicator, where each encoding represents a specific QoS guarantee. In another embodiment, the semantic address could be a 128-bit IPv6 address that includes optional fields for protocol parameters to achieve the desired QoS guarantees. Possible fields may include Network Slice Selection Assistance Information (NSSAI) (20 bits consisting of an 8-bit slice type and a 12-bit slice distinguisher), Differentiated Services Code Point (DSCP) (as described in IETF RFC 2474, "Definition of the Differentiated Services Field (DS Field) in IPv4 and IPv6 Headers," published by K. Nichos et al., December 1998), IEEE 802 Priority Code Point (PCP) (3 bits), and / or Drop Eligibility Indicator (DEI) (1 bit, as described on pages 1–214 of IEEE Std 802.1Q-1998, March 8, 1999, "IEEE Standards for Local Area Networks and Metropolitan Area Networks: Virtual Bridged Local Area Networks"). (Metropolitan Area Networks: Virtual Bridged Local Area Networks), etc. When the above addresses are used as IPv6 addresses, the portion of the IPv6 address with optional QoS protocol parameters can be set to a fixed value, for example, 0. In one embodiment, a new RR type can be defined that includes the IP address and additional fields for protocol parameters to achieve the desired QoS guarantees, as listed above.

[0070] In step 508, the client device connects to the service using 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, thereby connecting to the service using information from at least one DNS RR. In one embodiment, the client device, or (particularly) an application running on the client device, uses semantic addresses to send data packets. One advantage of the embodiments disclosed in this disclosure is that it may not be necessary to modify the application's API (i.e., sockets). The application does not need to know that it is using semantic addresses. Furthermore, DNS queries that include the modified domain name can be used... Figure 1 This is achieved through the standard DNS process described in [the document]. Only the DNS authoritative name server needs to resolve the modified domain name to identify one or more requested QoS requirements.

[0071] Figure 6 This is a flowchart of a method 600 for satisfying a QoS request according to one embodiment of this disclosure. Method 600 may be performed by a DNS authoritative server (e.g., but not limited to...). Figure 1 The DNS authoritative name server (110) is implemented in step 602. In step 602, the DNS authoritative server receives a modified DNS request, which includes a QoS request originating from the client device. In one embodiment, the QoS request is encoded in a modified domain name within the modified DNS request. For example, the modified domain name includes a QoS request prepended to the domain name. The DNS authoritative server decodes the QoS request to determine parameters of one or more requested QoS requirements. In one embodiment, the QoS request may indicate a set of predefined QoS requirements. In step 604, the DNS authoritative server determines one or more services and / or communication methods that satisfy the QoS request. A service can be a specific server or a specific path to that server. For example, a server may have two addresses, so requests to that server will follow different paths. Depending on the address used, the QoS may differ and depend on the path used, regardless of the specific server. In some cases, the QoS may depend on both the specific server and the path to that server. Therefore, the term "service" includes both the path to the server and the server itself. In step 606, the DNS authoritative server sends at least one DNS RR corresponding to one or more services that satisfy the QoS request to the client device. In one embodiment, at least one DNS RR includes one or more IP addresses.

[0072] Figure 7This is a schematic diagram of an apparatus 700 for implementing one or more methods disclosed herein, provided in one embodiment of this disclosure. For example, apparatus 700 may represent a transmitting device 100, a receiving device 102, a client device, and / or a server described herein. Apparatus 700 includes an ingress port 710 and a receiving unit (Rx) 720 for receiving messages, a processor, logic unit, or central processing unit (CPU) 730 for processing messages, a transmitting unit (Tx) 720 and an egress port 740 for transmitting messages, and a memory 750.

[0073] Processor 730 is implemented by any suitable combination of hardware, middleware, and firmware. Processor 730 can be implemented as one or more CPU chips, one or more cores (e.g., a multi-core processor), one or more field-programmable gate arrays (FPGAs), one or more application-specific integrated circuits (ASICs), or one or more digital signal processors (DSPs). Processor 730 communicates with input port 710, receiving unit 720, transmitting unit 720, output port 740, and memory 750.

[0074] Memory 750 includes one or more disks, one or more tape drives, or one or more solid-state drives, and can be used as an overflow data storage device to store programs when a program is selected for execution, or to store instructions and data read during program execution. 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, memory 750 includes a DNS QoS semantic addressing module 760. The DNS QoS semantic addressing module 760 includes executable instructions and data configurations that, when executed by processor 730, implement the disclosed embodiments described herein.

[0075] While this disclosure provides several embodiments, it should be understood that the disclosed systems and methods can also be embodied in many other specific forms without departing from the spirit or scope of this disclosure. Those skilled in the art will understand how any or all of the above techniques can be combined in various arrangements and combinations.

[0076] The examples presented here are intended to be illustrative rather than limiting, and are not limited to the details given herein. For instance, various elements or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0077] These disclosed embodiments improve network and application technologies by including one or more QoS requirements in DNS queries. QoS requirements can be encoded in DNS names, which are queried in the DNS query, so that these requirements can be automatically forwarded to the authoritative server without interference from any intermediate recursive DNS servers. Embodiments disclosed in this disclosure support application-aware networking without altering the underlying application programming interface (API) and DNS protocol. Specifically, embodiments disclosed in this disclosure enable applications on client devices to express QoS preferences or requirements through DNS queries by extending DNS queries to include QoS requirements. In one embodiment, the DNS returns a response including one or more semantic addresses that implicitly represent the QoS guarantees it provides. Using embodiments disclosed in this disclosure does not require modification of the application API (i.e., sockets) and can be implemented using standard DNS messages and protocols. In one embodiment, the RR query on the authoritative server is modified unless all the QoS labels to be queried are pre-configured on the authoritative server. Embodiments disclosed in this disclosure are applicable to IPv6 / SRv6 and allow SRv6 to be extended to hosts. In one embodiment, when using IPv6, the destination can have multiple IPv6 addresses (e.g., a generic IPv6 prefix and multiple suffixes, each suffix encoding some specific QoS requirements). A specific list of SRv6 segments (i.e., paths) can naturally reflect some QoS guarantees. The embodiments disclosed in this disclosure are applicable to all network environments, such as, but not limited to, data center networks, enterprise networks, and carrier backbones.

[0078] Furthermore, without departing from the scope of this disclosure, the technologies, systems, subsystems, and methods described and illustrated as discrete or separate in the various embodiments may be combined or integrated with other systems, modules, technologies, or methods. Other items shown or described as coupled, directly coupled, or communicating with each other may be indirectly coupled or communicated electrically, mechanically, or otherwise through some interface, device, or intermediate component. Other examples of variations, substitutions, and modifications can be determined by those skilled in the art and may be exemplified without departing from the spirit and scope of the disclosure herein.

Claims

1. A method for requesting Quality of Service (QoS) implemented by a client device, characterized in that, The method includes: The QoS request is encoded in a Domain Name System (DNS) query; the DNS query includes a modified domain name, the modified domain name includes the QoS request encoded using the domain name; the modified domain name includes the QoS request pre-defined in the domain name; Send the DNS query to the DNS server; Receive a response from the DNS server to the sent DNS query, wherein the response includes at least one DNS resource record (RR), and the at least one DNS RR includes information satisfying the QoS request in the DNS query; and Connect to the service using the information in at least one of the DNS RRs; The method further includes: prepending the QoS request in the domain name in a format indicating a set of QoS requirements, wherein the format is hexadecimal or base32; or prepending the QoS request in the domain name as a predetermined QoS profile indicating a set of predefined QoS requirements.

2. The method according to claim 1, characterized in that, The information includes Internet Protocol (IP) addresses.

3. The method according to claim 1, characterized in that, The QoS request includes a set of QoS requirements, wherein a specific QoS requirement in the set of QoS requirements includes a first field indicating the specific QoS requirement in the QoS request, a second field indicating the data size encoding of the specific QoS requirement in the QoS request, and a third field encoding the data size to specify a value for the specific QoS requirement.

4. The method according to any one of claims 1 to 3, characterized in that, The set of QoS requirements includes latency limitations.

5. The method according to any one of claims 1 to 4, characterized in that, The set of QoS requirements includes bandwidth requirements.

6. The method according to any one of claims 1 to 5, characterized in that, The set of QoS requirements includes packet loss limits.

7. The method according to any one of claims 1 to 6, characterized in that, The set of QoS requirements includes jitter limitations.

8. The method according to any one of claims 1 to 7, characterized in that, The set of QoS requirements includes cost constraints.

9. The method according to any one of claims 1 to 8, characterized in that, The set of QoS requirements includes security requirements.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes encoding the protocol requirements as part of the DNS query.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes encoding the service type requirement as part of the DNS query.

12. The method according to any one of claims 1 to 11, characterized in that, The QoS request includes one or more QoS prefixes.

13. An apparatus for requesting Quality of Service (QoS), characterized in that, The device includes: Memory, used to store instructions; and One or more processors are coupled to the memory and configured to execute the instructions, wherein, when executed, the instructions cause the device to perform the following operations: The Quality of Service (QoS) request is encoded in a Domain Name System (DNS) query; the DNS query includes a modified domain name, the modified domain name includes the QoS request encoded using the domain name; the modified domain name includes the QoS request pre-defined in the domain name; Send the DNS query to the DNS server; Receive a response from the DNS server to the sent DNS query, wherein the response includes at least one DNS resource record (RR), and the at least one DNS RR includes information satisfying the QoS request in the query; and Connect to the service using the information in at least one of the DNS RRs; When executed by the one or more processors, the instruction further causes the device to prepend the QoS request in the domain name in a format indicating a set of QoS requirements, wherein the format is hexadecimal or base32; or, when executed by the processor, the instruction further causes the device to prepend the QoS request in the domain name as a predetermined QoS profile indicating a set of predefined QoS requirements.

14. The apparatus according to claim 13, characterized in that, The information includes Internet Protocol (IP) addresses.

15. The apparatus according to claim 13, characterized in that, The QoS request includes a set of QoS requirements, wherein a specific QoS requirement in the set of QoS requirements includes a first field indicating the specific QoS requirement in the QoS request, a second field indicating the data size encoding of the specific QoS requirement in the QoS request, and a third field encoding the data size to specify a value for the specific QoS requirement.

16. The apparatus according to any one of claims 13 to 15, characterized in that, The set of QoS requirements includes latency limitations.

17. The apparatus according to any one of claims 13 to 15, characterized in that, The set of QoS requirements includes bandwidth requirements.

18. The apparatus according to any one of claims 13 to 15, characterized in that, The set of QoS requirements includes packet loss limits.

19. The apparatus according to any one of claims 13 to 15, characterized in that, The set of QoS requirements includes jitter limitations.

20. The apparatus according to any one of claims 13 to 19, characterized in that, When executed by the processor, the instructions also cause the device to encode the protocol requirements as part of the DNS query.

21. The apparatus according to any one of claims 13 to 20, characterized in that, When executed by the processor, the instructions also cause the device to encode the service type requirement as part of the DNS query.

22. The apparatus according to any one of claims 13 to 21, characterized in that, The QoS request includes one or more QoS prefixes.

23. A method for satisfying Quality of Service (QoS) requests, implemented by a Domain Name System (DNS) authoritative server, wherein the server interacts with a client device as described in any one of claims 1 to 12, characterized in that... The method includes: The client device receives a modified DNS request including a QoS request; the QoS request is encoded in a modified domain name in the modified DNS request; the modified domain name includes the QoS request prepended to the domain name; the QoS request is in hexadecimal or base32 format indicating a set of QoS requirements, or the QoS request indicates a set of predefined QoS requirements. Determine one or more services that satisfy the QoS request; and Send at least one DNS resource record (RR) to the client device corresponding to one or more services that satisfy the QoS request.

24. The method according to claim 23, characterized in that, The at least one DNS RR includes an IP address.

25. The method according to claim 23, characterized in that, The QoS request includes one or more QoS requirements, each QoS requirement including a first field indicating a specific QoS requirement, a second field indicating the data size encoding of the specific QoS requirement in the QoS request, and a third field encoding a value for the specific QoS requirement according to the data size.

26. The method according to any one of claims 23 to 25, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes latency limitations.

27. The method according to any one of claims 23 to 26, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes bandwidth requirements.

28. The method according to any one of claims 23 to 27, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes packet loss limits.

29. The method according to any one of claims 23 to 28, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes cost constraints.

30. The method according to any one of claims 23 to 29, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes security requirements.

31. An apparatus for satisfying a Quality of Service (QoS) request, the apparatus interacting with an apparatus for requesting QoS as described in any one of claims 13 to 22, characterized in that, The device includes: Memory, used to store instructions; and A processor, coupled to the memory and configured to execute the instructions, wherein, when executed, the instructions cause the device to perform the following operations: The client device receives a modified DNS request including a QoS request; the QoS request is encoded in a modified domain name in the modified DNS request; the modified domain name includes the QoS request prepended in the domain name; the QoS request is in hexadecimal or base32 format indicating a set of QoS requirements, or the QoS request indicates a set of predefined QoS requirements. Determine one or more services that satisfy the QoS request; and Send at least one DNS resource record (RR) to the client device corresponding to one or more services that satisfy the QoS request.

32. The apparatus according to claim 31, characterized in that, The at least one DNS RR includes an IP address.

33. The apparatus according to claim 31, characterized in that, The QoS request includes one or more QoS requirements, each QoS requirement including a first field indicating a specific QoS requirement, a second field indicating the data size encoding of the specific QoS requirement in the QoS request, and a third field encoding a value for the specific QoS requirement according to the data size.

34. The apparatus according to any one of claims 31 to 33, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes latency limitations.

35. The apparatus according to any one of claims 31 to 34, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes bandwidth requirements.

36. The apparatus according to any one of claims 31 to 35, characterized in that, The set of QoS requirements or a set of predefined QoS requirements includes packet loss limits.

Images