idnits 2.17.00 (12 Aug 2021) /tmp/idnits39167/draft-song-network-aware-dns-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (21 March 2022) is 54 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-farrel-irtf-introduction-to-semantic-routing-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Song 3 Internet-Draft D. Eastlake 4 Intended status: Informational Futurewei Technologies 5 Expires: 22 September 2022 21 March 2022 7 The Architecture of Network-Aware Domain Name System (DNS) 8 draft-song-network-aware-dns-00 10 Abstract 12 A simple method of enhancing Domain Name System (DNS) with network 13 awareness is discussed. This enables DNS system responses that are 14 dependent on communication service requirements such as QoS or path 15 without changes in the format of DNS protocol messages or application 16 program interfaces (APIs). The different enhancement methods and use 17 cases are discussed. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 22 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 54 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Obtaining Needed Information From the DNS . . . . . . . . . . 6 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 61 7.2. Informative References . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 Different application flows have different requirements on 67 networking, such as bandwidth, delay, jitter, reliability, security, 68 and so on. Many requirements are critical for the quality of service 69 and users are ready for premium services even if extra cost is 70 involved. Meanwhile, today's networks have advanced beyond the best- 71 effort model and are capable of providing per-flow services to meet 72 various application requirements (e.g., QoS) by means of 73 programmability, resource management (e.g., network slicing), traffic 74 engineering, and path regulation (e.g., segment routing and service 75 function chaining). 77 However, a clear gap exists. Applications usually only care about 78 the abstract requirements ("WHAT") instead of the actual measures for 79 networks to meet such requirements ("HOW"). Therefore, not only is 80 there a lack of a direct means for networks to tell applications 81 their capabilities but also it is often improper to do so. Due to 82 the limitation of the commonly available network socket API, it is 83 also difficult for applications to convey their service requirements 84 to networks. Currently one either assumes the requirements can be 85 expressed to network controllers through some out-of-band manner or, 86 in case of IPv6, by resorting to encoding the requirements as options 87 into extension headers (e.g., network tokens 88 [I-D.yiakoumis-network-tokens]). We need a simpler and more 89 extensible way to set up the service contract. 91 We define an architecture to support network awareness through DNS. 92 Requirements to network services can be incorporated into DNS queries 93 from a host (e.g., as specified in 94 [I-D.eastlake-dnsop-expressing-qos-requirements]) and the returned 95 information enables access to services meeting those requirements. 96 For example, by including new semantics representing a service 97 commitment embedded in the returned IP addresses (i.e., semantic 98 addressing [I-D.farrel-irtf-introduction-to-semantic-routing]). 100 The Domain Name System (DNS) is a distributed database that stores 101 data under hierarchical domain names and supports redundant servers, 102 data caching, and security features. The data is formatted into 103 resource records (RRs) whose content type and structure are indicated 104 by the RR Type field. A typical use of DNS is that, by running the 105 DNS protocol, a host gets the IP addresses stored at a domain name 106 from DNS servers through a DNS resolver. Many other types of data 107 besides IP addresses can be stored in and returned by the DNS. 109 In a nutshell, the application's service requirements are embedded 110 into the DNS queries from a host. The DNS replies either provide 111 semantic IP addresses or data that help construct the packet header 112 or headers signaling the special packet handling in networks. The 113 application flow packets will use the existing socket API to send the 114 packet. Network devices, after capturing such packets, would decode 115 the semantics and apply any special packet handling accordingly. 117 This document describes the architecture, requirements, and use cases 118 of the Network-Aware DNS. The details on DNS query encoding and 119 semantic addressing/data in DNS replies will be described in other 120 documents. 122 1.1. Terminology and Acronyms 124 The following terminology and acronyms are used in this document. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119][RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 API - Application Program Interface 134 DNS - Domain Name System 136 RR - Resource Record [RFC8499]. The unit of data stored in the DNS. 138 Semantic Addressing - Encoding extra semantics beyond the 139 destination ID in an address 141 2. Architecture 143 The architecture of the Network Aware DNS is shown in Figure 1. 145 +----------+ +----------+ 146 | | 1.registration | Network | 147 | DNS |<---------------+ Operator | 148 | | | | 149 +------+---+ +----+-----+ 150 ^ | 4. | 2. 151 3.| | r | p 152 q | | e | o 153 u | | p | l 154 e | | l | i 155 r | | y | c 156 y | V V y 157 +--+-------+ +----------+ 158 | | 5.pkt thru | | 6.pkt w/ met 159 | Host +--------------->| Network +-------------> 160 | | socket API | | requirements 161 +----------+ +----------+ 163 Figure 1: Architecture 165 1. The network operator registers the semantic addresses/data 166 associated with a name in authoritative DNS servers in form of 167 RRs. In addition to the location, the semantics represent the 168 commitments for network to meet certain service requirements. 169 The semantic addresses or data can be dynamically computed or 170 statically configured by the network operator. 172 2. Meanwhile, the packet processing policy corresponding to each 173 semantic address/data is configured to the network devices such 174 as routers. How the network meets the service requirements is 175 opaque to host applications. 177 3. A host application, when conducting a DNS query to a name, would 178 also express its service requirement. A host application can 179 also be ignorant of this service requesting scheme; in this 180 case, the normal DNS query is used and the best-effort results 181 are returned. 183 4. If the query with service requirements can be satisfied by some 184 RRs in DNS, the result will be returned to the host; otherwise, 185 a normal DNS response, or either an error or the best effort 186 result, will be returned. 188 5. Once the host application receives the reply, assuming the reply 189 is not an error, it simply uses the address (or assembles the 190 header fields as directed by the semantic data) to forward the 191 packet through a standard socket API. The semantic address or 192 data may be cached at the host for the lifetime of the flow. 193 Alternatively, the DNS response TTL may indicate the period of 194 time for which the semantic address will provide the service 195 assurances, and the application may again query the DNS at or 196 shortly before the end of the time to refresh the semantic 197 address/data or obtain a new address or data that will be 198 effective for a future interval; however, it is not common for 199 TTL information to be returned to an application doing a DNS 200 query. 202 6. The network devices would process the packets based on the 203 configured policies if the packets carries semantic addresses 204 and/or header fields. Using a semantic address/data other than 205 for the best effort service might be subject to extra cost based 206 on some service agreement. 208 We enforce some requirements on the architecture to make it practical 209 for incremental deployment. 211 * We do not introduce new protocols to enable the architecture. 213 * As an infrastructural system and protocol, DNS is hard to change. 214 We will not make any change to DNS architecture and protocol. 215 However, within the framework, we have the freedom to introduce 216 new semantics and new RR types to encode semantic data. 218 * Similarly, it is hard to change the ubiquitous network socket API, 219 so we just rely on it. 221 * We envision the system would be better used in limited domains 222 where the network operator owns not only the networks but also the 223 proper name servers. In some cases, it is also possible to extend 224 the scope into multiple domains if the packet processing to meet 225 the service requirements can be coordinated cross domains. 227 * We expect the semantic address or data is per application or per 228 flow based. So each application or flow may need its own DNS name 229 resolution even for the same service. Most applications can still 230 use the conventional best effort service without noticing any 231 change. 233 In a more dynamic architecture, DNS queries with service requirements 234 can be dynamically sent to the network operator when received by a 235 resolver, allowing network operator to generate on-demand semantic 236 addresses or data for the name server, which will eventually return 237 the information back to the host application. 239 3. Obtaining Needed Information From the DNS 241 A host application can have three methods to obtain information from 242 the DNS to enable the application to meet its service requirements. 243 These methods are as follows: 245 Method 1: It sends a requirement-encoded name to ask for an IP 246 address type RR (e.g., AAAA) and expects the semantics to meet the 247 requirements to be embedded in the returned addresses. The 248 encoding method is described in 249 [I-D.eastlake-dnsop-expressing-qos-requirements]. 251 Method 2: It sends a normal name to ask for a different type of RR 252 and the semantic data in the returned RRs represents the means to 253 meet the service requirements. 255 Method 3: Combining 1 and 2, it sends a requirement-encoded name to 256 ask for a different type of RR, which might be in addition to or 257 lead to (such as the SRV type RR) an IP address type RR, and the 258 semantic data in the RR represents the means to meet the service 259 requirements. 261 This architecture can support multiple use cases using one of the 262 above methods. Below are some examples. 264 E2E SRv6: This use case may use method 2. We can support true end- 265 to-end SRv6 service where a Segment List (SL) is acquired from DNS 266 using the RR Type specified in [I-D.eastlake-dnsop-rrtype-srv6] 267 and an SRH (Segment Routing Header) is directly inserted in the 268 IPv6 packet header. While the SRH determines the packet's 269 forwarding path, different packet handling and QoS treatment can 270 also be applied to the packet along the path. 272 Semantic Addressing: This use case may use method 1. Due to the 273 abundance of IPv6 addresses, each name can be assigned multiple 274 addresses with each representing some special network services. 275 While the network devices are configured or programmed to be able 276 to interpret and process the semantics embedded in addresses, 277 different services can be applied to flows for the same 278 destination. The details are described in a companion draft. 280 Service Header Fields: This use case may use method 3. Some 281 service-defining header fields (e.g., DSCP in IPv4 header and 282 traffic class and flow label in IPv6 header) can be used to 283 indicate QoS or other service requirements. Such semantic data 284 can also be provided by DNS replies in form of RRs. The details 285 are described in a companion draft. 287 Other Semantic Data: This use case may apply the method 2 or 3. 288 Some services may have other means to be encapsulated into a 289 packet (e.g., IPv6 Extension Header). The required information 290 can also be returned by DNS reply as semantic data. 292 4. Security Considerations 294 TBD 296 5. IANA Considerations 298 This document requires no IANA actions. 300 6. Acknowledgments 302 The comments and suggestions of the following are gratefully 303 acknowledged: 305 * TBD 307 7. References 309 7.1. Normative References 311 [I-D.eastlake-dnsop-expressing-qos-requirements] 312 Eastlake, D. and H. Song, "Expressing Quality of Service 313 Requirements (QoS) in Domain Name System (DNS) Queries", 314 Work in Progress, Internet-Draft, draft-eastlake-dnsop- 315 expressing-qos-requirements-00, 7 March 2022, 316 . 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 7.2. Informative References 330 [I-D.eastlake-dnsop-rrtype-srv6] 331 Eastlake, D. and H. Song, "An IPv6 Segment Routing (SRv6) 332 Domain Name System (DNS) Resource Record", Work in 333 Progress, Internet-Draft, draft-eastlake-dnsop-rrtype- 334 srv6-00, 6 March 2022, . 337 [I-D.farrel-irtf-introduction-to-semantic-routing] 338 Farrel, A. and D. King, "An Introduction to Semantic 339 Routing", Work in Progress, Internet-Draft, draft-farrel- 340 irtf-introduction-to-semantic-routing-03, 22 January 2022, 341 . 344 [I-D.yiakoumis-network-tokens] 345 Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network 346 Tokens", Work in Progress, Internet-Draft, draft- 347 yiakoumis-network-tokens-02, 22 December 2020, 348 . 351 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 352 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 353 January 2019, . 355 Authors' Addresses 357 Haoyu Song 358 Futurewei Technologies 359 2220 Central Expressway 360 Santa Clara, CA 95050 361 United States of America 362 Email: haoyu.song@futurewei.com 364 Donald Eastlake 365 Futurewei Technologies 366 2386 Panoramic Circle 367 Apopka, FL 32703 368 United States of America 369 Phone: +1-508-333-2270 370 Email: d3e3e3@gmail.com