DNS Extensions to Energy Efficiency as
Service(EEAS)China TelecomZhongshan Avenue WestGuangzhouGuangdong510630CN8613316097206zhuhh11@chinatelecom.cnChina TelecomNorth Chaoyangmen StreetBeijingBeijing100010CN8618901168068liusy@chinatelecom.cn
Internet
DNSOP Working GroupDNSThis document describes a new Mechanism and DNS resource record (RR)
type to carry information about energy-related characteristics for
end-to-end internet access. The "EE" ("Energy Efficiency") record allows
the network to provide different levels of energy-saving service. By
providing more energy information to the client before it attempts to
establish a connection, these records offer potential benefits to
enhancements on energy as service criteria.Energy savings and green communication are crucial due to the effects
of climate change and the global energy shortage. Today, users who are
more aware and sensitive toward environment may prefer reducing their
carbon footprint by choosing more renewable energy sources than
non-renewable sources for network services, even if it means compromised
service performance.With intended usage of renewable energy sources in the network, the
usage efficiency of energy consumption may be improved when resolving
domain-names by taking availability of renewable energy sources into
consideration. Overall reduction in energy usage and prioritizing usage
of renewable energy sources over non-renewable energy sources need a
coordinated solution at both user and application levels from the
perspective of end-to-end. DNS can play an important role in the whole
process. For example, authoritative servers can implement energy-aware
load balancing and scheduling functions based on energy-related
strategies. However, the exposure of the users' consent, awareness, and
energy-related information is necessary in this context as it may result
in dynamic service adjustment at flow level based on energy. Thus,
energy-aware Domain Name resolution with the user's consent and
awareness is the requirement for energy saving and green energy
usage.To support Energy Efficiency as a service in the DNS, this document
defines the following extensions:The "EE" ("Energy Efficiency") record type is defined that can be
applied directly and efficiently to a wide range of services. The
information helps make connectivity decisions with low carbon
emissions by using more renewable energy source-operated
servers.A mechanism is described how the "EE resolution" is performed by
the client and DNS servers. If a client learns more about the origin
energy before connecting (such as energy consumption, energy supply
mix, power usage effectiveness, and availability conditions), it may
be able to choose a greener endpoint without degrading the service
experience.The "EE" ("Energy Efficiency") record's compatibility with other
resource records is described.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 when, and only
when, they appear in all capitals, as shown here.The EE DNS RR type is used to choose an alternative endpoint for
the energy service by clients.EE RRs have the same top-level format as other RRsWhere:NAME: A <domain-name> which specifies a host.TYPE: A new EE RR TYPE code with two octets is registered by
IANA.CLASS: Two octets contain one of the EE RR CLASS code.TTL: A 32-bit signed integer that specifies the time inteval of
the EE record cached before the source of the information should
again be consulted.RDLENGTH: An unsigned 16-bit integer between 0 and 65535 that
specifies the length in octets of the RDATA field.RDATA: A variable-length string of octets that describes the
energy-related information.The presentation format <RDATA> of the record has the form:Where:PRIORITY: An unsigned 16-bit integer that specifies the
priority of this record.ENAME: A <domain-name> which specifies a host of an
alternative endpoint.EEPARAMS: A <character-string> which specifies the energy
parameters of the alternative endpoint.RRsets are explicitly unordered collections, so the PRIORITY
field imposes an ordering on EE RRs. A smaller PRIORITY indicates
that the domain owner prefers the usage of this record to other RRs
with a larger PRIORITY value. A value of 0 indicates AliasMode.
Other values indicate Servicemode.When receiving an RRset containing multiple EE records with the
same PRIORITY value, clients SHOULD apply a random shuffle within a
priority level to select the records to ensure uniform load
balancing.ENAME May be the domain name of either the alias target (for
AliasMode) or the alternative endpoint (for ServiceMode).In AliasMode, the EE record aliases a service to an ENAME. EE
RRsets SHOULD only have a single RR in AliasMode. If multiple
AliasMode RRs are present, either clients or recursive resolvers
SHOULD pick one at random.In ServiceMode, the ENAME and EEPARAMS within each RR associate
an alternative endpoint for the service with its connection
parameters.EEPARAMS is a whitespace-separated list with each EEPARAM
consisting of an EeParamKey=EeParamValue pair. EeParamKey names are
presented by lowercase alphanumeric strings from the ranges "a"-"z"
and "0"-"9". Each EeParamKey SHALL appear at most once in the
EEPARAMS. EeParamKeys SHOULD be registered by IANA. EEPARAMS in
presentation format MAY appear in any order, but keys MUST NOT be
repeated.The EeParamValue is a character string. If the optional "=" and
EeParamValue are omitted, the value is interpreted as empty.A few initial EeParamKeys are defined here.The "et" EeParamKey indicates the type of energy. The
presentation value SHALL be a comma-separated list of one or more
et-ids.The "eei" EeParamKey indicates the Energy Efficiency Index of
alternative endpoints. The index of Energy Efficiency is defined
into five levels from 1 to 5. The presentation value SHALL be 4 bits
in length.The "pue" EeParamKey indicates the power usage effectiveness of
the alternative data centers. The presentation value SHALL be a
2-octet length.The "v4addr" EeParamKey conveys IPv4 addresses used to reach the
endpoint to minimize additional connection latency by clients.The "v6addr" EeParamKey conveys IPv6 addresses used to reach the
endpoint to minimize additional connection latency by clients.If ENAME has the value "." (represented in the wire format as a
zero-length label), special rules apply.For AliasMode EE RRs, an ENAME of "." indicates that the service is
not available or does not exist. This indication is advisory: clients
encountering this indication MAY ignore it and attempt to connect
without EE.For ServiceMode EE RRs, if ENAME has the value ".", then the owner
name of this record MUST be used as the effective ENAME. If the record
has a wildcard owner name in the zone file, the recipient SHALL use
the response's synthesized owner name as the effective ENAME."EE resolution" is the process of enumerating and ordering the
available endpoints for a service, as performed by the client. EE
resolution is as follows:Carry a domain name as $QNAME for query in the Question
section.Issue an EE query for $QNAME.If an AliasMode EE record is returned, set $QNAME to its ENAME
and loop back to Step 2, subject to chain length limits and loop
detection heuristics.If one or more ServiceMode records are returned, these represent
the alternative endpoints. Sort the records by ascending
PRIORITY.Otherwise, EE resolution has failed, and the list of available
endpoints is empty.This procedure does not rely on any recursive or authoritative
DNS server to comply with this specification or have any awareness of
EE.Clients MUST consider an RR malformed if:The end of the RDATA occurs within an EEPARAM.EeParamKeys are not in strictly increasing numeric order.The EeParamValue for an EeParamKey does not have the expected
format.Note that the second condition implies that there are no
duplicate EeParamKeys.If any RRs are malformed, the client MUST reject the entire RRset and
fall back to non-EE connection establishment.When replying to an EE query, authoritative DNS servers SHOULD
return A, AAAA, and EE records in the Additional section for any ENAME
that is in the zone. If the zone is signed, the server SHOULD also
include DNSSEC records in the Additional section whether the existence
of these records or not.Whether the recursive resolver is aware of EE or not, the normal
response construction process used for unknown RR types generates the Answer section of the response. If
recursive resolvers are aware of EE, they SHOULD help the client
execute the procedure in Section 4 with minimum overall latency by
incorporating additional valid information into the Additional section
of the response as follows:Incorporate the results of EE resolution. If the recursive
resolver's local chain length limit (which may be different from
the client's limit) has been reached, terminate.If any of the resolved EE record is in AliasMode, choose one of
them at random, and resolve EE, A, and AAAA records for its
ENAME.If any EE record is resolved, go to Step 1.Otherwise, incorporate the results of A and AAAA
resolution, and terminate.All the resolved EE records are in ServiceMode. Resolve A and
AAAA queries for each ENAME (or for the owner name if ENAME is
"."), incorporate all the results, and terminate.In this procedure, "resolve" means processing a query for
that set as the resolver's ordinary recursive resolution procedure.
This includes following any alias that the resolver would ordinarily
follow (e.g., CNAME). Errors or anomalies inobtaining additional
records MAY cause this process to terminate, but they MUST NOT cause
the resolver to send a response about failure.The EE RR type SHOULD be registered on the "Domain Name System
(DNS) Parameters" page with a new code by IANA.The "Energy Efficiency Parameter Keys (EeParamKeys)" SHOULD be
registered in the "Domain Name System (DNS) Parameters" category of a
new page entitled "DNS Energy Efficiency (EE)" by IANA. This registry
defines the namespace for parameters, including string representations
and numeric EeParamKey values.This document should not affect the security of the Internet.
[CHECK]ReferencesNormative ReferencesInformative ReferencesThanks Aijun Wang for the template and help on this draft.