Internet DRAFT - draft-song-apn-dns-application-aware-networking
draft-song-apn-dns-application-aware-networking
Network Working Group H. Song
Internet-Draft D. Eastlake
Intended status: Informational Futurewei Technologies
Expires: 8 September 2022 7 March 2022
The Architecture of Domain Name System (DNS) Based Application Aware
Networking
draft-song-apn-dns-application-aware-networking-00
Abstract
A simple method of implementing Application Aware Networking using
the Domain Name System (DNS) is discussed. This enables DNS system
responses that are dependent on communication service quality
requirements without changes in the format of DNS protocol messages
or application program interfaces (APIs). Such responses can provide
lightweight support to application aware networking.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 September 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Song & Eastlake Expires 8 September 2022 [Page 1]
Internet-Draft DNS-based Application Aware Networking March 2022
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Obtaining Needed Information From the DNS . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Different application flows have different requirements on
networking, such as bandwidth, delay, jitter, reliability, security,
and so on. Many requirements are critical for the quality of service
and users are ready for premium services even if extra cost is
involved. Meanwhile, today's networks have advanced beyond the best-
effort model and are capable of providing per-flow services to meet
various application requirements (e.g., QoS) by means of
programmability, resource management (e.g., network slicing), traffic
engineering, and path regulation (e.g., segment routing and service
function chaining).
Application-Aware Networking (APN)
[I-D.li-apn-problem-statement-usecases] is becoming not only a
possibility but also a necessity. However, a clear gap exists.
Applications usually only care about the abstract requirements
("WHAT") instead of the actual measures for networks to meet such
requirements ("HOW"). Therefore, not only is there a lack of a
direct means for networks to tell applications their capabilities but
also it is often improper to do so. Due to the limitation of the
commonly available network socket API, it is also difficult for
applications to convey their service requirements to networks.
Currently application-aware networking schemes either assume the
requirements are expressed to network controllers through some out-
Song & Eastlake Expires 8 September 2022 [Page 2]
Internet-Draft DNS-based Application Aware Networking March 2022
of-band manner or, in case of IPv6, by resort to encoding the
requirements as options into extension headers (e.g., network tokens
[I-D.yiakoumis-network-tokens]). We need a simpler and more
extensible way to set up the service contract.
We define an architecture to support application aware networking
through DNS. Requirements are incorporated into DNS queries from a
host as specified in [I-D.eastlake-dnsop-expressing-qos-requirements]
and the returned information enables access to services meeting those
requirements. For example, by including new semantics representing a
service commitment embedded in the returned IP addresses (i.e.,
semantic addressing
[I-D.farrel-irtf-introduction-to-semantic-routing]).
The Domain Name System (DNS) is a distributed database that stores
data under hierarchical domain names and supports redundant servers,
data caching, and security features. The data is formatted into
resource records (RRs) whose content type and structure are indicated
by the RR Type field. A typical use of DNS is that, by running the
DNS protocol, a host gets the IP addresses stored at a domain name
from DNS servers through a DNS resolver. Many other types of data
besides IP addresses can be stored in and returned by the DNS.
In a nutshell, the application's service requirements are embedded
into the DNS queries from a host. The DNS replies either provide
semantic IP addresses or data that help construct the packet header
or headers signaling the special packet handling in networks. The
application flow packets will use the existing socket API to send the
packet. Network devices, after capturing such packets, would decode
the semantics and apply any special packet handling accordingly.
This document describes the architecture, requirements, and use cases
of the DNS-based application aware networking. The semantic
addressing and data in DNS replies will be described in other
documents.
1.1. Terminology and Acronyms
The following terminology and acronyms are used in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
API - Application Program Interface
Song & Eastlake Expires 8 September 2022 [Page 3]
Internet-Draft DNS-based Application Aware Networking March 2022
DNS - Domain Name System
RR - Resource Record [RFC8499]. The unit of data stored in the DNS.
Semantic Addressing - Encoding extra semantics beyond the
destination ID in an address
2. Architecture
The architecture of the DNS-based application aware networking is
shown in Figure 1.
+----------+ +----------+
| | 1.registration | Network |
| DNS |<---------------+ Operator |
| | | |
+------+---+ +----+-----+
^ | 4. | 2.
3.| | r | p
q | | e | o
u | | p | l
e | | l | i
r | | y | c
y | V V y
+--+-------+ +----------+
| | 5.pkt thru | | 6.pkt w/ met
| Host +--------------->| Network +------------->
| | socket API | | requirements
+----------+ +----------+
Figure 1: Architecture
1. The network operator registers the semantic addresses/data
associated with a name in authoritative DNS servers in form of
RRs. In addition to the location, the semantics represent the
commitments for network to meet certain service requirements.
The semantic addresses or data can be dynamically computed or
statically configured by the network operator.
2. Meanwhile, the packet processing policy corresponding to each
semantic address/data is configured to the network devices such
as routers. How the network meets the service requirements is
opaque to host applications.
Song & Eastlake Expires 8 September 2022 [Page 4]
Internet-Draft DNS-based Application Aware Networking March 2022
3. A host application, when conducting a DNS query to a name, would
also express its service requirement. A host application can
also be ignorant of this service requesting scheme; in this
case, the normal DNS query is used and the best-effort results
are returned.
4. If the query with service requirements can be satisfied by some
RRs in DNS, the result will be returned to the host; otherwise,
a normal DNS response, or either an error or the best effort
result, will be returned.
5. Once the host application receives the reply, assuming the reply
is not an error, it simply uses the address (or assembles the
header fields as directed by the semantic data) to forward the
packet through a standard socket API. The semantic address or
data may be cached at the host for the lifetime of the flow.
Alternatively, the DNS response TTL may indicate the period of
time for which the semantic address will provide the service
assurances, and the application may again query the DNS at or
shortly before the end of the time to refresh the semantic
address/data or obtain a new address or data that will be
effective for a future interval; however, it is not common for
TTL information to be returned to an application doing a DNS
query.
6. The network devices would process the packets based on the
configured policies if the packets carries semantic addresses
and/or header fields. Using a semantic address/data other than
for the best effort service might be subject to extra cost based
on some service agreement.
We enforce some requirements on the architecture to make it practical
for incremental deployment.
* We do not introduce new protocols to enable the architecture.
* As an infrastructural system and protocol, DNS is hard to change.
We will not make any change to DNS architecture and protocol.
However, within the framework, we have the freedom to introduce
new semantics and new RR types to encode semantic data.
* Similarly, it is hard to change the ubiquitous network socket API,
so we just rely on it.
Song & Eastlake Expires 8 September 2022 [Page 5]
Internet-Draft DNS-based Application Aware Networking March 2022
* We envision the system would be better used in limited domains
where the network operator owns not only the networks but also the
proper name servers. In some cases, it is also possible to extend
the scope into multiple domains if the packet processing to meet
the service requirements can be coordinated cross domains.
* We expect the semantic address or data is per application or per
flow based. So each application or flow may need its own DNS name
resolution even for the same service. Most applications can still
use the conventional best effort service without noticing any
change.
In a more dynamic architecture, DNS queries with service requirements
can be dynamically sent to the network operator when received by a
resolver, allowing network operator to generate on-demand semantic
addresses or data for the name server, which will eventually return
the information back to the host application.
3. Obtaining Needed Information From the DNS
A host application can have three methods to obtain information from
the DNS to enable the application to meet its service requirements.
These methods are as follows:
Method 1: It sends a requirement-encoded name to ask for an IP
address type RR (e.g., AAAA) and expects the semantics to meet the
requirements to be embedded in the returned addresses.
Method 2: It sends a normal name to ask for a different type of RR
and the semantic data in the returned RRs represents the means to
meet the service requirements.
Method 3: Combining 1 and 2, it sends a requirement-encoded name to
ask for a different type of RR, which might be in addition to or
lead to (such as the SRV type RR) an IP address type RR, and the
semantic data in the RR represents the means to meet the service
requirements.
This architecture can support multiple application aware-networking
use cases using one of the above methods. Below are some examples.
E2E SRv6: This use case may use method 2. We can support true end-
to-end SRv6 service where a Segment List (SL) is acquired from DNS
using the RR Type specified in [I-D.eastlake-dnsop-rrtype-srv6]
and an SRH (Segment Routing Header) is directly inserted in the
IPv6 packet header. While the SRH determines the packet's
forwarding path, different packet handling and QoS treatment can
also be applied to the packet along the path.
Song & Eastlake Expires 8 September 2022 [Page 6]
Internet-Draft DNS-based Application Aware Networking March 2022
Semantic Addressing: This use case may use method 1. Due to the
abundance of IPv6 addresses, each name can be assigned multiple
addresses with each representing some special network services.
While the network devices are configured or programmed to be able
to interpret and process the semantics embedded in addresses,
different services can be applied to flows for the same
destination. The details are described in a companion draft.
Service Header Fields: This use case may use method 3. Some
service-defining header fields (e.g., DSCP in IPv4 header and
traffic class and flow label in IPv6 header) can be used to
indicate QoS or other service requirements. Such semantic data
can also be provided by DNS replies in form of RRs. The details
are described in a companion draft.
Other Semantic Data: This use case may apply the method 2 or 3.
Some services may have other means to be encapsulated into a
packet (e.g., IPv6 Extension Header). The required information
can also be returned by DNS reply as semantic data.
4. Security Considerations
TBD
5. IANA Considerations
This document requires no IANA actions.
6. Acknowledgments
The comments and suggestions of the following are gratefully
acknowledged:
* TBD
7. References
7.1. Normative References
[I-D.eastlake-dnsop-expressing-qos-requirements]
Eastlake, D. and H. Song, "Expressing Quality of Service
Requirements (QoS) in Domain Name System (DNS) Queries",
Work in Progress, Internet-Draft, draft-eastlake-dnsop-
expressing-qos-requirements-00, 7 March 2022,
<https://www.ietf.org/archive/id/draft-eastlake-dnsop-
expressing-qos-requirements-00.txt>.
Song & Eastlake Expires 8 September 2022 [Page 7]
Internet-Draft DNS-based Application Aware Networking March 2022
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[I-D.eastlake-dnsop-rrtype-srv6]
Eastlake, D. and H. Song, "An IPv6 Segment Routing (SRv6)
Domain Name System (DNS) Resource Record", Work in
Progress, Internet-Draft, draft-eastlake-dnsop-rrtype-
srv6-00, 6 March 2022, <https://www.ietf.org/archive/id/
draft-eastlake-dnsop-rrtype-srv6-00.txt>.
[I-D.farrel-irtf-introduction-to-semantic-routing]
Farrel, A. and D. King, "An Introduction to Semantic
Routing", Work in Progress, Internet-Draft, draft-farrel-
irtf-introduction-to-semantic-routing-03, 22 January 2022,
<https://www.ietf.org/archive/id/draft-farrel-irtf-
introduction-to-semantic-routing-03.txt>.
[I-D.li-apn-problem-statement-usecases]
Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z.,
Mishra, G., Ebisawa, K., Previdi, S., and J. N. Guichard,
"Problem Statement and Use Cases of Application-aware
Networking (APN)", Work in Progress, Internet-Draft,
draft-li-apn-problem-statement-usecases-05, 20 December
2021, <https://www.ietf.org/archive/id/draft-li-apn-
problem-statement-usecases-05.txt>.
[I-D.yiakoumis-network-tokens]
Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network
Tokens", Work in Progress, Internet-Draft, draft-
yiakoumis-network-tokens-02, 22 December 2020,
<https://www.ietf.org/archive/id/draft-yiakoumis-network-
tokens-02.txt>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Authors' Addresses
Song & Eastlake Expires 8 September 2022 [Page 8]
Internet-Draft DNS-based Application Aware Networking March 2022
Haoyu Song
Futurewei Technologies
2220 Central Expressway
Santa Clara, CA 95050
United States of America
Email: haoyu.song@futurewei.com
Donald Eastlake
Futurewei Technologies
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Song & Eastlake Expires 8 September 2022 [Page 9]
