draft-eckert-ietf-and-energy-overview-00.xml

<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 3.1.2) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>

<?rfc comments="yes"?>

<rfc ipr="trust200902" docName="draft-eckert-ietf-and-energy-overview-00" category="info" submissionType="independent" tocDepth="5" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="energy-overview">IETF and Energy - an overview</title>

    <author initials="T." surname="Eckert" fullname="Toerless Eckert">
      <organization>Futurewei Technologies USA</organization>
      <address>
        <postal>
          <street>2220 Central Expressway</street>
          <city>Santa Clara</city>
          <code>CA 95050</code>
          <country>USA</country>
        </postal>
        <email>tte@cs.fau.de</email>
      </address>
    </author>

    <date year="2022" month="July" day="09"/>

    
    
    

    <abstract>


<t>This memo attempts to provide an overview of work performed by or proposed to the IETF
relates to energy and/or green: Awareness, management, control or reduction of consumption of
energy, and sustainability as it related to the IETF.</t>

<t>This document is written to help those unfamiliar with the work but interested in it,
in the hope to raise interest in energy related activites in the IETF, such as identifyng gaps and 
working on solution opportunities.</t>

<t>In general, this document attempts to summarize existing work. On occasion it elaborates more
details in support of better understanding the energy relationship of specific technologies,
when this background can not be found from existing draft/RFCs.</t>



    </abstract>



  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t>This document summarizes work that has been proposed to or performed by the IETF. This
means that it covers IETF RFC as well as individual submission RFC and IETF or individual
submission drafts that where abandoned. For this document, IETF also includes work
proposed to or performed by the IRTF. All this is loosely referred to as 'IETF work'
in this memo.</t>

<t>There are various aspects how work can relate to energy. This document
does not attempt to propose a taxonomy or ontology, but it is nevertheless structured around
various classifictions. Many technologies discussed will fall into
multiple categories. Each is listed under a category that is specifically significant
for example by being most narrow.</t>

<t>This memo usually refers for the technologies by significant early RFC or draft version,
as opposed to the newest. This is contrary to the common practice in IETF documents to
refer to the newest version. This is done because it allows readers to better understand
the historic timeline in which specific technology was introduced. Especially successful
IETF technologies will have newer RFC that updates such initial work.</t>

</section>
<section anchor="energy-saving"><name>Energy saving</name>

<t>Technologies that simply save energy compared to earlier/other alternatives are the
broadest and most unspecific category. In this memo such energy saving simply refers
to energy savings in some unit of electricity, such as kWh and does not take other
aspects into account. See <xref target="sustainability"/></t>

<section anchor="digitization"><name>Digitization</name>

<t>Digitization describes the transformation of processes from non or less digital with networking 
to more digital with computer-networking. For comparable process results, the digitized option is often,
but not always, less energy consuming. Consider for example energy consumption in the evolution of
messaging starting from postal mail and overs telegrams and various other historic form to 
solutions including e-mail utilizing for example the IETF "Simple Mail Transport Protocol" (SMTP, <xref target="RFC822"/>),
group communications utiziling the IETF "Network News Transport Protocol" (NNTP, <xref target="RFC3977"/>) or the almost
infinite set of communication options built on top of the IETF "HyperText Transport Protocol" (HTTP, 
<xref target="RFC2086"/> and successors) and IETF "HyperText Markup Language" (HTML, <xref target="RFC1866"/> and successors).</t>

<t>Traditionally, digitization had only "incidential", but not "intentional" relationship to 
energy consumption: If it saved energy, this was not only not a target benefit, it was not
even recognized as one, until probably recently.  Instead, the evolution was driven from anything-but-energy benefits,
but instead utility benefits such as improved speed, functionality/flexibility, accessibility, scalability
and reduced cost.</t>

<t>In hindsight though, digitization through IETF technologies and specifically the Internet
will likely have the largest contribution to energy saving amonst all the possible categories, but it
is also the hardest to pinpoint on any specific technology/RFC. Instead, it is often a combination of 
the whole stack of deployed protocols and operational practices that contributes to energy saving through
digitization. It is likely also the biggest overall energy saving impact of all possible categories that
relate IETF work to energy:</t>

<t>The Internet as well as all other TCP/IP networks are likely the biggest energy saving development
of the past few decades if only the energy consumption of equivalent services is compared. On the other hand,
they are also the cause for the biggest new type of new energy consumption because of all the new services
introduced in the past decades with the Internet and the hyper-scaling that the Internet affords them.</t>

</section>
<section anchor="energy-saving-through-scale"><name>Energy saving through scale</name>

<section anchor="an-example-telephony"><name>An example: Telephony</name>

<t>In most cases, energy saving through the use of IETF protocols compared to earlier (digitized or non digitized)
solutions is purely a result of the reduction in the energy cost per bit over the decades in networking.
For example, the energy consumption of digital voice telephony through the IETF "Session Initiation Protocol"
(SIP, <xref target="RFC2543"/> and successors) can easily be assumed to be more energy efficient on a per voice-minute basis than
 prior voice technologies such as analog or digital "Time Division Multiplex" (TDM) telephony solely because of this 
evolution in mostly device as well as physical-layer and link-layer networking technologies.</t>

</section>
<section anchor="the-packet-multiplexing-principle"><name>The packet multiplexing principle</name>

<t>Nevertheless, it is at the heart of the packet multiplexing model employed by the IETF networking protocols
IP (<xref target="RFC791"/>) and IPv6 (<xref target="RFC1883"/> and successors) to successfully support this scaling that brough down
the cost per bit through ever faster links and network nodes, especially for networks larger than building
scale networks. While the IETF protocols have not been the first or over their early decades necessarily the
most widely deployed packet networking protocols, they where the ones who at least during the 1990th started
to break away from other protocols both in scale of deployment, as well as in development of further technologies
to support this scaling.</t>

</section>
<section anchor="end-to-end-transport"><name>End-to-end transport</name>

<t>At the core of scalability, even up to now, is the lightweight per-packet-processing enabled through
end-to-end congestion loss management architecture as emobodied through the IETF "Transport Control Protocol"
(TCP, <xref target="RFC793"/> and successors). This model eliminated more expensive per-hop, per-packet processing, such as
would be required for reliable hop-by-hop forwarding through per-hop ARQ, which was key to scaling routers cost
effectively.</t>

</section>
<section anchor="internet-routing-architecture"><name>Internet routing architecture</name>

<t>The meshed peer-to-peer and transitive routing of the Internet enabled through the IETF "Border Gateway (Routing)
Protocol (BGP, <xref target="RFC4271"/> as well as predecessors) is another key factor to successful scalability, because it
enabled competitive market forces to explore markets quickly. Prior to the Internet, the public often only
had access to highly regulated international networking connections through often per-country monopoly regulated data networks.</t>

</section>
<section anchor="freedom-to-innovate"><name>Freedom to innovate</name>

<t>(non-IP) networks often also did not allow as much "freedom-to-innovate" (as it is often called in the IETF)
for applications running over it. Instead those networks where exploring the coupling of packet transport with
higher layer services to allow the network operator some degree of revenue sharing with the services running
on top of it, resulting not only in higher cost of those services but also preferential and often
exclusionary treatment of network traffic not fitting the perceived highest revenue service options.</t>

</section>
<section anchor="end-to-end-encryption"><name>End-to-end encryption</name>

<t>When the same business practices where applied to IP network, it was one of the key factors leading to
the development of IETF end-to-end encryption though protocols such as "Transport Layer Security" (TLS, <xref target="RFC2246"/>
and its successors). This further strengthened the ability to scale service/applications at minimum additional
cost for the underlying packet transport, arguably driving innvoation into ever faster networking technology
and likely lower cost per bit.</t>

</section>
<section anchor="converged-networks"><name>Converged networks</name>

<t>Another key factor to support scaling where IETF technologies that allowed to multiplex different types of traffic
(such as "Voice, Video and Data") which previously used/required separate networks with typically incompatible networking
technologies.</t>

<t>Eliminating multiple physical networks with separate routing/forwarding nodes and separate links affords significant
energy savings even at the same generation of speed and hence energy/bit simply by avoiding the N-fold
production and operations of equipment and links. Of course, originally the CAPEX and OPEX of multiple,
technology-diverse networks and host-stacks was the core reason for unified networks, and energy saving
is in hindsight just incidental (as for all other cases mentioned here).</t>

<section anchor="intserv-and-detnet"><name>IntServ and DetNet</name>

<t>The first (non-IETF) wider adopted technology promising converged networks was  "Asynchronuous Transfer Mode" (ATM), 
which was designed and deployed at the end of the 1980th to support specifically multiplexing of "Data Voice and Video",
where both Voice and Video (at that time) required loss-free deterministic bounded latency and low-jitter and had
therefore their own Time-Division-Multiplex (TDM) networks, both separate from so-called Data networks using
packet multiplexing. This technology was very expensive on a per-bit basis due to its cell-forwarding nature
though.</t>

<t>At the end of the 1980th, it was proven (TBD: need to find the reference, cedric knows..)
that variable length packet multiplexing in network can also support non-NP-hard calculations for
bounded latency. This lead to the IETF "Integrated Services WG" (INTSERV) to support such guaranteed
throughput and bounded latency traffic via <xref target="RFC2212"/> - and to the demise of ATM.</t>

<t>IntServ has so far seen little traction because it too got superceeded as explained in the following
section - for its original use-cases (voice and video). However this type of services are being revisited for a
broader set of use-cases <xref target="RFC8575"/> in the DetNet WG, which should enable even further network infrastructure
convergence for IoT and industrial markets.</t>

</section>
<section anchor="diffserv"><name>DiffServ</name>

<t>Due to the much higher per-packet processing overhead of INSERV versus standard (so-called Best-Effort)
Internet traffic, the INTSERV model was already recognized in the 1990th to not support highest-scale at lowest
cost, leading to the parallel development of the IETF "Differentated Services WG" (DIFFSERV) model
defined in <xref target="RFC2475"/>. This has since then become the dominant technology to support multiplexing of
applications and services originally not designed for the Internet onto a common TCP/IP network infrastructure,
specifically for voice and video over UDP (<xref target="RFC768"/>) including RTP <xref target="RFC3550"/> and SIP.</t>

</section>
<section anchor="sip"><name>SIP</name>

<t>SIP has most notably in the past two decades eliminated additional network infrastructures previously required
for (voice) telephony services starting in the early 2000 with commercial/enterprise deployments and
today by removing even the option for any (non-IP/SIP) analog or digital (ISDN) telephone service connection,
instead delivering those purely as services over adaptation interfaces on home routers (TBD: Any 
RFC to cite for those tunneling/adaptation services ?).</t>

</section>
</section>
</section>
</section>
<section anchor="higher-or-new-energy-consumption"><name>Higher or new energy consumption</name>

<t>Digitized, network centric workflows may consume more energy than their non-digitized counterpart,
as may new network centric worklows without easy to compare prior workflows.</t>

<t>In one type of instances, the energy consumption on a per-instance basis is lower than in the
non-digitized/non-Internet-digitized case, but the total number of instances
that are (Internet)-digitzed is orders of magnituedes larger than their alternative options,
typically because of their higher utility or lower overall cost.</t>

<t>For example, each instance of (simple text) email consumes less energy than sending a letter or postcard.
Even streaming a movie or TV series consumes less energy than renting a DVD 
<eref target="https://www.smithsonianmag.com/science-nature/streaming-movie-less-energy-dvd-180951586">DVDvsStreaming</eref>.
Nevertheless, the total amount of instances and in result energy consumption for email and
streaming easily outranks their predecessor technologies.</t>

<t>While these instances look beneficial from a simple energy consumption
metric, its overall scale and the resulting energy consumption may in itself become an
issue, especially when the energy demand it creates risks to outstrip the possible
energy production, short term or long term. This concern is nowadays often raised against
the "digital economy", where the network energy consumption is typically cited as
a small contributor relative to its applications, such as what is running in Data Centers (DC).</t>

<t>In other cases, the energy consumption of digitization requires often significantly more
than their pre-digitization alternatives. The most well-known example of this are likely
crypto-currencies based on "proof-of-work" computations (mining), which on a per currency
value unit can cost 10..30 times or more of the energy consumed by for example gold mining
(very much depending on the highly fluctuating price of the crypto-currency). Nevertheless,
its overall utility compared to such prior currencies or valuables makes it highly
successful in the market.</t>

<t>In general, the digital economy tends to be more energy intensive on a per utility/value
unit, for example by replacing a lot of manual labor with computation), and/or it allows
for faster growth of its workflows.</t>

<t>The lower the cost of network traffic, and the more easily accessible everywhere network
connectivity is, the more competitive and/or successful most of these new workflows of the digital
economy can be.</t>

<t>Given how TCP/IP based networks, especially the Internet have excelled
through their design principles (and success) in this reduction of network traffic cost
and ubiquitous access over the past few decades, as outlined above, one can say that 
IETF technologies and especially the Internet are the most important enabler of the digital economy,
and the energy consumption it produces.</t>

</section>
<section anchor="sustainability"><name>Sustainability</name>

<t>Sustainability is the principle to utilize resources in a way that they do not diminish or run out over the long term.
Beyond the above covered energy saving, sustainability relates with respect to the IETF specifically to the use of 
renewable sources of energy to minimize exhaustion of fossile resources, and the impact of IETF technologies
on global warming to avoid worsening living conditions on the planet.</t>

<t>While there seems to be no IETF work specifically intending to target sustainability (TBD: did we miss anything ?), 
the Internet itself can similarily to how it does for digitization play a key role in building sustainable
networked IT infrastructures. The following subsections list three examples areas where global high performance,
low cost Internet networking is a key requirement.</t>

<section anchor="follow-the-energy-cloud-scheduling"><name>Follow the energy cloud scheduling</name>

<t>Renewable energy resources (except for water) do commonly have fluctuating energy output. For example,
solar energy output correlates to night/day and strength of sunlight. Cloud Data Centers (DC) consume a significant
amount of the IT sectors energy. Some workloads may simply be scheduled to consume energy in accordance
with the amount of available renewable energy at the time, not requiring the network. Significant
workloads are not elastic in time, such as interactive cloud DC interactive work (cloud based
applications) or entertainment (gaming etc.). These workloads may be instantiated or even
dynamically (over time) migrate to a DC location with sufficient renewable energy and the Internet
(or large TCP/IP OTT backbone networks) will serve as the fabric to access the remote DC and
to coordinate the instantiation/migration.</t>

</section>
<section anchor="minimize-generated-heat"><name>Minimize generated heat</name>

<t>The mayority of energy in cloud DC is normally also wasted as exhaust heat, requiring even more energy
for cooling. The warmer the location, the more energy needs to be spent for cooling. For this
reason, DC in cooler climates such as <eref target="https://greenmountain.no/power-and-cooling/"/> can help
to reduce the overall DC energy consumption significantly (independent of the energy being
consumed in the DC to be renewable itself). The Internet again plays the role of providing access
to those type of DC whole location is not optimized for consumption but for sustainable generation
of compute and storage.</t>

</section>
<section anchor="heat-recovery"><name>Heat recovery</name>

<t>Exhaust heat, especially from compute in DC, can be recovered when it is coupled to heating systems
ranging in size all the way from individual familys home through larger buildings (hotels etc.) all the
way to district heating systems. A provider of such type of compute-generated heat as a service
can sell the compute capacity as long as there is cost efficient network connectivity.  "Cloud &amp; Heat"
is an example company offering such infrastructures and services
<eref target="https://www.cloudandheat.com/wp-content/uploads/2020/02/2020_CloudHeat-Whitepaper-Cost-saving-Potential.pdf"/>.</t>

</section>
<section anchor="telecollaboration"><name>Telecollaboration</name>

<t>Telecollaboration has a long history in the IETF resulting in multiple core technologies over the decades.</t>

<t>If one considers textual communications via email and netwnews (using e.g.: NNTP) as early forms of Telecollaboration,
then telecollaboration history through IETF technology reaches back into the 1980th and earlier.</t>

<t>Around 1990, the IETF work on IP Multicast (e.g.<xref target="RFC1112"/> and later) enabled the first efficient forms
of audio/video group collaboration through an overlay network over the Internet called the MBone
<eref target="https://en.wikipedia.org/wiki/Mbone"/> which was also used by the IETF for more than a decade to
provide remote collaboration for its own (in-person + remote participation) meetings.</t>

<t>With the advent of SIP in the early 2000, commercial telecollaboration started to be built most often on SIP based
session and application protocols with multiple IETF working groups contributing to that protocol suite
(TBD: how much more example/details should we have here). Using this technology and the Internet, the
immersive nature of telecollaboration was brought to life-size video, was/is called Telepresence
<eref target="https://en.wikipedia.org/wiki/Telepresence"/> and later to even more immersive forms such as AR/VR telecollaboration.</t>

<t>In 2011, the IETF opened the "Real-Time Communication in WEB-browsers" (RTCWEB) WG, that towards the
end of that decade became the most widely supported cross-platform standard for hundreds of commercial
and free tele-collaboration solutions, including Cisco Webex, which is also used by the IETF itself, Zoom and
the new IETF collaboration suite MeetEcho (TBD: good references here ?).</t>

<t>While the various forms of Telecollaboration are mostly instances of digitization, they
are discussed under sustainability because of its comparison to in-person travel that is
not based on simple comparison of energy, but nowadays by comparing their impact on global warming,
a key fator to sustainability.</t>

<t>Telecollaboration was primarily developed because of the utility for the participants - to avoid travel
for originally predominantly business communications/collaborations. It  saw an extreme increase in use 
(TBD: references) in the Corona Crisis of 2019, when especially international travel was often prohibited,
and often even working from an office. This forced millions of people to work from home and utilizing commercial
telecollaboration tools. It equally caused most in-person events that where not cancelled to
be moved to a telecollaboration platform over the Internet - most of them likely relying on RTCWEB
protocols.</t>

<t>Actual energy consumption related comparison between teleconferencing and in-person travel is complex
but since the last decades is commonly based on calculating some form of CO2 emission equivalent of
the energy consumed, hence comparing not simply the energy consumption, but weighing it by the
impact the energy consumption has on one of the key factors (CO2 emission) known to impact sustainable
living conditions.</t>

<t><xref target="VC2014"/> is a good example of a comparison between travel and telecollaboration taking various factors
into account and using CO2 emission equivalents as its core metric. That paper concludes that carbon/
energy cost of telecollaboration could be as little as 7% of an in-person meeting. 
in-person meeting. Those numbers have various assumptions and change when time-effort of
participants is converted to carbon/energy costs. These numbers should even be better today
in favor of telecollaboration: cost of Internet traffic/bit goes down while cost of fossile fuel
for travel goes up.</t>

<t>Recently, air travel has also come under more scrutiny because the greenhouse gas emissions of air travel
at the altitudes used by commercial aviation has been calculated to have a higher global warming
impact than simply the amount of CO2 used by the air plane if it was exhausted at surface level. One
publically funded organization offering carbon offset services calculates a factor 3 of the CO2 consumption of an
air plane <eref target="https://www.atmosfair.de/de/fliegen_und_klima/flugverkehr_und_klima/klimawirkung_flugverkehr/"/>.</t>

<t>In summary: Telecollaboration has a higher sustainability benefit compared to travel than just
the comparison of energy consumption because of the higher challenge to use renewable energy
in transportation than in networking, and this is most extreme in the case of telecollaboration
that replaces air travel because of the even higher global warming impact of using fossile fuels
in air travel.</t>

</section>
</section>
<section anchor="energy-saving-in-networks-and-nodes"><name>Energy saving in networks and nodes</name>

<section anchor="LLN"><name>Low Power and Lossy Networks (LLN)</name>

<t>Low Power and Lossy Networks are networks in which nodes and/or radio links have constraints.
Low poer consumption constraints in nodes often originate from the need to operate nodes from
as long as possible from battery and/or energy harvesting such as (today most commonly) solar panels
associated with the node or ambient energy such as energy harvesting from movement for wearable nodes
or piezo cells to generate energy for mechanically operated nodes such as switches.</t>

<t>Several IETF WGs have or are producing work is primarily intended wo support LLN through multiple
layers of the protocol stack. <xref target="RFC8352"/> gives a good overview of the energy consumption related
communication challenges and solutions produced by the IETF for this space.</t>

<t>To minimize the energy needs for such nodes, their network data-processing mechanisms have to
be optimized. This includes packet header compression, fragmentation (to avoid latency through
large packets at low bitrates, packet bundling to only consume radio engergy at short time
periods, radio energy tuning to just reach the destination(s), minimization of of multicasting
to eliminate need of radio receivers to consume energy and so on. <xref target="RFC8352"/> gives a more detailled
overview, especially because different L2 technologies such as IEEE 802.15.4 type (low power)
wireless networks, Bluetooth Low Energy (BLE), WiFi (IEEE 802.11) and DEC ULE.</t>

<t>In the INTernet area of the IETF, several LLN specific WGs exist(ed):</t>

<section anchor="lowpan-wg"><name>6LOWPAN WG</name>

<t>The "IPv6 over Low power WPAN (Wireless Personal Area Networks)" (6lowpan) WG ran from 2005
to 2014 and produced 6 RFC that adopt IPv6 to IEEE 802.15.4 type (low power) wireless networks
by transmission procedures <xref target="RFC4949"/>, compression of IPv6 (and transport) packet headers <xref target="RFC6282"/>,
modifications for neighbor discovery (ND) <xref target="RFC6775"/> , as well as 3 informational RFCs
about the WPAN space and applying IPv6 to it.  "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" <xref target="RFC4944"/>,
"Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" <xref target="RFC6282"/>,
"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" <xref target="RFC6775"/> (6LOWPAN-ND).</t>

</section>
<section anchor="lpwan-wg"><name>LPWAN WG</name>

<t>Since 2014, the "IPv6 over Low Power Wide-Area Networks" (LPWAN) WG has produced 4 RFC
for low-power wide area networks, such as LoRaWAN <eref target="https://en.wikipedia.org/wiki/LoRa"/>,
with three standards, <xref target="RFC8724"/>, <xref target="RFC8824"/>, <xref target="RFC9011"/>.</t>

</section>
<section anchor="tisch-wg"><name>6TISCH WG</name>

<t>Since 2013, the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6tisch) WG has produced 7 RFC
for a version of 802.15.4 called the "Time-Slotted Channel Hopping Mode" (TSCH), which
supports deterministic latency and lower energy consumption through the use of
scheduling traffic into well defined time slots, thereby also optimizing/minimizing
energy consumption when compared to 802.15.4 without TSCH.</t>

</section>
<section anchor="lo-wg"><name>6LO WG</name>

<t>Since 2013, the "IPv6 over Networks of Resource-constrained Nodes" (6lo) WG has generalized
the work of 6lowpan for LLN in general, producing 17 RFC for IPv6-over-l2foo adaptation layer
specifications, information models, cross-adaptation layer specification (such as header
specifications) and maintenance and informational documents for other pre-existing IETF
work in this space.</t>

</section>
<section anchor="roll-wg"><name>ROLL WG</name>

<t>In the RouTinG (RTG) area of the IETF, the "Routing Over Low power and Lossy networks" (ROLL) WG
has produced since 2008 23 RFC. Initially it produced requirement RFCs of different type of
"Low-power and Lossy Networks": urban: <xref target="RFC5548"/>, industrial <xref target="RFC5673"/>, home automation
<xref target="RFC5826"/> and building automation <xref target="RFC5867"/>.</t>

<t>Since then its work is mostly focussed
on the "IPv6 Routing Protocol for Low-Power and Lossy Networks" (RPL) <xref target="RFC6550"/>, which
is used in a wide variety of the above described IPv6 instances of LLN networks
and which are discussed in two ROLL applicability statement RFCs,
 "Applicability Statement: The Use of the Routing Protocol for Low-Power and
Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control" <xref target="RFC7733"/> and
"Applicability Statement for the Routing Protocol for Low-Power and
Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks"
<xref target="RFC8036"/>.</t>

<t>The ROLL WG also wrote a more generic RFC for LLN, "Terms Used in Routing for Low-Power and Lossy Networks" <xref target="RFC7102"/>.
RPL has a highly configurable set of functions to support (energy) constrained networks. 
Unconstrained root node(s), typically edge routers between the RPL network and a backbone network
calculate "Destination-Oriented Directed Acyclic Graphs" (DODAG) and can use strict hop-by-hop
source routing with dedicated IPv6 routing headers <xref target="RFC9008"/> to minimize constrained nodes
routing related compute and memory requirements. "The Trickle Algorithm" <xref target="RFC6206"/> allows
to minimize routing related packets through automatic lazy updates. While RPL is naturally
a mesh network routing protocol, where all nodes are usually expected to be able to
participate in it, RPL also supports even more lightweight leave nodes <xref target="RFC9010"/>.</t>

<t>The 2013 <xref target="I-D.ajunior-energy-awareness-00"/> proposes the introducing of energy related parameters
into RPL to support calculation/selection of most energy efficient paths. The 2017
 "An energy optimization routing scheme for LLSs", <xref target="I-D.wang-roll-energy-optimization-scheme"/> 
observed that DODAGs in RPL tend to require more energy in nodes closer to the root and
proposed specific optimizations to reduce this problem. Neither of these drafts proceeded in the IETF.</t>

<t>While original use-cases for RPL where energy and size limited networks, its design is to a large
extend not scale limited.  Because of this, and due to its reduced compute/memory requirements for
the same size networks compared to other routing protocols, especially the so-called link-state
"Interior Gateway routing Protocols" (IGP), such as most commonly used protocols ISIS <xref target="RFC1142"/>
and OSPF <xref target="RFC2328"/>, RPL has also proliferated into use-cases for non-constrained networks, for example to support
the largest possible networks automatically, such as in <xref target="RFC8994"/>.</t>

</section>
</section>
<section anchor="constrained-nodes-and-networks"><name>Constrained Nodes and Networks</name>

<t>(Power) constrained nodes and/or networks exist in a much broader variety than coupled
with low-power and lossy networks. For example WiFi and mobile network connections are
not considered to be lossy networks, and personal mobile nodes with either connections
are order of magnitude less constrained than nodes typically attached to LLN network.
Therefore, broader work in the IETF than focussed primarily on LLN typically uses
just the term light-weight or constrained (nodes and networks).</t>

<section anchor="lwig-wg"><name>LWIG WG</name>

<t>Since 2013, the "Light-Weight Implementation Guidance" (lwig) WG is has produced 6 informational
RFC on the groups subject, much of which indirectly supports implementing power
efficient network implementations via lightweight nodes/links,  but it also
addressed the topic explicitly including via the aforementioned <xref target="RFC8352"/> and <xref target="RFC9178"/>,
"Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks".</t>

</section>
<section anchor="core-and-coap"><name>CORE and CoAP</name>

<t>In the APPlication (APP) area of the IETF, the "Constrained RESTful Environments" (core) WG
has produced since 2010 21 RFC, most of them for or related to "The Constrained Application Protocol"
(CoAP) <xref target="RFC6690"/>, which can best be described as a replacement for HTTP for constrained
environment, using UDP instead of TCP and DTLS instead of TLS, compact binary message formats
instead of human readible textual formats, RESTful message exchange semantic instead of a
broader set of options (in HTTP), but also more functionality such as (multicast)
discovery and directory services, therefore providing a more comprehensive set of common application
functions with more compact on-the-wire/radio encoding than its unconstrained alternatives.
"Object Security for Constrained RESTful Environments" (OSCORE), <xref target="RFC8613"/> is a further
product of the CoRE WG providing a more message layer based, more lightweight security
alternative to DTLS.</t>

<t>While originally designed for LLN, CoAP is transcending LLN and equally becoming standards
in unconstrained environments such as wired/ethernet industrial Machine 2 Machine (M2M) communications,
because of simplicity, flexibility and relying on the single set of protocols supporting the widest
range of deployment scenarios.</t>

<t>In the SECurity (SEC) area of the IETF, the "Authentication and Authorization for Constrained Environments" (ace)
working group has since 2014 produced 4 RFC for security functions in constrained environments,
for example CoAP based variations of prior HTTPS protocols such as EST-coaps <xref target="RFC9148"/> for
HTTPS based EST <xref target="RFC7030"/>. Constrained node support in cryptography especially
entails support for Elliptic Curve (EC) public keys due to their shorter key sizes and lower compute
requirements compared to RSA public keys with same cryptographic strength. While the benefits of
EC over RSA where making them preferred, this "additional market space" (constrained node)
benefit helped in their faster market proliferation even beyond constrained networks.</t>

</section>
</section>
<section anchor="selected-cross-wg-technologies"><name>Selected cross-WG technologies</name>

<section anchor="ip-multicast"><name>(IP) Multicast</name>

<section anchor="power-saving-with-multicast"><name>Power saving with multicast</name>

<t>IP Multicast was introduced with <xref target="RFC1112"/> and today also called "Any Source Multicast" (ASM)
has various protocols standardized in the IETF across multiple working groups. There are also
MPLS and BIER multicast protocols from the IETF developed in the equally named WGs.</t>

<t>These three, network layer multicast technologies can be a power saving technologies when used to
distribute data because they reduce the number of packets that need to be sent across
the network (through in-network-replication where needed). Because most current link and router technologies 
do not allow to actually save significant amounts of energy on lower than maximum utilization, these benefits are often only theoretical though. Software routers are the ones most likely to expose energy consumption somwhat proportional to their throughput for just the forwarding (CPU) chip.</t>

<t>Likewise, in large backbone networks, IP multicast can free up bandwidth to be used for other traffic,
such as unicast traffic, which may allow to avoid upgrades to faster and potentially more power consuming
routers/links. Today, these benefits too are most often overcompensated for by lower per-bit energy
consumption of newer generations of routers and links though.</t>

<t>Multicasting can also save energy on the transmitting station across radio links, compared to
replicated unicast traffic, but this is rarely significant, because except for
fully battery powered mesh network, there are typically non-energy-constrained nodes, such as (commonly) the
wired access-points in WiFi networks.</t>

<t>In result, today multicasting has typically no significant power saving benefits with available
network technologies. Instead it is used (for data distribution) when the amount of traffic that a unicast solution
alternatice (with so-called ingres replication) is not possible due to the total amount of
traffic generated. This includes wireless/radio networks, where equally airtime is the limiting
factor.</t>

</section>
<section anchor="coordination"><name>Power waste through multicast based service coordination</name>

<t>(IP) multicast is often not used to distribute data requested by receivers, but also
coordination type functions such as service or resource announcement, discovery or selection.
These multicast messages may not carry a lot of data, but they cause recurring, often periodic
packets to be sent across a domain and waste energy because of various ill advised designs,
including, but not limited to the following issues:</t>

<t>(a) The receivers of such packets may not even need to receive them, but the protocol
shares a multicast group with another protocol that the client does need to receive.</t>

<t>(b) The receiver should not need to receive the packet as far as multicast is concerned, but
the underlying link-layer technology still makes the receiver consume the packet at link-layer.</t>

<t>(c) The information received is not new, but just periodically refreshed.</t>

<t>(d) The packet was originated for a service selection by a client, and the receiving device
is even responding, but the client then chooses to select another device for the service/resource.</t>

<t>These problems are specifically problematic in the presence of so-called "sleepy" nodes <xref target="sleepy"/> that
need to wake up to receive such packets (unnecessarily). It is worse, when the network itself
is an LLN network where the forwarders themselves are power constrained and for example periodic
multicasting of such coordination packets wastes energy on those forwaders as well - compared
to better alternatives.</t>

<t>In 2006, the IETF standardized "Source Specific Multicast" (SSM) <xref target="RFC4607"/>, a variation of IP Multicast
that does not allow to perform these type of coordination functions but is only meant for
(and useable for) actual data distribution. SSM was introduced for other reasons than the
above described power related issues though, but deprecating the use of ASM is one way to
avoid/minimize its ill-advised use with these type of coordination functions, when energy
efficiency is an issue. <xref target="RFC8815"/> is an example for deprecating ASM for other reasons
in Service Provider networks.</t>

</section>
<section anchor="wifi"><name>Multicast problems with WiFi</name>

<t><xref target="RFC9119"/> covers multicast challenges and solution (proposals) for IP Multicast over 
WiFi. With respect to power consumption, it discusses the following aspects.</t>

<t>(a) Unnecessary wake-up of power constrained WiFi Stations (STA) nodes can be minimized by wireless
Access Points (APs) that buffer multicast packets so they are sent only periodically when
those nodes wake up.</t>

<t>(b) WiFi access points with "Multiple Input Multiple Output" (MIMO) antenna diversity
focus sent packets in a way that they are not "broadcast" to all receivers within
a particular maximum distance from the AP, making WiFi multicast transmission even
less desirable.</t>

<t>(c) It lists the most widely deployed protocols using aforementioned coordination via
IP multicast and describes their specific challenges and possible improvements.</t>

<t>(d) Existing proprietary conversion of WiFi multicast to WiFi unicast packets.</t>

</section>
</section>
<section anchor="sleepy"><name>Sleepy nodes</name>

<t>Sleepy nodes are one of the most common design solutions in support of power saving.
This includes LLN level constrained nodes, but also nodes with significant battery capacity,
such as mobile phones, tablets and notebooks, because battery lifetime has long since
been a key selling factor. In result, vendors do attempt to optimize power consumption
across all hardware and software components of such nodes, including the interface hardware
and protocols used across the nodes WiFi and mobile radios.</t>

<t>Restating from <xref target="I-D.bormann-core-roadmap-05"/>: CoAP has basic support for sleepy nodes
by allowing caching of resource information in (non-sleepy) proxy nodes. <xref target="RFC7641"/>
enhances this support by enabling sleepy nodes to update caching intermediaries on their own schedule.
Around 2012/2013, there was significant review of further review of further support for sleepy
nodes in CoAP, resulting in a long list of drafts, whose sleepy nodes benefits are discussed
in <xref target="I-D.bormann-core-roadmap-05"/>: <xref target="I-D.vial-core-mirror-server"/>, <xref target="I-D.vial-core-mirror-proxy"/>,
<xref target="I-D.fossati-core-publish-option"/>, <xref target="I-D.giacomin-core-sleepy-option"/>, <xref target="I-D.castellani-core-alive"/>,
<xref target="I-D.rahman-core-sleepy-problem-statement"/>, <xref target="I-D.rahman-core-sleepy"/>, <xref target="I-D.rahman-core-sleepy-nodes-do-we-need"/>,
<xref target="I-D.fossati-core-monitor-option"/>. None of these drafts proceeded though.</t>

<t>One partial solution to some sleepy node issues related to their energy consumption,
especially the ones caused by the use of multicast <xref target="coordination"/>, <xref target="wifi"/> is the
use of the "Constrained RESTful Environments (CoRE) Resource Directory" (CoRE-RD) <xref target="RFC9176"/>.
It allows for sleepy nodes to register discover and register resources via unicast and
avoids waking up sleepy nodes when they are not selected by a resouce consumer.</t>

<t>An partial alternative to CoRE-RD is the "DNS-Based Service Discovery" {DNS-SD} <xref target="RFC6763"/>
combined with for example "Service Registration Protocol for DNS-Based Service Discovery" <xref target="I-D.ietf-dnssd-srp"/>.
Services can be seen as a subset of resources, and in networks where DNS has to be supported
anyhow for other reasons, DNS-SD may be a sufficient alternative to CoRE-RD. It is used
for example in Thread <eref target="https://en.wikipedia.org/wiki/Thread_(network_protocol)"/> for this purpose
and the only multicast based coordination is the one to establish network wide parameters,
such as the address(es) of DNS-SD server(s).</t>

<t>"Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks"  <xref target="RFC9178"/>
discusses sleepy devices, especially the use of CoAP PubSub <xref target="I-D.ietf-core-coap-pubsub"/> as a
mechanism to build proxies for sleepy devices. "Sensor Measurement Lists (SenML)", Standardized
proxy infrastructures are best built with standard data models, such as "Sensor Measurement Lists" (SenML)
<xref target="RFC8428"/> for sensors, likely the largest number of sleepy devices, especially in LLN.</t>

<t>"Reducing Energy Consumption of Router Advertisements", <xref target="RFC7772"/> eliminates/reduces the
energy impact for sleepy nodes of the ubiquitous IPv6 "Neighbor Discovery" (ND) protocol by
giving recommends for replacing multicast "Router Advertisement" (RA) messages with so-called
directed unicast versions, therefore not waking up sleepy nodes (with an IP multicast RA message).
This was already allowed in ND <xref target="RFC4861"/>, but not recommended as the default. Note that
<xref target="RFC7772"/> does not provide all the energy related optimizations of ND as developed by 
6LoWPAN through <xref target="RFC6775"/>. <xref target="I-D.chakrabarti-nordmark-energy-aware-nd"/> proposes generalizations
for those applications for to all IPv6 links, but was not further pursued by the IETF so far.</t>

</section>
</section>
</section>
<section anchor="energy-management-networks"><name>Energy Management Networks</name>

<t>Use of IETF protocol networks in networks that operate power
consumption and production is another broad area of digitization.</t>

<section anchor="smart-grid"><name>Smart Grid</name>

<t>"Smart Grid" is the most well known instance of such energy management networks.
According to <eref target="https://en.wikipedia.org/wiki/Smart_grid"/>, the term covers
aspects mostly centered around intelligent measured and controlled
consumption of energy. This includes "Advanced Metering Infrastructure" / "Smart Meters",
remote controllable "distribution boards", "circuit breakers",
"load control" and "smart applicances". Use cases for the "Smart Grid"
include for example timed and measured operations of home devices such as
washers or charging cars, when energy consumption os below average.</t>

<t>The 2011 "Internet Protocols for the Smart Grid" <xref target="RFC6272"/> is a quite comprehensive
(66 page) overview of all IETF protocols considered to be necessary or beneficial
for Smart Grid networks. This document was written in response to interest by
the (not-yet-smart grid) community in utilizing the IETF TCP/IP technologies to
evolve previously non-TCP/IP network, and the risk that unnecessary reinvention of
the wheel/protocols would be done by that community instead of reusing what
was already well specified by the IETF.</t>

<t>Most of the overview in this document is not specific to networks used for Smart
Grid applications but just summarized in the document for the avbove described
outreach and education to the community.  The aspects most specific to Smart Grids
is the back in 2011 still somewhat in its infancy adaptation of IPv6 network
technologies to LLN networks (see <xref target="LLN"/> below): smart meters, circuit breakers,
load measurement devices, car chargers and so on - all those devices would
most likely be connected to the network via a low-power radio networks, which
ideally would utilize IPv6 directly. Support for LLN networks with IPv6 has
well improved in IETF specifications in the past decade.</t>

</section>
<section anchor="syncro-phasor-networks"><name>Syncro Phasor Networks</name>

<t>Power output of multiple power plants/generators into the same power grid needs to be synchronized
by power levels based on consumption and power phase (50/60Hz depending on
continent) to avoid that energy created out-of-phase is not only wasted, but would
actually burn out power lines or create permanent damage in power generators. When generators
go out-of-sync, they have to be emergency switched off, resulting in (rolling-)blackouts,
worsening the conditions beyond its likely root-cause such as a single overloaded
limited region.</t>

<t>Syncro Phasor Networks are networks whose goal it is to support synchronziation of
power generators across a power grid, ultimately also permitting to build larger
and more resilient power grids. "Power Measurement Units" (PMU) are their core
sensoring elements. Since about 2012? these networks have started to
move from traditional SCADA towards more TCP/IP based networking and application technologies 
"to improve power system reliability and visibility through wide area measurement and control, 
by fostering the use and capabilities of synchrophasor technology" (www.naspi.org).</t>

<t>With their fast control loop reaction time and measurement requirements, they also
benefit from reliable, fast propagation of PMU data as well as stricter clock synchronization
than most Smart Grid applications. For example, transmission lines expand under heat that
s caused by electrical load and/or environmental temperature by as much as 30% (between coldest
and hotted/highest-load times), impacting the necessary phase relationship of power generation
on either end (speed of light propagation speed based on effective length of contracted/expanded wire).</t>

<t>The length of transmission wires can be measured from
data sent across the transmission lines and measuring their propagation latency with the help of
accurate clock synchronization between sender and receiver(s), using for example network based
clock synchronization protocols. The IETF "Network Time Protocol version 4" (NTPv4), <xref target="RFC5905"/>
is one option for this. The IEEE PTP protocol is often preferred though because it specifies
better how measurements can be integrated at the hardware level of Ethernet interfaces, thus
allowing easier to achieve higher accuracy, such as Maximum Time Interval (MTIE) errors of
less than 1 msec. See for example <xref target="NASPICLOCK"/>.</t>

<t>The "North American Syncro Phasor Initiative" (NASPI), https://www.naspi.org is an example
organization in support of syncro phasor networking. It is an ongoing project by
the USA "Department of Energy" (DoE).</t>

</section>
</section>
<section anchor="energy-management-in-networks"><name>Energy Management in Networks</name>

<section anchor="metrics-and-costs"><name>Metrics and costs</name>

<t>A 2010-2013 draft <xref target="I-D.manral-bmwg-power-usage"/>, which was not adopted
discussed and proposed metrics for power consumption that where intended
to be used for benchmarking.</t>

<t>The later work in <xref target="EMAN"/> referred instead to pre-existing metrics for
measuring power consumption from other SDOs.</t>

<t>A 2011-2012 draft <xref target="I-D.jennings-energy-pricing"/>, which was not adopted,
discusses and proposes a data model to communicate time-varying cost of
energy in support of enabling time-shifting of network attached or
managed equipment consumption of power.</t>

</section>
<section anchor="EMAN"><name>EMAN WG</name>

<t>While the IETF did specify a few MIBs with aspects related to of power management,
it was only with the formation of the "Energy Management" (EMAN) WG
which ran from 2010 to 2015 and released 7 RFC,
that the IETF produced a comprehensive set of MIB based standards for
managing energy/power for network equipment and associated devices 
and integrated prior scattered power management related work
in the IETF.</t>

<t>EMAN produced (solely) a set of data/information models
(MIBs). It does not introduce any new protocol/stacks nor does it
address "questions regarding Smart Grid, electricity producers, and distributors" (from <xref target="RFC7603"/>).</t>

<t><xref target="I-D.claise-power-management-arch"/> describes
the initial EMAN architecture as envisioned by some of the core contributors to the WG.
It was rewritten in EMAN as the "Energy Management Framework" <xref target="RFC7326"/>.
"Requirements for Energy Management" are defined in <xref target="RFC6988"/>.</t>

<t>According to <xref target="RFC7326"/>, "the (EMAN) framework presents a physical reference model and
information model.  The information model consists of an Energy
Management Domain as a set of Energy Objects.  Each Energy Object can
be attributed with identity, classification, and context.  Energy
Objects can be monitored and controlled with respect to power, Power
State, energy, demand, Power Attributes, and battery.  Additionally,
the framework models relationships and capabilities between Energy Objects."</t>

<t>One category of use-cases of particular interest to network equipment vendors was and is
the managment of "Power over Ethernet" via the EMAN framework,
measuring and controlling ethernet connected devices through their PoE 
supplied power. Besides industrial, surveillance cameras and office equipment,
such as WiFi access points and phones, PoE is also positioned as a new
approach for replacing most in-building automation components including
security control for doors/windows, as well as environmental controls and lighting
through the use of an in-ceiling, PoE enabled IP/ethernet infrastructure.</t>

<t>EMAN produced version 4 of the "Entity MIB" (ENTITY-MIB) <xref target="RFC6933"/>, primarily
to introduce globally unique UUIDs for physical entities that allows to better 
link across different entities, such as a PoE port on an ethernet switch and
the device connected to that switch port.</t>

<t>The "Monitoring and Control MIB for Power and Energy" <xref target="RFC7460"/> is a
new EMAN MIB, linking against various pre-existing and new EMAN MIBs;
the ENTITY-MIB, the ENTITY-SENSOR-MIB <xref target="RFC3433"/> for which it is 
amending missing accuracy information to meet IEC power monitoring
requirements, the pre-existing IETF "Power Ethernet MIB" (POWER-ETHERNET-MIB) <xref target="RFC3621"/>
to manage PoE, and the pre-existing IETF MIB for Uninterruptable Power Supplies (UPS) (UPS-MIB) 
<xref target="RFC1628"/>, allowing for example to build control systems that manage shutdowns
of devices in case of poweer failure based on UPS battery capacity and device consumptions/priorities.
Similarily, the EMAN "Definition of Managed Objects for Battery Monitoring" <xref target="RFC7577"/>
defines objects to support battery monitoring in managed devices.</t>

<t>The pre-existing IETF "Entity State MIB" (ENTITY-STATE-MIB) <xref target="RFC4268"/> allows to
specify the operational state of entities specified via the ENTITY-MIB respective
to their power consumption and operational capabilities (e.g.: "coldStandby",
"hotStandby", "ready" etc.). Devices can also act as proxies to provide a MIB
interfaces for monitoring and control of power for other devices, that may use
other protocols, such as in case of a home gateway interfacing with various
vendor specific protocols of home equipment.</t>

<t>The EMAN "Energy Object Context MIB" <xref target="RFC7461"/> defines the
ENERGY-OBJECT-CONTEXT-MIB and IANA-ENERGY-RELATION-MIB, both of which serve to
"address device identification, context information, and the energy relationships
between devices" according to <xref target="RFC7461"/>.</t>

<t>To automatically discover and negotiate PoE power consumption
between switch and client, non-IETF technologies, such as IEEE "Link Layer Discovery Protocol" (LLDP)
 and proprietary MIBs for it, such as LLDP-EXT-MED-MIB can be used.</t>

<t>Finally, the "Energy Management (EMAN) Applicability Statement" <xref target="RFC7603"/>
provides an overview of EMAN with a user/operator perspective, also reviewing
a range ot typical scenarios it can support as well as how it could/can link
to a variety of pre-existing, non-IETF standards relevant for power management.</t>

</section>
</section>
<section anchor="power-awareness-in-network-forwarding-and-routing-protocols"><name>Power awareness in network forwarding and routing protocols</name>

<section anchor="PANET"><name>Power Aware Networks (PANET)</name>

<t>In 2013/2014, some drafts discussed/proposed how networks themselves,
specifically those of Internet Service Providers (ISP) could become
"power aware" to the extend that its power consumption could be regulated
(or self-regulate) based on the current required performance of the
network and/or available power, by reducing excess (or too power expensive)
network capacity through switching-off/low-powering components such as 
redundant routers, linecards, interfaces or links, or reducing power
consumption by reducing bitrates on links.</t>

<t>The 2013 "Power-Aware Networks (PANET): Problem Statement" <xref target="I-D.zhang-panet-problem-statement"/>
gives an overview of this concept, and so does "Power-aware Routing and Traffic Engineering: Requirements, Approaches, and Issues", <xref target="I-D.zhang-greennet"/> from the same year.</t>

<t>The 2014 <xref target="I-D.retana-rtgwg-eacp"/> exemplifies
the concept and discusses key challenges such as the reduced resilience against errors when
redundant components are switched off, the risk of increased stretch (path length) and
therefore latency under partial network component shutdown or downspeeding, as well
as the idea of saving energy through (periodic) microsleeps such as possible with
"Energy Efficient Ethernet" <eref target="https://en.wikipedia.org/wiki/Energy-Efficient_Ethernet"/>
links. The 2013 draft "Reducing Power Consumption using BGP with power source data",
<xref target="I-D.mjsraman-panet-inter-as-power-source"/> proposed BGP attributes to allow calculation
of power efficient (or for example green) paths.</t>

<t>One core market driver for this work where rolling blackouts that especially
affected India at the time of these drafts, raising the desire to be for
example reducing the total power consumption of a network in times of such
energy emergencies.</t>

<t>While there was technical interest in the IETF, the market significance for
the vendors mostly present in the IETF was considered as not to be important
enough. Likewise, traditional routers, unlike for example todays standard PC
hardware designs do exhibit little power savings upon shutdown of components
such as line-cards or interfaces.</t>

<t>In addition, an SDN / controller based solution where relatively in
their infancy back in 2013/2014, and technologies that would allow for SDN controller to
have resilient (self-healing) connectivity such as described in <xref target="RFC8368"/>/<xref target="RFC8994"/>
was also not available, making the risk of severely impacting network
reliability one of the key factors for this PANET work to not proceed so far.</t>

</section>
<section anchor="other"><name>Other</name>

<t>The non adopted, expired 2013 draft <xref target="I-D.okamoto-ccamp-midori-gmpls-extension-reqs"/>
discusses power awareness in routing in conjunction with Traffic
Engineering (tunnels), specifically in the context of Generalized MPLS (GMPLS),
e.g.: varous L2 technologies such as switched optical fiber networks. It primarily
claims the issue that the existing management objects are not sufficient to
express energy managemenet related aspects, and thus do not allow to build
energy conscious policies into PCE for such GMPLS networks.</t>

<t>The non-adopted 2013 "Requirements for an Energy-Efficient Network System",
<xref target="I-D.suzuki-eens-requirements"/> proposes a signaling of network capacity towards
DC, for example based on load or network energy management in support of 
appropriate performance control (such as VM migration) the DC - or vice versa
(DC load based traffic engineering in the network to support that DC load).</t>

<t>The non-adopted 2013 "Building power optimal Multicast Trees" <xref target="I-D.mjsraman-rtgwg-pim-power"/>
proposes that (PIM based) IP Multicast routing could perform local routing choices
in the case of "Equal Cost MultiPath" (ECMP) "Reverse Path Forwarding" (RPF)
alternatives based on the energy that would be consumed in the router, such as when
one ECMP alternative would use a more power efficient linecard or when one ECMP choice was
on the same linecard as the interfaces to which the packets would need to be routed
(and therefore avoiding to forward the packet across separate ingres and egres linecards).</t>

</section>
</section>
<section anchor="gaps"><name>Gaps</name>

<t>The 2013 "Towards an Energy-Efficient Internet" <xref target="I-D.winter-energy-efficient-internet"/>
summarizes some of the same work items as this document (as written back in 2013) and
lists additional more non-adopted drafts. It also identifies three areas of gaps, that
it suggests the IETF to work on: "Load-adaptive Resource Management",
"Energy-efficient Protocol Design" and "Energy-efficiency Metrics and Standard Benchmarking Methodologies".</t>

<t>Some aspects for those areas of gaps where partially tackled by later work in the IETF, 
but broadly speaking, most of those areas remain open to a wide range of possible further IETF/IRTF work.</t>

</section>
<section anchor="summary"><name>Summary</name>

<t>TBD</t>

</section>


  </middle>

  <back>



    <references title='Informative References'>





<reference anchor='RFC768' target='https://www.rfc-editor.org/info/rfc768'>
<front>
<title>User Datagram Protocol</title>
<author fullname='J. Postel' initials='J.' surname='Postel'><organization/></author>
<date month='August' year='1980'/>
</front>
<seriesInfo name='STD' value='6'/>
<seriesInfo name='RFC' value='768'/>
<seriesInfo name='DOI' value='10.17487/RFC0768'/>
</reference>



<reference anchor='RFC791' target='https://www.rfc-editor.org/info/rfc791'>
<front>
<title>Internet Protocol</title>
<author fullname='J. Postel' initials='J.' surname='Postel'><organization/></author>
<date month='September' year='1981'/>
</front>
<seriesInfo name='STD' value='5'/>
<seriesInfo name='RFC' value='791'/>
<seriesInfo name='DOI' value='10.17487/RFC0791'/>
</reference>



<reference anchor='RFC793' target='https://www.rfc-editor.org/info/rfc793'>
<front>
<title>Transmission Control Protocol</title>
<author fullname='J. Postel' initials='J.' surname='Postel'><organization/></author>
<date month='September' year='1981'/>
</front>
<seriesInfo name='STD' value='7'/>
<seriesInfo name='RFC' value='793'/>
<seriesInfo name='DOI' value='10.17487/RFC0793'/>
</reference>



<reference anchor='RFC822' target='https://www.rfc-editor.org/info/rfc822'>
<front>
<title>STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES</title>
<author fullname='D. Crocker' initials='D.' surname='Crocker'><organization/></author>
<date month='August' year='1982'/>
<abstract><t>This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet.  Some of RFC 733's features failed to gain adequate acceptance.  In order to simplify the standard and the software that follows it, these features have been removed.  A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced.  Obsoletes RFC 733, NIC 41952.</t></abstract>
</front>
<seriesInfo name='STD' value='11'/>
<seriesInfo name='RFC' value='822'/>
<seriesInfo name='DOI' value='10.17487/RFC0822'/>
</reference>



<reference anchor='RFC1112' target='https://www.rfc-editor.org/info/rfc1112'>
<front>
<title>Host extensions for IP multicasting</title>
<author fullname='S.E. Deering' initials='S.E.' surname='Deering'><organization/></author>
<date month='August' year='1989'/>
<abstract><t>This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting.  Recommended procedure for IP multicasting in the Internet.  This RFC obsoletes RFCs 998 and 1054.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='5'/>
<seriesInfo name='RFC' value='1112'/>
<seriesInfo name='DOI' value='10.17487/RFC1112'/>
</reference>



<reference anchor='RFC1142' target='https://www.rfc-editor.org/info/rfc1142'>
<front>
<title>OSI IS-IS Intra-domain Routing Protocol</title>
<author fullname='D. Oran' initials='D.' role='editor' surname='Oran'><organization/></author>
<date month='February' year='1990'/>
<abstract><t>This RFC is a republication of ISO DP 10589 as a service to the Internet community.  This is not an Internet standard.</t></abstract>
</front>
<seriesInfo name='RFC' value='1142'/>
<seriesInfo name='DOI' value='10.17487/RFC1142'/>
</reference>



<reference anchor='RFC1628' target='https://www.rfc-editor.org/info/rfc1628'>
<front>
<title>UPS Management Information Base</title>
<author fullname='J. Case' initials='J.' role='editor' surname='Case'><organization/></author>
<date month='May' year='1994'/>
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it defines objects for managing uninterruptible power supply (UPS) systems.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1628'/>
<seriesInfo name='DOI' value='10.17487/RFC1628'/>
</reference>



<reference anchor='RFC1866' target='https://www.rfc-editor.org/info/rfc1866'>
<front>
<title>Hypertext Markup Language - 2.0</title>
<author fullname='T. Berners-Lee' initials='T.' surname='Berners-Lee'><organization/></author>
<author fullname='D. Connolly' initials='D.' surname='Connolly'><organization/></author>
<date month='November' year='1995'/>
<abstract><t>This document defines a HTML 2.0 (to distinguish it from the previous informal specifications).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1866'/>
<seriesInfo name='DOI' value='10.17487/RFC1866'/>
</reference>



<reference anchor='RFC1883' target='https://www.rfc-editor.org/info/rfc1883'>
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname='S. Deering' initials='S.' surname='Deering'><organization/></author>
<author fullname='R. Hinden' initials='R.' surname='Hinden'><organization/></author>
<date month='December' year='1995'/>
<abstract><t>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1883'/>
<seriesInfo name='DOI' value='10.17487/RFC1883'/>
</reference>



<reference anchor='RFC2086' target='https://www.rfc-editor.org/info/rfc2086'>
<front>
<title>IMAP4 ACL extension</title>
<author fullname='J. Myers' initials='J.' surname='Myers'><organization/></author>
<date month='January' year='1997'/>
<abstract><t>The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2086'/>
<seriesInfo name='DOI' value='10.17487/RFC2086'/>
</reference>



<reference anchor='RFC2212' target='https://www.rfc-editor.org/info/rfc2212'>
<front>
<title>Specification of Guaranteed Quality of Service</title>
<author fullname='S. Shenker' initials='S.' surname='Shenker'><organization/></author>
<author fullname='C. Partridge' initials='C.' surname='Partridge'><organization/></author>
<author fullname='R. Guerin' initials='R.' surname='Guerin'><organization/></author>
<date month='September' year='1997'/>
<abstract><t>This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2212'/>
<seriesInfo name='DOI' value='10.17487/RFC2212'/>
</reference>



<reference anchor='RFC2246' target='https://www.rfc-editor.org/info/rfc2246'>
<front>
<title>The TLS Protocol Version 1.0</title>
<author fullname='T. Dierks' initials='T.' surname='Dierks'><organization/></author>
<author fullname='C. Allen' initials='C.' surname='Allen'><organization/></author>
<date month='January' year='1999'/>
<abstract><t>This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.</t></abstract>
</front>
<seriesInfo name='RFC' value='2246'/>
<seriesInfo name='DOI' value='10.17487/RFC2246'/>
</reference>



<reference anchor='RFC2328' target='https://www.rfc-editor.org/info/rfc2328'>
<front>
<title>OSPF Version 2</title>
<author fullname='J. Moy' initials='J.' surname='Moy'><organization/></author>
<date month='April' year='1998'/>
<abstract><t>This memo documents version 2 of the OSPF protocol.  OSPF is a link- state routing protocol.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='54'/>
<seriesInfo name='RFC' value='2328'/>
<seriesInfo name='DOI' value='10.17487/RFC2328'/>
</reference>



<reference anchor='RFC2475' target='https://www.rfc-editor.org/info/rfc2475'>
<front>
<title>An Architecture for Differentiated Services</title>
<author fullname='S. Blake' initials='S.' surname='Blake'><organization/></author>
<author fullname='D. Black' initials='D.' surname='Black'><organization/></author>
<author fullname='M. Carlson' initials='M.' surname='Carlson'><organization/></author>
<author fullname='E. Davies' initials='E.' surname='Davies'><organization/></author>
<author fullname='Z. Wang' initials='Z.' surname='Wang'><organization/></author>
<author fullname='W. Weiss' initials='W.' surname='Weiss'><organization/></author>
<date month='December' year='1998'/>
<abstract><t>This document defines an architecture for implementing scalable service differentiation in the Internet.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2475'/>
<seriesInfo name='DOI' value='10.17487/RFC2475'/>
</reference>



<reference anchor='RFC2543' target='https://www.rfc-editor.org/info/rfc2543'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></author>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='E. Schooler' initials='E.' surname='Schooler'><organization/></author>
<author fullname='J. Rosenberg' initials='J.' surname='Rosenberg'><organization/></author>
<date month='March' year='1999'/>
<abstract><t>The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2543'/>
<seriesInfo name='DOI' value='10.17487/RFC2543'/>
</reference>



<reference anchor='RFC3433' target='https://www.rfc-editor.org/info/rfc3433'>
<front>
<title>Entity Sensor Management Information Base</title>
<author fullname='A. Bierman' initials='A.' surname='Bierman'><organization/></author>
<author fullname='D. Romascanu' initials='D.' surname='Romascanu'><organization/></author>
<author fullname='K.C. Norseth' initials='K.C.' surname='Norseth'><organization/></author>
<date month='December' year='2002'/>
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3433'/>
<seriesInfo name='DOI' value='10.17487/RFC3433'/>
</reference>



<reference anchor='RFC3550' target='https://www.rfc-editor.org/info/rfc3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='S. Casner' initials='S.' surname='Casner'><organization/></author>
<author fullname='R. Frederick' initials='R.' surname='Frederick'><organization/></author>
<author fullname='V. Jacobson' initials='V.' surname='Jacobson'><organization/></author>
<date month='July' year='2003'/>
<abstract><t>This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>
</reference>



<reference anchor='RFC3621' target='https://www.rfc-editor.org/info/rfc3621'>
<front>
<title>Power Ethernet MIB</title>
<author fullname='A. Berger' initials='A.' surname='Berger'><organization/></author>
<author fullname='D. Romascanu' initials='D.' surname='Romascanu'><organization/></author>
<date month='December' year='2003'/>
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.  This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).</t></abstract>
</front>
<seriesInfo name='RFC' value='3621'/>
<seriesInfo name='DOI' value='10.17487/RFC3621'/>
</reference>



<reference anchor='RFC3977' target='https://www.rfc-editor.org/info/rfc3977'>
<front>
<title>Network News Transfer Protocol (NNTP)</title>
<author fullname='C. Feather' initials='C.' surname='Feather'><organization/></author>
<date month='October' year='2006'/>
<abstract><t>The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today.  This document is a replacement for RFC 977, and officially updates the protocol specification.  It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3977'/>
<seriesInfo name='DOI' value='10.17487/RFC3977'/>
</reference>



<reference anchor='RFC4268' target='https://www.rfc-editor.org/info/rfc4268'>
<front>
<title>Entity State MIB</title>
<author fullname='S. Chisholm' initials='S.' surname='Chisholm'><organization/></author>
<author fullname='D. Perkins' initials='D.' surname='Perkins'><organization/></author>
<date month='November' year='2005'/>
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the Entity MIB to provide information about the state of physical entities.</t><t>In addition, this memo defines a set of Textual Conventions to represent various states of an entity.  The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4268'/>
<seriesInfo name='DOI' value='10.17487/RFC4268'/>
</reference>



<reference anchor='RFC4271' target='https://www.rfc-editor.org/info/rfc4271'>
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname='Y. Rekhter' initials='Y.' role='editor' surname='Rekhter'><organization/></author>
<author fullname='T. Li' initials='T.' role='editor' surname='Li'><organization/></author>
<author fullname='S. Hares' initials='S.' role='editor' surname='Hares'><organization/></author>
<date month='January' year='2006'/>
<abstract><t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t><t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems.  This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t><t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR).  These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network &quot;class&quot; within BGP.  BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t><t>This document obsoletes RFC 1771.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4271'/>
<seriesInfo name='DOI' value='10.17487/RFC4271'/>
</reference>



<reference anchor='RFC4607' target='https://www.rfc-editor.org/info/rfc4607'>
<front>
<title>Source-Specific Multicast for IP</title>
<author fullname='H. Holbrook' initials='H.' surname='Holbrook'><organization/></author>
<author fullname='B. Cain' initials='B.' surname='Cain'><organization/></author>
<date month='August' year='2006'/>
<abstract><t>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols.  For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use.  This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4607'/>
<seriesInfo name='DOI' value='10.17487/RFC4607'/>
</reference>



<reference anchor='RFC4861' target='https://www.rfc-editor.org/info/rfc4861'>
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></author>
<author fullname='E. Nordmark' initials='E.' surname='Nordmark'><organization/></author>
<author fullname='W. Simpson' initials='W.' surname='Simpson'><organization/></author>
<author fullname='H. Soliman' initials='H.' surname='Soliman'><organization/></author>
<date month='September' year='2007'/>
<abstract><t>This document specifies the Neighbor Discovery protocol for IP Version 6.  IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4861'/>
<seriesInfo name='DOI' value='10.17487/RFC4861'/>
</reference>



<reference anchor='RFC4944' target='https://www.rfc-editor.org/info/rfc4944'>
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author fullname='G. Montenegro' initials='G.' surname='Montenegro'><organization/></author>
<author fullname='N. Kushalnagar' initials='N.' surname='Kushalnagar'><organization/></author>
<author fullname='J. Hui' initials='J.' surname='Hui'><organization/></author>
<author fullname='D. Culler' initials='D.' surname='Culler'><organization/></author>
<date month='September' year='2007'/>
<abstract><t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4944'/>
<seriesInfo name='DOI' value='10.17487/RFC4944'/>
</reference>



<reference anchor='RFC4949' target='https://www.rfc-editor.org/info/rfc4949'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author fullname='R. Shirey' initials='R.' surname='Shirey'><organization/></author>
<date month='August' year='2007'/>
<abstract><t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='FYI' value='36'/>
<seriesInfo name='RFC' value='4949'/>
<seriesInfo name='DOI' value='10.17487/RFC4949'/>
</reference>



<reference anchor='RFC5548' target='https://www.rfc-editor.org/info/rfc5548'>
<front>
<title>Routing Requirements for Urban Low-Power and Lossy Networks</title>
<author fullname='M. Dohler' initials='M.' role='editor' surname='Dohler'><organization/></author>
<author fullname='T. Watteyne' initials='T.' role='editor' surname='Watteyne'><organization/></author>
<author fullname='T. Winter' initials='T.' role='editor' surname='Winter'><organization/></author>
<author fullname='D. Barthel' initials='D.' role='editor' surname='Barthel'><organization/></author>
<date month='May' year='2009'/>
<abstract><t>The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document.  In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions).  The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols.  The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios.  As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous.  This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='5548'/>
<seriesInfo name='DOI' value='10.17487/RFC5548'/>
</reference>



<reference anchor='RFC5673' target='https://www.rfc-editor.org/info/rfc5673'>
<front>
<title>Industrial Routing Requirements in Low-Power and Lossy Networks</title>
<author fullname='K. Pister' initials='K.' role='editor' surname='Pister'><organization/></author>
<author fullname='P. Thubert' initials='P.' role='editor' surname='Thubert'><organization/></author>
<author fullname='S. Dwars' initials='S.' surname='Dwars'><organization/></author>
<author fullname='T. Phinney' initials='T.' surname='Phinney'><organization/></author>
<date month='October' year='2009'/>
<abstract><t>The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations.  The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='5673'/>
<seriesInfo name='DOI' value='10.17487/RFC5673'/>
</reference>



<reference anchor='RFC5826' target='https://www.rfc-editor.org/info/rfc5826'>
<front>
<title>Home Automation Routing Requirements in Low-Power and Lossy Networks</title>
<author fullname='A. Brandt' initials='A.' surname='Brandt'><organization/></author>
<author fullname='J. Buron' initials='J.' surname='Buron'><organization/></author>
<author fullname='G. Porcu' initials='G.' surname='Porcu'><organization/></author>
<date month='April' year='2010'/>
<abstract><t>This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks.  In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes.  Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control).  Because such devices only cover a limited radio range, routing is often required.  The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5826'/>
<seriesInfo name='DOI' value='10.17487/RFC5826'/>
</reference>



<reference anchor='RFC5867' target='https://www.rfc-editor.org/info/rfc5867'>
<front>
<title>Building Automation Routing Requirements in Low-Power and Lossy Networks</title>
<author fullname='J. Martocci' initials='J.' role='editor' surname='Martocci'><organization/></author>
<author fullname='P. De Mil' initials='P.' surname='De Mil'><organization/></author>
<author fullname='N. Riou' initials='N.' surname='Riou'><organization/></author>
<author fullname='W. Vermeylen' initials='W.' surname='Vermeylen'><organization/></author>
<date month='June' year='2010'/>
<abstract><t>The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks.  Pursuant to this effort, this document defines the IPv6 routing requirements for building automation.  This  document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5867'/>
<seriesInfo name='DOI' value='10.17487/RFC5867'/>
</reference>



<reference anchor='RFC5905' target='https://www.rfc-editor.org/info/rfc5905'>
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
<author fullname='D. Mills' initials='D.' surname='Mills'><organization/></author>
<author fullname='J. Martin' initials='J.' role='editor' surname='Martin'><organization/></author>
<author fullname='J. Burbank' initials='J.' surname='Burbank'><organization/></author>
<author fullname='W. Kasch' initials='W.' surname='Kasch'><organization/></author>
<date month='June' year='2010'/>
<abstract><t>The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet.  This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family.  NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs.  It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required.  It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5905'/>
<seriesInfo name='DOI' value='10.17487/RFC5905'/>
</reference>



<reference anchor='RFC6206' target='https://www.rfc-editor.org/info/rfc6206'>
<front>
<title>The Trickle Algorithm</title>
<author fullname='P. Levis' initials='P.' surname='Levis'><organization/></author>
<author fullname='T. Clausen' initials='T.' surname='Clausen'><organization/></author>
<author fullname='J. Hui' initials='J.' surname='Hui'><organization/></author>
<author fullname='O. Gnawali' initials='O.' surname='Gnawali'><organization/></author>
<author fullname='J. Ko' initials='J.' surname='Ko'><organization/></author>
<date month='March' year='2011'/>
<abstract><t>The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner.  Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change.  A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density.  This document describes the Trickle algorithm and considerations in its use.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6206'/>
<seriesInfo name='DOI' value='10.17487/RFC6206'/>
</reference>



<reference anchor='RFC6272' target='https://www.rfc-editor.org/info/rfc6272'>
<front>
<title>Internet Protocols for the Smart Grid</title>
<author fullname='F. Baker' initials='F.' surname='Baker'><organization/></author>
<author fullname='D. Meyer' initials='D.' surname='Meyer'><organization/></author>
<date month='June' year='2011'/>
<abstract><t>This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid.  The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid.  In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here.  This document is  not an Internet Standards Track specification; it is published for  informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6272'/>
<seriesInfo name='DOI' value='10.17487/RFC6272'/>
</reference>



<reference anchor='RFC6282' target='https://www.rfc-editor.org/info/rfc6282'>
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
<author fullname='J. Hui' initials='J.' role='editor' surname='Hui'><organization/></author>
<author fullname='P. Thubert' initials='P.' surname='Thubert'><organization/></author>
<date month='September' year='2011'/>
<abstract><t>This document updates RFC 4944, &quot;Transmission of IPv6 Packets over IEEE 802.15.4 Networks&quot;.  This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs).  The compression format relies on shared context to allow compression of arbitrary prefixes.  How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers.  UDP header compression is specified within this framework.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6282'/>
<seriesInfo name='DOI' value='10.17487/RFC6282'/>
</reference>



<reference anchor='RFC6550' target='https://www.rfc-editor.org/info/rfc6550'>
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
<author fullname='T. Winter' initials='T.' role='editor' surname='Winter'><organization/></author>
<author fullname='P. Thubert' initials='P.' role='editor' surname='Thubert'><organization/></author>
<author fullname='A. Brandt' initials='A.' surname='Brandt'><organization/></author>
<author fullname='J. Hui' initials='J.' surname='Hui'><organization/></author>
<author fullname='R. Kelsey' initials='R.' surname='Kelsey'><organization/></author>
<author fullname='P. Levis' initials='P.' surname='Levis'><organization/></author>
<author fullname='K. Pister' initials='K.' surname='Pister'><organization/></author>
<author fullname='R. Struik' initials='R.' surname='Struik'><organization/></author>
<author fullname='JP. Vasseur' initials='JP.' surname='Vasseur'><organization/></author>
<author fullname='R. Alexander' initials='R.' surname='Alexander'><organization/></author>
<date month='March' year='2012'/>
<abstract><t>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6550'/>
<seriesInfo name='DOI' value='10.17487/RFC6550'/>
</reference>



<reference anchor='RFC6690' target='https://www.rfc-editor.org/info/rfc6690'>
<front>
<title>Constrained RESTful Environments (CoRE) Link Format</title>
<author fullname='Z. Shelby' initials='Z.' surname='Shelby'><organization/></author>
<date month='August' year='2012'/>
<abstract><t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type.  &quot;RESTful&quot; refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6690'/>
<seriesInfo name='DOI' value='10.17487/RFC6690'/>
</reference>



<reference anchor='RFC6763' target='https://www.rfc-editor.org/info/rfc6763'>
<front>
<title>DNS-Based Service Discovery</title>
<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/></author>
<author fullname='M. Krochmal' initials='M.' surname='Krochmal'><organization/></author>
<date month='February' year='2013'/>
<abstract><t>This document specifies how DNS resource records are named and structured to facilitate service discovery.  Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t></abstract>
</front>
<seriesInfo name='RFC' value='6763'/>
<seriesInfo name='DOI' value='10.17487/RFC6763'/>
</reference>



<reference anchor='RFC6775' target='https://www.rfc-editor.org/info/rfc6775'>
<front>
<title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
<author fullname='Z. Shelby' initials='Z.' role='editor' surname='Shelby'><organization/></author>
<author fullname='S. Chakrabarti' initials='S.' surname='Chakrabarti'><organization/></author>
<author fullname='E. Nordmark' initials='E.' surname='Nordmark'><organization/></author>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></author>
<date month='November' year='2012'/>
<abstract><t>The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4.  This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation.  In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links.  IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network.  This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks.  The document thus updates RFC 4944 to specify the use of the optimizations defined here.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6775'/>
<seriesInfo name='DOI' value='10.17487/RFC6775'/>
</reference>



<reference anchor='RFC6933' target='https://www.rfc-editor.org/info/rfc6933'>
<front>
<title>Entity MIB (Version 4)</title>
<author fullname='A. Bierman' initials='A.' surname='Bierman'><organization/></author>
<author fullname='D. Romascanu' initials='D.' surname='Romascanu'><organization/></author>
<author fullname='J. Quittek' initials='J.' surname='Quittek'><organization/></author>
<author fullname='M. Chandramouli' initials='M.' surname='Chandramouli'><organization/></author>
<date month='May' year='2013'/>
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent.  This document specifies version 4 of the Entity MIB.  This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.</t></abstract>
</front>
<seriesInfo name='RFC' value='6933'/>
<seriesInfo name='DOI' value='10.17487/RFC6933'/>
</reference>



<reference anchor='RFC6988' target='https://www.rfc-editor.org/info/rfc6988'>
<front>
<title>Requirements for Energy Management</title>
<author fullname='J. Quittek' initials='J.' role='editor' surname='Quittek'><organization/></author>
<author fullname='M. Chandramouli' initials='M.' surname='Chandramouli'><organization/></author>
<author fullname='R. Winter' initials='R.' surname='Winter'><organization/></author>
<author fullname='T. Dietz' initials='T.' surname='Dietz'><organization/></author>
<author fullname='B. Claise' initials='B.' surname='Claise'><organization/></author>
<date month='September' year='2013'/>
<abstract><t>This document defines requirements for standards specifications for Energy Management.  The requirements defined in this document are concerned with monitoring functions as well as control functions. Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries.  Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.</t><t>This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.</t></abstract>
</front>
<seriesInfo name='RFC' value='6988'/>
<seriesInfo name='DOI' value='10.17487/RFC6988'/>
</reference>



<reference anchor='RFC7030' target='https://www.rfc-editor.org/info/rfc7030'>
<front>
<title>Enrollment over Secure Transport</title>
<author fullname='M. Pritikin' initials='M.' role='editor' surname='Pritikin'><organization/></author>
<author fullname='P. Yee' initials='P.' role='editor' surname='Yee'><organization/></author>
<author fullname='D. Harkins' initials='D.' role='editor' surname='Harkins'><organization/></author>
<date month='October' year='2013'/>
<abstract><t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport.  This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates.  It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t></abstract>
</front>
<seriesInfo name='RFC' value='7030'/>
<seriesInfo name='DOI' value='10.17487/RFC7030'/>
</reference>



<reference anchor='RFC7102' target='https://www.rfc-editor.org/info/rfc7102'>
<front>
<title>Terms Used in Routing for Low-Power and Lossy Networks</title>
<author fullname='JP. Vasseur' initials='JP.' surname='Vasseur'><organization/></author>
<date month='January' year='2014'/>
<abstract><t>This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs).  An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links.  There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.</t></abstract>
</front>
<seriesInfo name='RFC' value='7102'/>
<seriesInfo name='DOI' value='10.17487/RFC7102'/>
</reference>



<reference anchor='RFC7326' target='https://www.rfc-editor.org/info/rfc7326'>
<front>
<title>Energy Management Framework</title>
<author fullname='J. Parello' initials='J.' surname='Parello'><organization/></author>
<author fullname='B. Claise' initials='B.' surname='Claise'><organization/></author>
<author fullname='B. Schoening' initials='B.' surname='Schoening'><organization/></author>
<author fullname='J. Quittek' initials='J.' surname='Quittek'><organization/></author>
<date month='September' year='2014'/>
<abstract><t>This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks.  The framework presents a physical reference model and information model.  The information model consists of an Energy Management Domain as a set of Energy Objects.  Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between Energy Objects.</t></abstract>
</front>
<seriesInfo name='RFC' value='7326'/>
<seriesInfo name='DOI' value='10.17487/RFC7326'/>
</reference>



<reference anchor='RFC7460' target='https://www.rfc-editor.org/info/rfc7460'>
<front>
<title>Monitoring and Control MIB for Power and Energy</title>
<author fullname='M. Chandramouli' initials='M.' surname='Chandramouli'><organization/></author>
<author fullname='B. Claise' initials='B.' surname='Claise'><organization/></author>
<author fullname='B. Schoening' initials='B.' surname='Schoening'><organization/></author>
<author fullname='J. Quittek' initials='J.' surname='Quittek'><organization/></author>
<author fullname='T. Dietz' initials='T.' surname='Dietz'><organization/></author>
<date month='March' year='2015'/>
<abstract><t>This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.</t></abstract>
</front>
<seriesInfo name='RFC' value='7460'/>
<seriesInfo name='DOI' value='10.17487/RFC7460'/>
</reference>



<reference anchor='RFC7461' target='https://www.rfc-editor.org/info/rfc7461'>
<front>
<title>Energy Object Context MIB</title>
<author fullname='J. Parello' initials='J.' surname='Parello'><organization/></author>
<author fullname='B. Claise' initials='B.' surname='Claise'><organization/></author>
<author fullname='M. Chandramouli' initials='M.' surname='Chandramouli'><organization/></author>
<date month='March' year='2015'/>
<abstract><t>This document defines a subset of a Management Information Base (MIB) for energy management of devices.  The module addresses device identification, context information, and the energy relationships between devices.</t></abstract>
</front>
<seriesInfo name='RFC' value='7461'/>
<seriesInfo name='DOI' value='10.17487/RFC7461'/>
</reference>



<reference anchor='RFC7577' target='https://www.rfc-editor.org/info/rfc7577'>
<front>
<title>Definition of Managed Objects for Battery Monitoring</title>
<author fullname='J. Quittek' initials='J.' surname='Quittek'><organization/></author>
<author fullname='R. Winter' initials='R.' surname='Winter'><organization/></author>
<author fullname='T. Dietz' initials='T.' surname='Dietz'><organization/></author>
<date month='July' year='2015'/>
<abstract><t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices.</t></abstract>
</front>
<seriesInfo name='RFC' value='7577'/>
<seriesInfo name='DOI' value='10.17487/RFC7577'/>
</reference>



<reference anchor='RFC7603' target='https://www.rfc-editor.org/info/rfc7603'>
<front>
<title>Energy Management (EMAN) Applicability Statement</title>
<author fullname='B. Schoening' initials='B.' surname='Schoening'><organization/></author>
<author fullname='M. Chandramouli' initials='M.' surname='Chandramouli'><organization/></author>
<author fullname='B. Nordman' initials='B.' surname='Nordman'><organization/></author>
<date month='August' year='2015'/>
<abstract><t>The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices.  This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs.  Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.</t></abstract>
</front>
<seriesInfo name='RFC' value='7603'/>
<seriesInfo name='DOI' value='10.17487/RFC7603'/>
</reference>



<reference anchor='RFC7641' target='https://www.rfc-editor.org/info/rfc7641'>
<front>
<title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
<author fullname='K. Hartke' initials='K.' surname='Hartke'><organization/></author>
<date month='September' year='2015'/>
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to &quot;observe&quot; resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t></abstract>
</front>
<seriesInfo name='RFC' value='7641'/>
<seriesInfo name='DOI' value='10.17487/RFC7641'/>
</reference>



<reference anchor='RFC7733' target='https://www.rfc-editor.org/info/rfc7733'>
<front>
<title>Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control</title>
<author fullname='A. Brandt' initials='A.' surname='Brandt'><organization/></author>
<author fullname='E. Baccelli' initials='E.' surname='Baccelli'><organization/></author>
<author fullname='R. Cragie' initials='R.' surname='Cragie'><organization/></author>
<author fullname='P. van der Stok' initials='P.' surname='van der Stok'><organization/></author>
<date month='February' year='2016'/>
<abstract><t>The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7733'/>
<seriesInfo name='DOI' value='10.17487/RFC7733'/>
</reference>



<reference anchor='RFC7772' target='https://www.rfc-editor.org/info/rfc7772'>
<front>
<title>Reducing Energy Consumption of Router Advertisements</title>
<author fullname='A. Yourtchenko' initials='A.' surname='Yourtchenko'><organization/></author>
<author fullname='L. Colitti' initials='L.' surname='Colitti'><organization/></author>
<date month='February' year='2016'/>
<abstract><t>Frequent Router Advertisement messages can severely impact host power consumption.  This document recommends operational practices to avoid such impact.</t></abstract>
</front>
<seriesInfo name='BCP' value='202'/>
<seriesInfo name='RFC' value='7772'/>
<seriesInfo name='DOI' value='10.17487/RFC7772'/>
</reference>



<reference anchor='RFC8036' target='https://www.rfc-editor.org/info/rfc8036'>
<front>
<title>Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks</title>
<author fullname='N. Cam-Winget' initials='N.' role='editor' surname='Cam-Winget'><organization/></author>
<author fullname='J. Hui' initials='J.' surname='Hui'><organization/></author>
<author fullname='D. Popa' initials='D.' surname='Popa'><organization/></author>
<date month='January' year='2017'/>
<abstract><t>This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.</t></abstract>
</front>
<seriesInfo name='RFC' value='8036'/>
<seriesInfo name='DOI' value='10.17487/RFC8036'/>
</reference>



<reference anchor='RFC8352' target='https://www.rfc-editor.org/info/rfc8352'>
<front>
<title>Energy-Efficient Features of Internet of Things Protocols</title>
<author fullname='C. Gomez' initials='C.' surname='Gomez'><organization/></author>
<author fullname='M. Kovatsch' initials='M.' surname='Kovatsch'><organization/></author>
<author fullname='H. Tian' initials='H.' surname='Tian'><organization/></author>
<author fullname='Z. Cao' initials='Z.' role='editor' surname='Cao'><organization/></author>
<date month='April' year='2018'/>
<abstract><t>This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges.  It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior.  The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.</t></abstract>
</front>
<seriesInfo name='RFC' value='8352'/>
<seriesInfo name='DOI' value='10.17487/RFC8352'/>
</reference>



<reference anchor='RFC8368' target='https://www.rfc-editor.org/info/rfc8368'>
<front>
<title>Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)</title>
<author fullname='T. Eckert' initials='T.' role='editor' surname='Eckert'><organization/></author>
<author fullname='M. Behringer' initials='M.' surname='Behringer'><organization/></author>
<date month='May' year='2018'/>
<abstract><t>Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.</t><t>Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on.  Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.</t><t>This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes.  This connectivity is not subject to the aforementioned circular dependencies.</t></abstract>
</front>
<seriesInfo name='RFC' value='8368'/>
<seriesInfo name='DOI' value='10.17487/RFC8368'/>
</reference>



<reference anchor='RFC8428' target='https://www.rfc-editor.org/info/rfc8428'>
<front>
<title>Sensor Measurement Lists (SenML)</title>
<author fullname='C. Jennings' initials='C.' surname='Jennings'><organization/></author>
<author fullname='Z. Shelby' initials='Z.' surname='Shelby'><organization/></author>
<author fullname='J. Arkko' initials='J.' surname='Arkko'><organization/></author>
<author fullname='A. Keranen' initials='A.' surname='Keranen'><organization/></author>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></author>
<date month='August' year='2018'/>
<abstract><t>This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML).  Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model.  A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</t></abstract>
</front>
<seriesInfo name='RFC' value='8428'/>
<seriesInfo name='DOI' value='10.17487/RFC8428'/>
</reference>



<reference anchor='RFC8575' target='https://www.rfc-editor.org/info/rfc8575'>
<front>
<title>YANG Data Model for the Precision Time Protocol (PTP)</title>
<author fullname='Y. Jiang' initials='Y.' role='editor' surname='Jiang'><organization/></author>
<author fullname='X. Liu' initials='X.' surname='Liu'><organization/></author>
<author fullname='J. Xu' initials='J.' surname='Xu'><organization/></author>
<author fullname='R. Cummings' initials='R.' role='editor' surname='Cummings'><organization/></author>
<date month='May' year='2019'/>
<abstract><t>This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008.  It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks.  The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).</t></abstract>
</front>
<seriesInfo name='RFC' value='8575'/>
<seriesInfo name='DOI' value='10.17487/RFC8575'/>
</reference>



<reference anchor='RFC8613' target='https://www.rfc-editor.org/info/rfc8613'>
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)</title>
<author fullname='G. Selander' initials='G.' surname='Selander'><organization/></author>
<author fullname='J. Mattsson' initials='J.' surname='Mattsson'><organization/></author>
<author fullname='F. Palombini' initials='F.' surname='Palombini'><organization/></author>
<author fullname='L. Seitz' initials='L.' surname='Seitz'><organization/></author>
<date month='July' year='2019'/>
<abstract><t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t><t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t></abstract>
</front>
<seriesInfo name='RFC' value='8613'/>
<seriesInfo name='DOI' value='10.17487/RFC8613'/>
</reference>



<reference anchor='RFC8724' target='https://www.rfc-editor.org/info/rfc8724'>
<front>
<title>SCHC: Generic Framework for Static Context Header Compression and Fragmentation</title>
<author fullname='A. Minaburo' initials='A.' surname='Minaburo'><organization/></author>
<author fullname='L. Toutain' initials='L.' surname='Toutain'><organization/></author>
<author fullname='C. Gomez' initials='C.' surname='Gomez'><organization/></author>
<author fullname='D. Barthel' initials='D.' surname='Barthel'><organization/></author>
<author fullname='JC. Zuniga' initials='JC.' surname='Zuniga'><organization/></author>
<date month='April' year='2020'/>
<abstract><t>This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.</t><t>SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.</t><t>This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.</t><t>The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.</t></abstract>
</front>
<seriesInfo name='RFC' value='8724'/>
<seriesInfo name='DOI' value='10.17487/RFC8724'/>
</reference>



<reference anchor='RFC8815' target='https://www.rfc-editor.org/info/rfc8815'>
<front>
<title>Deprecating Any-Source Multicast (ASM) for Interdomain Multicast</title>
<author fullname='M. Abrahamsson' initials='M.' surname='Abrahamsson'><organization/></author>
<author fullname='T. Chown' initials='T.' surname='Chown'><organization/></author>
<author fullname='L. Giuliano' initials='L.' surname='Giuliano'><organization/></author>
<author fullname='T. Eckert' initials='T.' surname='Eckert'><organization/></author>
<date month='August' year='2020'/>
<abstract><t>This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM.  The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).</t></abstract>
</front>
<seriesInfo name='BCP' value='229'/>
<seriesInfo name='RFC' value='8815'/>
<seriesInfo name='DOI' value='10.17487/RFC8815'/>
</reference>



<reference anchor='RFC8824' target='https://www.rfc-editor.org/info/rfc8824'>
<front>
<title>Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)</title>
<author fullname='A. Minaburo' initials='A.' surname='Minaburo'><organization/></author>
<author fullname='L. Toutain' initials='L.' surname='Toutain'><organization/></author>
<author fullname='R. Andreasen' initials='R.' surname='Andreasen'><organization/></author>
<date month='June' year='2021'/>
<abstract><t>This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</t></abstract>
</front>
<seriesInfo name='RFC' value='8824'/>
<seriesInfo name='DOI' value='10.17487/RFC8824'/>
</reference>



<reference anchor='RFC8994' target='https://www.rfc-editor.org/info/rfc8994'>
<front>
<title>An Autonomic Control Plane (ACP)</title>
<author fullname='T. Eckert' initials='T.' role='editor' surname='Eckert'><organization/></author>
<author fullname='M. Behringer' initials='M.' role='editor' surname='Behringer'><organization/></author>
<author fullname='S. Bjarnason' initials='S.' surname='Bjarnason'><organization/></author>
<date month='May' year='2021'/>
<abstract><t>Autonomic functions need a control plane to communicate, which depends on some addressing and routing.  This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration.  This document defines such a plane and calls it the &quot;Autonomic Control Plane&quot;, with the primary use as a control plane for autonomic functions.  It also serves as a &quot;virtual out-of-band channel&quot; for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured.</t></abstract>
</front>
<seriesInfo name='RFC' value='8994'/>
<seriesInfo name='DOI' value='10.17487/RFC8994'/>
</reference>



<reference anchor='RFC9008' target='https://www.rfc-editor.org/info/rfc9008'>
<front>
<title>Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane</title>
<author fullname='M.I. Robles' initials='M.I.' surname='Robles'><organization/></author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organization/></author>
<author fullname='P. Thubert' initials='P.' surname='Thubert'><organization/></author>
<date month='April' year='2021'/>
<abstract><t>This document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to the RPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed.</t></abstract>
</front>
<seriesInfo name='RFC' value='9008'/>
<seriesInfo name='DOI' value='10.17487/RFC9008'/>
</reference>



<reference anchor='RFC9010' target='https://www.rfc-editor.org/info/rfc9010'>
<front>
<title>Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves</title>
<author fullname='P. Thubert' initials='P.' role='editor' surname='Thubert'><organization/></author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organization/></author>
<date month='April' year='2021'/>
<abstract><t>This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505.</t></abstract>
</front>
<seriesInfo name='RFC' value='9010'/>
<seriesInfo name='DOI' value='10.17487/RFC9010'/>
</reference>



<reference anchor='RFC9011' target='https://www.rfc-editor.org/info/rfc9011'>
<front>
<title>Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN</title>
<author fullname='O. Gimenez' initials='O.' role='editor' surname='Gimenez'><organization/></author>
<author fullname='I. Petrov' initials='I.' role='editor' surname='Petrov'><organization/></author>
<date month='April' year='2021'/>
<abstract><t>The Static Context Header Compression and fragmentation (SCHC) specification (RFC 8724) describes generic header compression and fragmentation techniques for Low-Power Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies.</t><t>This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation.</t></abstract>
</front>
<seriesInfo name='RFC' value='9011'/>
<seriesInfo name='DOI' value='10.17487/RFC9011'/>
</reference>



<reference anchor='RFC9119' target='https://www.rfc-editor.org/info/rfc9119'>
<front>
<title>Multicast Considerations over IEEE 802 Wireless Media</title>
<author fullname='C. Perkins' initials='C.' surname='Perkins'><organization/></author>
<author fullname='M. McBride' initials='M.' surname='McBride'><organization/></author>
<author fullname='D. Stanley' initials='D.' surname='Stanley'><organization/></author>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></author>
<author fullname='JC. Zúñiga' initials='JC.' surname='Zúñiga'><organization/></author>
<date month='October' year='2021'/>
<abstract><t>Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer 2 multicast.  Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network.  Finally, some recommendations are provided about the usage and combination of these features and operational choices.</t></abstract>
</front>
<seriesInfo name='RFC' value='9119'/>
<seriesInfo name='DOI' value='10.17487/RFC9119'/>
</reference>



<reference anchor='RFC9148' target='https://www.rfc-editor.org/info/rfc9148'>
<front>
<title>EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol</title>
<author fullname='P. van der Stok' initials='P.' surname='van der Stok'><organization/></author>
<author fullname='P. Kampanakis' initials='P.' surname='Kampanakis'><organization/></author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organization/></author>
<author fullname='S. Raza' initials='S.' surname='Raza'><organization/></author>
<date month='April' year='2022'/>
<abstract><t>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</t></abstract>
</front>
<seriesInfo name='RFC' value='9148'/>
<seriesInfo name='DOI' value='10.17487/RFC9148'/>
</reference>



<reference anchor='RFC9176' target='https://www.rfc-editor.org/info/rfc9176'>
<front>
<title>Constrained RESTful Environments (CoRE) Resource Directory</title>
<author fullname='C. Amsüss' initials='C.' role='editor' surname='Amsüss'><organization/></author>
<author fullname='Z. Shelby' initials='Z.' surname='Shelby'><organization/></author>
<author fullname='M. Koster' initials='M.' surname='Koster'><organization/></author>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></author>
<author fullname='P. van der Stok' initials='P.' surname='van der Stok'><organization/></author>
<date month='April' year='2022'/>
<abstract><t>In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined.</t></abstract>
</front>
<seriesInfo name='RFC' value='9176'/>
<seriesInfo name='DOI' value='10.17487/RFC9176'/>
</reference>



<reference anchor='RFC9178' target='https://www.rfc-editor.org/info/rfc9178'>
<front>
<title>Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks</title>
<author fullname='J. Arkko' initials='J.' surname='Arkko'><organization/></author>
<author fullname='A. Eriksson' initials='A.' surname='Eriksson'><organization/></author>
<author fullname='A. Keränen' initials='A.' surname='Keränen'><organization/></author>
<date month='May' year='2022'/>
<abstract><t>This memo discusses the use of the Constrained Application Protocol (CoAP) in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.</t></abstract>
</front>
<seriesInfo name='RFC' value='9178'/>
<seriesInfo name='DOI' value='10.17487/RFC9178'/>
</reference>


<reference anchor='I-D.ajunior-energy-awareness-00'>
   <front>
      <title>Energy-awareness metrics global applicability guidelines</title>
      <author fullname='Antonio Junior' initials='A.' surname='Junior'>
         </author>
      <author fullname='Rute C. Sofia' initials='R. C.' surname='Sofia'>
         </author>
      <date day='16' month='October' year='2012'/>
      <abstract>
	 <t>   This document describes a new set of energy-awareness metrics which
   have been devised to be applicable to any multihop routing protocol,
   including the Routing for Low Power and Lossy Networks (RPL)
   protocol.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ajunior-energy-awareness-00'/>
   <format target='https://www.ietf.org/archive/id/draft-ajunior-energy-awareness-00.txt' type='TXT'/>
</reference>


<reference anchor='I-D.claise-power-management-arch'>
   <front>
      <title>Power Management Architecture</title>
      <author fullname='Benoit Claise'>
	 </author>
      <author fullname='John Parello'>
	 </author>
      <author fullname='Brad Schoening'>
	 </author>
      <date day='22' month='October' year='2010'/>
      <abstract>
	 <t>This document defines the power management architecture.  




































  &lt;Claise, et. Al&gt;

  Expires April 20, 2011



[page 2] 



  Internet-Draft
 &lt;Power Management Archictecure&gt;
Octobre 2010
	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-claise-power-management-arch-02'/>
   <format target='https://www.ietf.org/archive/id/draft-claise-power-management-arch-02.txt' type='TXT'/>
</reference>


<reference anchor='I-D.bormann-core-roadmap-05'>
   <front>
      <title>CoRE Roadmap and Implementation Guide</title>
      <author fullname='Carsten Bormann' initials='C.' surname='Bormann'>
         </author>
      <date day='21' month='October' year='2013'/>
      <abstract>
	 <t>   The CoRE set of protocols, in particular the CoAP protocol, is
   defined in draft-ietf-core-coap in conjunction with a number of
   specifications that are currently nearing completion.  There are also
   several dozen more individual Internet-Drafts in various states of
   development, with various levels of WG review and interest.

   Today, this is simply a bewildering array of documents.  Beyond the
   main four documents, it is hard to find relevant information and
   assess the status of proposals.  At the level of Internet-Drafts, the
   IETF has only adoption as a WG document to assign status - too crude
   an instrument to assess the level of development and standing for
   anyone who does not follow the daily proceedings of the WG.

   With a more long-term perspective, as additional drafts mature and
   existing specifications enter various levels of spec maintenance, the
   entirety of these specifications may become harder to understand,
   pose specific implementation problems, or be simply inconsistent.

   The present guide aims to provide a roadmap to these documents as
   well as provide specific advice how to use these specifications in
   combination.  In certain cases, it may provide clarifications or even
   corrections to the specifications referenced.

   This guide is intended as a continued work-in-progress, i.e. a long-
   lived Internet-Draft, to be updated whenever new information becomes
   available and new consensus on how to handle issues is formed.
   Similar to the ROHC implementation guide, RFC 4815, it might be
   published as an RFC at some future time later in the acceptance curve
   of the specifications.

   This document does not describe a new protocol or attempt to set a
   new standard of any kind - it mostly describes good practice in using
   the existing specifications, but it may also document emerging
   consensus where a correction needs to be made.

   (TODO: The present version does not completely cover the new
   Internet-Drafts submitted concurrently with it; it is to be updated
   by the start of IETF88.)

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-bormann-core-roadmap-05'/>
   <format target='https://www.ietf.org/archive/id/draft-bormann-core-roadmap-05.txt' type='TXT'/>
</reference>


<reference anchor='I-D.castellani-core-alive'>
   <front>
      <title>CoAP Alive Message</title>
      <author fullname='Angelo P. Castellani'>
	 </author>
      <author fullname='Salvatore Loreto'>
	 </author>
      <date day='29' month='March' year='2012'/>
      <abstract>
	 <t>   In the context of a Constrained RESTful Environment (CoRE), hosts
   could frequently be energy-constrained and be turned off the vast
   majority of time for energy-saving purposes.

   In the case of a CoAP server, while it is offline, it is neither
   available to serve requests.  Clients desiring to access its
   resources have no way to understand when they will find it up again.

   This specification provides a simple new message that gives to a CoAP
   server the ability to signal its current availability in the network.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-castellani-core-alive-00'/>
   <format target='https://www.ietf.org/archive/id/draft-castellani-core-alive-00.txt' type='TXT'/>
</reference>


<reference anchor='I-D.chakrabarti-nordmark-energy-aware-nd'>
   <front>
      <title>Energy Aware IPv6 Neighbor Discovery Optimizations</title>
      <author fullname='Samita Chakrabarti'>
	 </author>
      <author fullname='Erik Nordmark'>
	 </author>
      <author fullname='Margaret Wasserman'>
	 </author>
      <date day='12' month='March' year='2012'/>
      <abstract>
	 <t>   IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
   neighbor&#39;s address resolution, unreachability detection, address
   autoconfiguration, router advertisement and solicitation.  With the
   progress of Internet adoption on various industries including home,
   wireless and machine-to-machine communications, there is a desire for
   optimizing legacy IPv6 Neighbor Discovery protocol to be more
   efficient in terms of number of signaling messages in the network.
   Efficient IPv6 Neighbor Discovery is useful for energy-efficient
   networks and as well for overlay networks such as VLANs with large
   number of nodes.  This document describes a method of optimizations
   by reducing periodic multicast messages, frequent Neighbor
   Solicitation messages and discusses interoperability with legacy IPv6
   nodes.  It also addresses the ND denial of service issues by
   introducing node Registration procedure.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-chakrabarti-nordmark-energy-aware-nd-02'/>
   <format target='https://www.ietf.org/archive/id/draft-chakrabarti-nordmark-energy-aware-nd-02.txt' type='TXT'/>
</reference>


<reference anchor='I-D.zhang-greennet'>
   <front>
      <title>Power-aware Routing and Traffic Engineering: Requirements, Approaches, and Issues</title>
      <author fullname='Beichuan Zhang'>
	 </author>
      <author fullname='Junxiao Shi'>
	 </author>
      <author fullname='Jie Dong'>
	 </author>
      <author fullname='Mingui Zhang'>
	 </author>
      <date day='10' month='January' year='2013'/>
      <abstract>
	 <t>   Energy consumption of network infrastructures is rising fast.  There
   are emerging needs for power-aware routing and traffic engineering,
   which adjust routing paths to help reduce power consumption network-
   wide.  This document gives a high-level analysis on the basic
   requirements, approaches, and potential issues in power-aware routing
   and traffic engineering.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-zhang-greennet-01'/>
   <format target='https://www.ietf.org/archive/id/draft-zhang-greennet-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.fossati-core-monitor-option'>
   <front>
      <title>Monitor Option for CoAP</title>
      <author fullname='Thomas Fossati'>
	 </author>
      <author fullname='Pierpaolo Giacomin'>
	 </author>
      <author fullname='Salvatore Loreto'>
	 </author>
      <date day='9' month='July' year='2012'/>
      <abstract>
	 <t>   This memo defines Monitor, an additional Option for the Constrained
   Application Protocol (CoAP) especially targeted at sleepy sensors.

   The Monitor Option complements the typical Observe pattern, enabling
   the tracking of a resource hosted by a node sleeping most of the
   time, by taking care of establishing and maintaining an Observe
   relationship with the (sleepy) origin on behalf of the (sleepy)
   client.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-fossati-core-monitor-option-00'/>
   <format target='https://www.ietf.org/archive/id/draft-fossati-core-monitor-option-00.txt' type='TXT'/>
</reference>


<reference anchor='I-D.fossati-core-publish-option'>
   <front>
      <title>Publish Option for CoAP</title>
      <author fullname='Thomas Fossati'>
	 </author>
      <author fullname='Pierpaolo Giacomin'>
	 </author>
      <author fullname='Salvatore Loreto'>
	 </author>
      <date day='6' month='January' year='2014'/>
      <abstract>
	 <t>   This memo defines the Publish Option for the Constrained Application
   Protocol (CoAP).  The Publish Option is used by a CoAP Endpoint to
   control the authority delegation of one of its resources to another
   Endpoint.  All the phases of the authority delegation process (setup,
   renewal, cancellation) are controlled by a simple RESTful protocol.

   This memo also introduces the &#39;proxies&#39; Web Linking relation type, to
   be used by a CoAP Proxy to explicitly advertise the resources that it
   can serve - either from its cache, or by forwarding the Client&#39;s
   request upstream.

   The Publish Option and the &#39;proxies&#39; relation provide the building
   blocks for a comprehensive, in-protocol, solution to the sleepy/
   intermittent Endpoint use case.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-fossati-core-publish-option-03'/>
   <format target='https://www.ietf.org/archive/id/draft-fossati-core-publish-option-03.txt' type='TXT'/>
</reference>


<reference anchor='I-D.giacomin-core-sleepy-option'>
   <front>
      <title>Sleepy Option for CoAP</title>
      <author fullname='Thomas Fossati'>
	 </author>
      <author fullname='Pierpaolo Giacomin'>
	 </author>
      <author fullname='Salvatore Loreto'>
	 </author>
      <author fullname='Mirko Rossini'>
	 </author>
      <date day='29' month='February' year='2012'/>
      <abstract>
	 <t>   This memo defines a framework for allowing asynchronous communication
   between sleepy sensors mediated by a supporting Proxy node.  The
   Proxy acts as a store-and-forward agent that handles requests on
   behalf of a sleepy client, and buffers responses coming from the
   target origin until the requesting client wakes up and get the
   computation results.

   A new CoAP option, Sleepy, is defined to initiate and control the
   asynchronous exchange.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-giacomin-core-sleepy-option-00'/>
   <format target='https://www.ietf.org/archive/id/draft-giacomin-core-sleepy-option-00.txt' type='TXT'/>
</reference>


<reference anchor='I-D.ietf-core-coap-pubsub'>
   <front>
      <title>Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)</title>
      <author fullname='Michael Koster'>
	 <organization>SmartThings</organization>
      </author>
      <author fullname='Ari Keranen'>
	 <organization>Ericsson</organization>
      </author>
      <author fullname='Jaime Jimenez'>
	 <organization>Ericsson</organization>
      </author>
      <date day='4' month='May' year='2022'/>
      <abstract>
	 <t>   The Constrained Application Protocol (CoAP), and related extensions
   are intended to support machine-to-machine communication in systems
   where one or more nodes are resource constrained, in particular for
   low power wireless sensor networks.  This document defines a publish-
   subscribe Broker for CoAP that extends the capabilities of CoAP for
   supporting nodes with long breaks in connectivity and/or up-time.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-core-coap-pubsub-10'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-core-coap-pubsub-10.txt' type='TXT'/>
</reference>


<reference anchor='I-D.ietf-dnssd-srp'>
   <front>
      <title>Service Registration Protocol for DNS-Based Service Discovery</title>
      <author fullname='Ted Lemon'>
	 <organization>Apple Inc.</organization>
      </author>
      <author fullname='Stuart Cheshire'>
	 <organization>Apple Inc.</organization>
      </author>
      <date day='24' month='April' year='2022'/>
      <abstract>
	 <t>   The Service Registration Protocol for DNS-Based Service Discovery
   uses the standard DNS Update mechanism to enable DNS-Based Service
   Discovery using only unicast packets.  This makes it possible to
   deploy DNS Service Discovery without multicast, which greatly
   improves scalability and improves performance on networks where
   multicast service is not an optimal choice, particularly 802.11
   (Wi-Fi) and 802.15.4 (IoT) networks.  DNS-SD Service registration
   uses public keys and SIG(0) to allow services to defend their
   registrations against attack.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-srp-13'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-13.txt' type='TXT'/>
</reference>


<reference anchor='I-D.jennings-energy-pricing'>
   <front>
      <title>Communication of Energy Price Information</title>
      <author fullname='Cullen Jennings'>
	 </author>
      <author fullname='Bruce Nordman'>
	 </author>
      <date day='10' month='July' year='2011'/>
      <abstract>
	 <t>   This specification defines media types for representing the future
   price of energy in JSON.  It also defines a way for a client device,
   such as a car, refrigerator, air conditioner, water heater, or
   display to discover a web server that can provide the future price
   for local electrical energy.  This will allow the client device to
   make intelligent decisions about when to use energy, and enable price
   distribution when the building is off-grid.  It enables obtaining
   price from a local or non-local price server.

   This draft is an early skeleton of a draft to start discussion around
   this idea.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-jennings-energy-pricing-01'/>
   <format target='https://www.ietf.org/archive/id/draft-jennings-energy-pricing-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.manral-bmwg-power-usage'>
   <front>
      <title>Benchmarking Power usage of networking devices</title>
      <author fullname='Vishwas Manral'>
	 </author>
      <author fullname='Puneet Sharma'>
	 </author>
      <author fullname='Sujata Banerjee'>
	 </author>
      <author fullname='Yang Ping'>
	 </author>
      <date day='12' month='March' year='2013'/>
      <abstract>
	 <t>   With the rapid growth of networks around the globe there is an ever
   increasing need to improve the energy efficiency of network devices.
   Operators are begining to seek more information of power consumption
   in the network, have no standard mechanism to measure, report and
   compare power usage of different networking equipment under different
   network configuration and conditions.

   This document provides suggestions for measuring power usage of live
   networks under different traffic loads and various switch router
   configuration settings.  It provides a benchmarking suite which can
   be employed for any networking device .

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-manral-bmwg-power-usage-04'/>
   <format target='https://www.ietf.org/archive/id/draft-manral-bmwg-power-usage-04.txt' type='TXT'/>
</reference>


<reference anchor='I-D.mjsraman-panet-inter-as-power-source'>
   <front>
      <title>Reducing Power Consumption using BGP with power source data</title>
      <author fullname='Shankar Raman'>
	 </author>
      <author fullname='Balaji Venkat Venkataswami'>
	 </author>
      <author fullname='Gaurav Raina'>
	 </author>
      <author fullname='Kamakoti Veezhinathan'>
	 </author>
      <date day='25' month='January' year='2013'/>
      <abstract>
	 <t>   In this paper, we propose a framework to reduce the aggregate power
   consumption of the Internet using a collaborative approach between
   Autonomous Systems (AS). We identify the low-power paths among the AS
   and then use Traffic Engineering (TE) techniques to route the packets
   along the paths. Such low-power paths can be identified by using the
   consumed-power-to-available-bandwidth (PWR) ratio as an additional
   constraint in the Constrained Shortest Path First (CSPF) algorithm.
   For re-routing the data traffic through these low-power paths, the
   Inter-AS Traffic Engineered Label Switched Path (TE-LSP) that spans
   multiple AS can be used. Extensions to the Border Gateway Protocol
   (BGP) can be used to disseminate the PWR ratio metric among the AS
   thereby creating a collaborative approach to reduce the power
   consumption. Since calculating the low-power paths can be
   computationally intensive, a graph-labeling heuristic is also
   proposed. This heuristic reduces the computational complexity but may
   provide a sub-optimal low-power path. The feasibility of our
   approaches is illustrated by applying our algorithm to a subset of
   the Internet. The techniques proposed in this paper for the Inter-AS
   power reduction require minimal modifications to the existing
   features of the Internet. The proposed techniques can be extended to
   other levels of Internet hierarchy, such as Intra-AS paths, through
   suitable modifications. The addition to this draft is that the power
   source of the Autonomous system is broken down to a ratio called PWR-
   SOURCE Ratio and used in the arrival of the metric to be used for
   this purpose.



	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-mjsraman-panet-inter-as-power-source-00'/>
   <format target='https://www.ietf.org/archive/id/draft-mjsraman-panet-inter-as-power-source-00.txt' type='TXT'/>
</reference>


<reference anchor='I-D.mjsraman-rtgwg-pim-power'>
   <front>
      <title>Building power optimal Multicast Trees</title>
      <author fullname='Shankar Raman'>
	 </author>
      <author fullname='Balaji Venkat Venkataswami'>
	 </author>
      <author fullname='Gaurav Raina'>
	 </author>
      <author fullname='Vasan Srini'>
	 </author>
      <date day='27' month='March' year='2012'/>
      <abstract>
	 <t>   Power consumption in multicast replication operations is an area of
   concern and choosing suitable replication points that can decrease
   power consumption overall assumes importance. Multicast replication
   capacity is an attribute of every line card of major routers and
   multi-layer switches that support multicast in the core of an
   Internet Service Provider (ISP) or an enterprise network.

   Currently multicast replication points on Point-to-Multipoint
   Multicast Distribution trees consume power while delivering multiple
   output streams of data from a given input stream. The multicast
   distribution trees are constructed without any regard for a proper
   placement of the replication points and consequent optimal power
   consumption at these points.

   This results in overloading certain routers while under-utilizing
   others. An optimal usage of these replication resources could reduce
   power consumption on these routers bringing power consumption to
   optimality. In this paper, we propose a mechanism by which Multicast
   Distribution Trees are constructed for carrying multicast traffic
   across multiple routers within a given network. We propose that these
   Multicast Distribution Trees be built by using the information
   pertaining to power-replication capacity ratio available with fine
   grained components such as multicast capable line-cards of routers
   and multi-layer switches deployed within a network.


	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-mjsraman-rtgwg-pim-power-02'/>
   <format target='https://www.ietf.org/archive/id/draft-mjsraman-rtgwg-pim-power-02.txt' type='TXT'/>
</reference>


<reference anchor='I-D.okamoto-ccamp-midori-gmpls-extension-reqs'>
   <front>
      <title>Requirements of GMPLS Extensions for Energy Efficient Traffic Engineering</title>
      <author fullname='Satoru Okamoto'>
	 </author>
      <date day='14' month='March' year='2013'/>
      <abstract>
	 <t>       This document discusses some of extensions required in existing GMPLS
       OSPF routing protocol, RSVP signaling protocol, and LMP to support
       the energy efficient traffic engineering technology.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-okamoto-ccamp-midori-gmpls-extension-reqs-02'/>
   <format target='https://www.ietf.org/archive/id/draft-okamoto-ccamp-midori-gmpls-extension-reqs-02.txt' type='TXT'/>
</reference>


<reference anchor='I-D.rahman-core-sleepy-nodes-do-we-need'>
   <front>
      <title>Sleepy Devices: Do we need to Support them in CORE?</title>
      <author fullname='Akbar Rahman'>
	 </author>
      <date day='11' month='February' year='2014'/>
      <abstract>
	 <t>   This document summarizes the discussion in the CORE WG related to the
   question of whether support of sleepy devices is required for the
   CoAP protocol, CORE Link Format, CORE Resource Directory, etc.  The
   only goal of this document is to trigger discussions in the CORE WG
   so that all relevant considerations for sleeping devices are taken
   into account.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-rahman-core-sleepy-nodes-do-we-need-01'/>
   <format target='https://www.ietf.org/archive/id/draft-rahman-core-sleepy-nodes-do-we-need-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.rahman-core-sleepy-problem-statement'>
   <front>
      <title>Sleepy Devices in CoAP - Problem Statement</title>
      <author fullname='Akbar Rahman'>
	 </author>
      <author fullname='Thomas Fossati'>
	 </author>
      <author fullname='Salvatore Loreto'>
	 </author>
      <author fullname='Matthieu Vial'>
	 </author>
      <date day='21' month='October' year='2012'/>
      <abstract>
	 <t>   This document analyzes the COAP protocol issues related to sleeping
   devices.  The only goal of this document is to trigger discussions in
   the CORE WG so that all relevant considerations for sleeping devices
   are taken into account when designing CoAP.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-rahman-core-sleepy-problem-statement-01'/>
   <format target='https://www.ietf.org/archive/id/draft-rahman-core-sleepy-problem-statement-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.rahman-core-sleepy'>
   <front>
      <title>Enhanced Sleepy Node Support for CoAP</title>
      <author fullname='Akbar Rahman'>
	 </author>
      <date day='11' month='February' year='2014'/>
      <abstract>
	 <t>   CoAP is a specialized web transfer protocol for constrained devices.
   These devices typically have some combination of limited battery
   power, small memory footprint and low throughput links.  It is
   expected that in CoAP networks there will be a certain portion of
   devices that are &quot;sleepy&quot; and which may occasionally go into a sleep
   mode (i.e. go into a low power state to conserve power) and
   temporarily suspend CoAP protocol communication.  This document
   proposes a minimal and efficient mechanism building on the Resource
   Directory (RD) functionality to enhance sleepy node support in CoAP
   networks.  The RD functionality may be incorporated as part of a CoAP
   Proxy.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-rahman-core-sleepy-05'/>
   <format target='https://www.ietf.org/archive/id/draft-rahman-core-sleepy-05.txt' type='TXT'/>
</reference>


<reference anchor='I-D.retana-rtgwg-eacp'>
   <front>
      <title>A Framework and Requirements for Energy Aware Control Planes</title>
      <author fullname='Alvaro Retana'>
	 </author>
      <author fullname='Russ White'>
	 </author>
      <author fullname='Manuel Paul'>
	 </author>
      <date day='24' month='October' year='2014'/>
      <abstract>
	 <t>   There has been, for several years, a rising concern over the energy
   usage of large scale networks.  This concern is strongly focused on
   campus, data center, and other highly concentrated deployments of
   network infrastructure.  Given the steadily increasing demand for
   higher network speeds, always-on service models, and ubiquitous
   network coverage, it is also of growing importance for
   telecommunication networks both local and wide area in scope.  One of
   the issues in moving forward to reduce energy usage is to ensure that
   the network can still meet the performance specifications required to
   support the applications running over it.

   This document provides an overview of the various areas of concern in
   the interaction between network performance and efforts at energy
   aware control planes, as a guide for those working on modifying
   current control planes or designing new control planes to improve the
   energy efficiency of high density, highly complex, network
   deployments.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-retana-rtgwg-eacp-03'/>
   <format target='https://www.ietf.org/archive/id/draft-retana-rtgwg-eacp-03.txt' type='TXT'/>
</reference>


<reference anchor='I-D.suzuki-eens-requirements'>
   <front>
      <title>Requirements for an Energy-Efficient Network System</title>
      <author fullname='Toshiaki Suzuki'>
	 </author>
      <author fullname='Toshiaki Tarui'>
	 </author>
      <date day='15' month='October' year='2012'/>
      <abstract>
	 <t>   Requirements concerning an energy-efficient network system such as a
   cloud system are presented.  Specifically, a large-scale cloud
   system, which is composed of multiple data centers (DCs) and a wide
   area network (WAN) to connect these DCs, is focused on.  The problems
   needed to be overcome in order to make the system energy efficient
   are presented.  The requirements that must be satisfied in order to
   solve these problems are also presented.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-suzuki-eens-requirements-00'/>
   <format target='https://www.ietf.org/archive/id/draft-suzuki-eens-requirements-00.txt' type='TXT'/>
</reference>


<reference anchor='I-D.vial-core-mirror-proxy'>
   <front>
      <title>CoRE Mirror Server</title>
      <author fullname='Matthieu Vial'>
	 </author>
      <date day='13' month='July' year='2012'/>
      <abstract>
	 <t>   The Constrained RESTful Environments (CoRE) working group aims at
   realizing the REpresentational State Transfer (REST) architecture in
   a suitable form for the most constrained nodes.  Thanks to the
   Constrained Application Protocol (CoAP), REST is now applicable to
   constrained networks.  However the most energy-constrained devices
   may enter sleep mode and disconnect their network link during several
   minutes to save energy, hence preventing them from acting as
   traditional web servers.  This document describes how a sleeping
   device can store resource representations in an entity called Mirror
   Server and participate in a constrained RESTful environment.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-vial-core-mirror-proxy-01'/>
   <format target='https://www.ietf.org/archive/id/draft-vial-core-mirror-proxy-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.vial-core-mirror-server'>
   <front>
      <title>CoRE Mirror Server</title>
      <author fullname='Matthieu Vial'>
	 </author>
      <date day='10' month='April' year='2013'/>
      <abstract>
	 <t>   The Constrained RESTful Environments (CoRE) working group aims at
   realizing the REpresentational State Transfer (REST) architecture in
   a suitable form for the most constrained nodes.  Thanks to the
   Constrained Application Protocol (CoAP), REST is now applicable to
   constrained networks.  However the most energy-constrained devices
   may enter sleep mode and disconnect their network link during several
   minutes to save energy, hence preventing them from acting as
   traditional web servers.  This document describes how a sleeping
   device can store resource representations in an entity called Mirror
   Server and participate in a constrained RESTful environment.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-vial-core-mirror-server-01'/>
   <format target='https://www.ietf.org/archive/id/draft-vial-core-mirror-server-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.wang-roll-energy-optimization-scheme'>
   <front>
      <title>An energy optimization routing scheme for LLSs</title>
      <author fullname='Hao Wang'>
	 </author>
      <author fullname='Min Wei'>
	 </author>
      <author fullname='Shuaiyong Li'>
	 </author>
      <author fullname='Qingqing Huang'>
	 </author>
      <author fullname='Ping Wang'>
	 </author>
      <author fullname='Chaomei Wang'>
	 </author>
      <date day='21' month='February' year='2017'/>
      <abstract>
	 <t>   Low-Power and Lossy Networks (LLNs) are composed of devices that
   have constraints on processing power, memory, and energy (battery
   power). It is obvious that conserving energy is especially important
   in the LLNs. This document is aimed at proposing an efficient and
   effective scheme to optimize the energy in the process of seeking
   the DAG root node.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-wang-roll-energy-optimization-scheme-00'/>
   <format target='https://www.ietf.org/archive/id/draft-wang-roll-energy-optimization-scheme-00.txt' type='TXT'/>
</reference>


<reference anchor='I-D.winter-energy-efficient-internet'>
   <front>
      <title>Towards an Energy-Efficient Internet</title>
      <author fullname='Rolf Winter'>
	 </author>
      <author fullname='Sangjin Jeong'>
	 </author>
      <author fullname='JinHyeock Choi'>
	 </author>
      <date day='22' month='October' year='2012'/>
      <abstract>
	 <t>   Climate change and cost drives all sectors of industry and society as
   a whole towards more energy-efficient technology, products and life
   styles.  The collection of Internet infrastructure and the attached
   devices are a large user of electrical energy and therefore of course
   are no exception regarding this trend.  This memo attempts to
   identify obstacles and more importantly technology options for an
   energy-efficient Internet with a focus on the protocols that are the
   product of the IETF.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-winter-energy-efficient-internet-01'/>
   <format target='https://www.ietf.org/archive/id/draft-winter-energy-efficient-internet-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.zhang-panet-problem-statement'>
   <front>
      <title>Power-Aware Networks (PANET): Problem Statement</title>
      <author fullname='Beichuan Zhang'>
	 </author>
      <author fullname='Junxiao Shi'>
	 </author>
      <author fullname='Jie Dong'>
	 </author>
      <author fullname='Mingui Zhang'>
	 </author>
      <author fullname='Mohamed Boucadair'>
	 </author>
      <date day='15' month='October' year='2013'/>
      <abstract>
	 <t>   Energy consumption of network infrastructures is growing fast due to
   exponential growth of data traffic and the deployment of increasingly
   powerful equipment.  There are emerging needs for power-aware routing
   and traffic engineering, which adapt routing paths to traffic load in
   order to reduce energy consumption network-wide.  This document
   outlines the design space and problem areas for potential IETF work.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-zhang-panet-problem-statement-03'/>
   <format target='https://www.ietf.org/archive/id/draft-zhang-panet-problem-statement-03.txt' type='TXT'/>
</reference>


<reference anchor="VC2014" target="https://www.sciencedirect.com/science/article/pii/S0140366414000620">
  <front>
    <title>Comparison of the energy, carbon and time costs of videoconferencing and in-person meetings</title>
    <author initials="D." surname="Ong" fullname="Dennis Ong">
      <organization></organization>
    </author>
    <author initials="T." surname="Moors" fullname="Tim Moors">
      <organization></organization>
    </author>
    <author initials="V." surname="Sivaraman" fullname="Vijay Sivaraman">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
  <seriesInfo name="DOI" value="10.1016/j.comcom.2014.02.009"/>
</reference>
<reference anchor="NASPICLOCK" target="https://www.naspi.org/sites/default/files/reference_documents/tstf_electric_power_system_report_pnnl_26331_march_2017_0.pdf">
  <front>
    <title>Time Synchronization in the Electric Power System</title>
    <author initials="N. T. S. T." surname="Force" fullname="NASPI Time Synchronization Task Force">
      <organization></organization>
    </author>
    <date year="2017" month="March"/>
  </front>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA7W9a3PbyNIm+B2/AsGO2SFjSd1sy5f9MKuW1G7N+KKx1Kdn
dmOjAyIhEW0S4AuQktUd/u+bz5OZVQWSPj2xEfvGec+RSbBQlZX362QyyabN
rKof3uWb9f3kTZatq/WifJdfXd7+khf1LL+sy/bhOZ/IP/LmsWwfq/IpK+7u
2vLxXV7yy0n4fNZM62IpP5+1xf16Uk6/lu16UpWytKw12X68W7dlsXyXV/Ws
XJXyX/U6mxbr8qFpn/HpfZNVq/Zdvm433frk6Ojt0UkmP5Kl/igWTS3veS67
bFW9y/I8XzdT/bf+LSuu5+/yV/hn17TypvsufN89L3v/njbLpbzcPsiKzXre
tFh1gm/xf3qs26ZsF2XX5Zc8mX/ZtAK/XzbrTVs+lVV+W07ndbNoHqqyy3+7
OfPHcNxy/S4/OTk5ys/lfW2xyC+/rVpZ8al49sem1VpOf1PU6yI/XxRtEb5o
ZrKH87P87aujV0fx042sJL9I3lQui2ohcFuX/+e0O7gvNgezMssA0HZZrKvH
Emf78sv569M3/tfb4/DXC/vrzcmJ/XV8fBz/fBn+PD3xnx+/OT0Nf77xBU6O
3vinJydhhZOTl+HTF2GFk5evX/mfr176Ci9evgh/vnp15H+envhuX7x9/dr+
fHkSTvPy5LU/8PL0KDzw5jR8+vbly/jnW/vz1auXvsKr09f+4ldvTk7Dn6e+
2Ku3R77f05Oj0/Dn65Pw55vwZ9z66enb8Ofr0xfhz3D407fhxKdv34TrOXrh
P3t9fOTrvn4RdvZazhn/DHf5KkDn9enRi/Dny/DA6/C216/D1t8cvfB137x4
FT59EeD75mW4tzevwtYFvAF1Xp84fN+8OQ4PvImfvn3rf749OnoT/jw+in/6
Jt8eH78Nf4Ybenv8+jT+KZ/K3z8JqS/LvGzbphX+kX9ti+Wsearzp3lZ53Wz
zjedMLt8cnSUz8uWZHA1uTgo/tzUVdM6gyqeilb+7Dp5juvimemiqLpysmqe
ynayLOrioQTPmBTtdO7r3IG+6noybdpy0jbFbFmsJoonXKLo1uViUdSVPlEs
jBT55byQ7d4V7bqa1E0rP22/9jY0qWf+7F/zon6YPAg7qWvhKPbpfdN1Qt26
9rKpq7UcqVmtq6be+8hqc7eouvnWIw9VIeywskN0i7JcPW89QobOr6eNHFDW
6TZ3vS9nddfNJl278k//lJ0K5Ds/0aqtphA79rVATZjh5G759GAQ3nQC4PD1
n53cZFFPVoWcd1LVa3mi6OzRrtm0091n2/UDVquW+ph/33wtls26mUynxXI1
WVazpq0mD8vVQvb2bV3WnRx00pb/0fkP2mKO5VJw1MKJu8msmTzJrZTl7N88
umqbu0W5nIjYWhNhfvxs+KYUEVfY/stiGoDYbf7afK0mcusddrip2lLFln3/
WAkM9fYrkABe/u35h992IoYjXJ6AUm2zWAQxLXe+rP4qcPOTbjqXd4Vn9Qbs
wfL+Xi4TtMCPE4xUPNVL2wMIeepfIiSOyQlEaqvqMThvlquirbpGNI77fD0v
Tc8Y59OivZNPoZfI3kqRfd26w0OP1axspk19L0RdA7H4jCDxqmyxzlIEL9Bv
wBdF+Y7/CzLehPwFULXLP9cPP3jgtlrmH5um7X7w/b+qP4vn/KZ6LIiI/HYm
hxbJL2flPwX0ohxAIPsuLj5fvcuPjw6Oj45PD/88EBKU/xzgBwdHJwei+yiI
ivYBKsR8vV517w4Pn56eDjrAflrOBBuma/zw0D45BC+ZLsrDVVUd3shKwtaF
9b88OjoSkQXofzq7ub46//D5/L/1buAWsL15rqfzVriIYgDYKa7iciFvEeLN
r0FU8pSwtOW/hapBhe/av/Rt0X3Nf2mEiBNYfQRjBcRe//DkddGtqgPRvg67
al12h7NSVJ3F+vC+EiXtUDQ8YkP5h6ilGxLK4bpb3/9R2hH+IF/4o+MR/mjL
laiJf6zqevHHyemLF8d/LLGDP7CDP44OVrP7LJtMRA++Ez2umK6z7HYuaLIs
l01eiKa1XAkqrptc8BzYmOrLwNCnpv2aCzZCBStn+d2zaI14dtV08k/5HYAL
rTtry4UAgGsp3gOXD+Vp8vt3+ZlLp3EexZDQRiNqYLPAsm0520wJWXmxfN5t
liv7Z+akBProRK0uqrq4qxaic+ZFl1frXF/f29KBndXhmMvfT20lh67x2Lxc
rORZOUi+qe+LpaxWtPlTtZ5zBZ78biO/AncoOywuyFStx5nh1LxZlViohYQN
j+EhA4DvScBePeKqHRuxu7GcQzAFu4cFUd0/C/k/FKuOZ8zwejAEOX7XLDYK
hxXuWmT+WqhQTndV5w94VbEYy7LpSdObFTAKSlR/CT/6VnXgJzzbgbCKvBFx
0pFM1rlsVhQB3uFS2G02E35eLbjnbsM3417uSlm6FYjNhEXBpsF6kdnpmWXF
bl6t8Hy3KqeVMNp8nZgX44yaDfd8V0y/PrRiDcyET6q2c1fm9/zgvm2Wcde0
zg5FccLZgdMiBWcLsRB+yq+ARIY927cezt/pna7nxTqfC9zvBC97uAzUTlE9
IFKOFbNlWdSd/lzANQWZdGpxyp5wkU+iJfFCBSpCTBuxk0TDWFYdQcyH5FD8
BRU9fypLnuIh7S1PUPaEcuVXYjbODsBs+hc9Not30TWy3nSxmdkps3881xec
60w2zAXlP4tGnl/gBoUBtfpLOcx/5huw5n9WxDfuQeri/uT/RWZUzUZQF9ct
2583TwpsXKmSQWQMCs5wBjG/ZdO4d8NaY0fYfl4IB/3W1M2SjEd4BTBI+AAJ
kxRdl3IPciIauMLjBAk22H1BnMp8Z6IHC4AFEYmcB8Kn6+ceTuazqptuOoDs
qRKw3BfyX0LUTbYU5lytFiK31cgH8eWXhRAvoFaRM5AeZLfuBzA06QL+y2rP
eVc91PyHnFquQ1BblDlZWO7krgSKL0UzEMEjes7TQcqpN92GC/BuuvyeeFD2
93/XWz8vi1Z+AKSTh4lVORBWTj/O5FrBSxIWXpdPwrvsZuQ/ZMsFzqHfw9XQ
gFrAy6bgdop5QUbJgxl311/R3xlXBirLaafFBkxTLn2xaJ46OVkBjoJf77CY
jNxWAN1AgkOFWlQ19/A0r+QadnnMc/5EOlSuANK55EN6C5vpVJDlfrPIeIYe
FHn38+JRD9ASgLzLzWpG3kiuXYEHC3mTkYIBmb+pKx7lGuXm0iX5866Sm+YD
gVVOqTDqHeC2qrI9bOSogkcLKKR0eXSkL/k0u4NlBpCCiRBRNnU4uePdgbDC
SKO62TLdm29EMSmL0lq/VnYPaxRiBgzc1Q4RtVFkff19zm0E0l0XX8ucm8+c
B4B2RPTR0XOQ35Rl/vfffdH9/buA7qf8onoQaKpSlWXpv3I577St7ghEgUIr
DNicQaolCJvAVcr3FBU1Pm1zsoIZ1sEVQaCLJu8CFUeGfOs/gLvYwDiITyq7
1UsqxAbwlwnoOuEI3Zh7mul25RbV2ASKN/eiYowz8CiytcVT8SyPc1vh7qHe
8C3n8mcF7pFyhN5jq1STLR+DOnAvIkkM4wde6xpqs/xBQAht42jwp/GeVFaJ
FV8+iHKvKoZzRkW5QF6ALzAyc7WjM8mCxcUIw5Ly+aL6i29L9uziMh/cVPzg
I569xaVRe7huxYCdNotBPrz5eHs9FnxQd93376NxBh1gRT4jmDdVHQIv+kte
ZSqGLv5Jbyj/VArb2Lv6p09hdTjaZPncGGaxAOHApQgKLsWgWauymbzVLlIY
6qZarKGArZuVm3S6hV+fRZ7eit29//2/3uL9GTcAZ+L376a3ku+IBTaKikCy
lpgOXwUEH8T43Ih+zIU+frCDwFW5uw6ERFvMKmwYvG3s+KgnmRdy9bVQ+0Cu
UNXMYjFQ6QnMHEBprfXHg77qBgzYRcJ3+dU9mDbY2CzYt+Q3YLhYk+8j2pvx
I/y8Lu9Fb8YP7alMhDYUg2kjAgvEA4lUl2PhOoJaoLQ7ITlwqansbyFsTfia
CNpiNt4iAiw4ayssR8wXsS7bEfNdzmiWvm+gU5KsdCFF4nX8NurjSxhDsilh
ZKW88H5TTxVG8vjh/UIUUuVfY7A3uYnwz07EvPG2DDdFi0YWgsGv+rpsbSZS
er6G5bF5mG9d2FrsS/k035VLvPhUlyA2muMio9RaVF+hv1F44dsFwN+tVZZX
dwqvbYafFyLXO4ph/kg4h5ynp+y4tpXJLVPTpDguWgoj6GpVvWoEk3L6OJ73
iWNo7QfxClVzI5uEztQs76o68HRK+6d5I3sQJjb9is9m5WrRPAskV0ZlChAx
wNpCryaoJiZvw6F7Jqmd2cCcpbCX7a1VoSMUw0HvqgdCESwUQOqvJLgir8UW
8d0e4HE3ZhznQZWOW3pHNTrcZGpGYEVlzrfn14dX1y7FVCWwfaZb7G9tJjS2
aFZUsY17rQp56l4s+5noXzAVqnul18SA6xveOfx1j8WChhTcAgAw9UPVXWhF
4tcmReRWxrjAZ+4xAFG1PVdbfb+iYeVrYX94D/7eswNXFA3ApliGrWRRxXP5
yDP6+YI1H+ELJxzwF2x3AoJVhCjWW8/dy25n1DuWB1RTLvehEEkeJqg8cFa7
KHyX34qoXc2b+plUT21NLG3Q0l5M5LvtnESSiOd7tMR8mGgdLbWe8MEoldtd
vhJbCNhsSouLsehqca3CQS8bFcDIFSnGq47j2FInitRB9kuU/eN/g0GuZz02
MBzWDpje0U1tKNUGvqJ2zd8HqZoNb65cqCPStkemwtYsi65agKcLAckmFGzy
L2p8tr/g+CXD4nG5t4noY8Iv8jtZg3RbZ3IPVdOGrSf82IVFIbyneaCNZecc
0Fl4IbY9D/PRrMdvIs9vLz6OEgjITZXcbMBxStIsSrdKcUceEmrGHhL2sJo/
d5AFk0XxDJtBoCG4/NX+mWi86b4PFFVvSSjTr4Lobt1+w6NyXFEUVsDoT4ld
7RzbiGQueBhQad8yy2ZWCqdcGtNOXCnpvgKOZ8LbhrzZ12+Poa1RO7p+PLVP
EZvdc9/0bbkpR7tOvVQEYo+y7xTTEFPL1JpN0NzxEOcVq7+D7QlAqoix/eaM
nQj1RjMS3CxwZMralkhDvRHackbeEJ45yH+fV6maHGlc7U16vkqlx/uqhcxp
AxFWrVn0Tox1iZOLDq/sOyOPeRIlj8+4uNTL2Qd0kuyz+ZjIwWswzDncwmKq
kItuWle9j9++PRJWSiujnMGGuhOL/WteiGmjipcKgHimO/mAxiSBEGS4eq16
zrJUUuHB+03LtVK8zXjZu/dr+HxZzybrRvS9mRqJeC7Lztbmu2i5gUQ7G+dU
QDfUc+vmaZxXamIuoJs9ldTQICAUgBMz/WgC1TAGZ0GHKOOrhfFBroFwF6IJ
JH7uHD55MTjom8KpxTi/a2ZVXCdhg9GmODfneMIFRRUwLvj67R6iMD+LEeCi
WkKxKmfG/76tECgUXMPR5s1qnJwxj2cMdn721GwWM/BPi9vNiPUiUipaxLLE
5O4ZK+HzJ1EJU5lmL8nPvvz3sXlqoK1/LelVcgKVZ9cwTkGTmbDmEs5yQWK7
2SCQ8Rz11QSSqjuJETwHrpfyPrkJ/K+KecCxwmrhx27F+aJbl5lcws8i/WWd
9wI9oPjwi64wyvwu8uHP7/0qkLiBu0iYs8CqDJwKrLNWAsHp70VlbNo+/+pj
Z/SPZb5F6AHlWo+DILvs/h6xJ1Vvvwlttf5Fl8tlTb/CbLqm/PKgiB1bpTXj
6FPTwqEFZjAX1aJhfESIgCbYw0bDGBomdX074SmC93WpjtUASV0WKGCZPoKC
dbNqeivOinUR+aNe+C+tGF0NXRBVXTeP8mCWDUXHmVxdjyLDNeMBCuasmpmf
ZdE8AfhLYO/gXhcCSvhCIoI1WhSsD9hSUXfE1Y/omS1Wq0XwQrQbZgEoL67W
wZCx6FHYk/JSvQtnnHL61cJQzwgtcCiqpxngDJFDsR10bPjOeB5VeVUIqb0j
26OHblYitIaFW3CzjdhLYpUxvuNqb1jOjpBFbwYMclUK8YtguVd1bhuikCTB
4JBhJdiCBPvKIpV0hNIaA0Sz8tt0sYHmQ++xCIm183U/hZwfGhjfKYb32kEl
h5uWFQxv7qBbx3Ppy90zs8v0y3raPq/Ugfj73GRoVwiQ7pA6A4yO9qGFVXDD
qh9G0yr4KOCkNmYRKbaDXFQW12SqGPcEFzlHuW9XZu0n4tH1x4TbfyAG3JRT
EbvrZ6iLH25c4z15efr9O30K5qnYYvguM5GsVz/In3Wpdo5HSY3jBlge9jBc
RL5Iimq5WebFzN1JGTHAjTa64xfP1CG28FjkefuwocMGrhjaxXX92HgEHgwq
Ua72qabqLzGbdsEYfaqk2Y2LPJR1HsqglnUi5H/AWFVXcCmjd77rVqF6SEJT
VAhqrHCVe0VvmqhM1zDEzYbh8v4Fw2Cc/wt5HKSBC+Fog5FJO6GQR7hY5UjC
zGeHQYh2JXzK65R1kGKfV+bcES0cZt+azoQIr2xLlb80AU+d26NUbhdsLR7e
abLwMJHYVG5VlfCnTAM2KzgNXG3FC6hImWFAitOQtFt/9KFx6TmSGswGO4Ti
bZEIsQ4KMbBCIPnT5L5ZzBDAdBu15+rp3CuhZOdmj6jXn+HI3bSdXIjw34eq
Dn6y87Pry//BRz/jD1nAoTWOIH2ezCq4yZNb4bYFDSd0RKmPM2iUwtqQowP6
2AA4CVZqnkIPUHCeVan/788NcwXULSu3BclEyRO8PnQY5Et10IIrCjqOlBKo
F90IJSvSletP5VqVITUcVF5CmtEkkFVnwjuB4jFCJgBeVp3J7y2y4knzwVln
KS8bBArIqRDh+yjoIuzp7PbjaJxnUbMTJBI8sesONojhRkkJYcbEGxgTKZmm
ns2eKSk/GYCocpIaVya1DZhDINdAO2PrSwHm2nw6YouPovYKtXwCxUC2J6wI
PE/09aksAvYm3wvq19NnxarmafJnxVAk8aBgHFKEXqMGk1hkyNGEtT9xa38S
rH0z9iNGcJ+BvGgydc3E9I+LVBHSbM9sj2FtzH4rzCl395zo9u7UmIDG1Jcx
2zD8DtExFQV1kpJ+QUVa5dNBsJl2bitIRvrGaznezxfvcmQRYuX7ytxqIXtp
LG+aIZ70Vcyr7uBglPE+EHSi6bCgmNrrPYhuJrp0qGw4ogCvP11P4H2G7jbd
WMgCpJNt3aJBa0FNrUl0e+jBDy010BtXa35/Lxh99en25vLLv0Y91ASvF+km
yL8uYfqqgrvaKO/ZxhxXbh6rwkX38YnYBhM1SRpzqC0rdfgIDTEwoMSMrBQ5
7H0BRVCALJJ7vWDcc9rzhsJr0TT5Q4PtUW0qZxpEgfJZVHVUaYWXCiLTG6Eq
uuwEbAa44FwS0mmi3Gb4GCiJyYmiX/wqslGdEEA9c9cGdRBuXs1dgLBDQpva
iIXFq1uPscV3aNjv1etXAhbbpXIwuQQ3FLs5LU81flTGuIrjuFHV920REj4y
Z2IQMtjAVXNr2ZQz4bRtxXAoraOD3HjohYh4wD3LLpRAsBUaD6YC77WOaQbM
gVRQ+T4BYZjlsEH6ibwRqDmMpP2zKLKTS8jR9SgLhqehiVpihnZmtT/R9Y98
iOc0QmaQMkcM3RbrgKSmME9UxYMDp0H2BTW4caK1mscOgQx505b6GgnkwnWf
PTRycfXLL0ok3G42K+8d3xTfX+JijfaI0BWuBCop8BeGC0kAydrIU0mYWUJ1
WzIg62urVFRsU4moB0SCDHK9NYC8YT6CZ7L0QypbyDTOegLpPriAA12oLfjb
RXBcnr6B4zJGyr/cXlsE+tWrI/PT3Fxdu/iWP7NM/osQ0qyfZk0NOg1jyN6C
vy9x5kQV/Qf771LV04Uf7Vql754T2gEZMgg8JEB348nR0VFIkVgKqxFCOiwB
01ULHha9eryXbN3MCup0bblsaAqQeOlgVFOI3EFebDb94Q3s+l03+vDq5uJT
3Gg0AqO3AZmYaogLIkJ3UxUS5qrHPboEUR6pBxWrdbBLylYsBnwlihkQ031R
KtzOZJMZ838aVDd5/ArLr8WcRhLSw2GyYHjTfxmRxeS/Khehn3hfdCskuyDK
HEQeKqxEgOAf90yNWhb+q34cg85mVUQAyhgTosdFLkjuk7leWAA72PcKvgH3
K0dH9IRUaDEni36EnWgIG3fhYgDwL4S8ux8HgFwb8UdNJWHC4ZO7zBXlst4x
DokfRr3p6Qpo+HBDMCeoAbLUm+UdIJ3sSPUNnGLoi4x0FXJTMA4mnMEYKITH
rjclyCx15Ctsk2Qsd0CI1RBMtV70Bs+b7PD0AuQj8aAeQLZkgF70rGQ2oUNI
lhp2mkKzLr+tR1oY5zjQ9RKJuNGu1DzcQr6iwoqMT3nNVGTRQXYJAtSiRX0I
hFnimdt/WUr/v1mbHh7+7OJfF3n2f8t/P3Y3vtr/M+zl9C8FkcQoqopaYJom
9U9UzzwM25hwExO8zgsyZo+zyfGbo7evjl+9ORVDpx+BipddLIHfvcs2Se9R
zj14yEQlz4fKIjQsYCjYLwre187uMHHfbofPQhCHOd/+/kXTfLVMEnBIy0XJ
7Rb3kP6yBAmOVQ8zzDDpHVRpd87tOQ5ImtnoXbm4d7la1GJldpuyF6Z6cneY
rSK6p7qR8imcc/ANVt1XOhwFCNCUVr1EELf3oz0+hnaGOIwYUIre9OS0SxP6
ss+pUAyTc5snYZDP7m1lprzIr4cCkKMLbeD8Xo6ANN/BOAlJOcPalw3XJe6S
KdXOossE4kulMcv+0GiFEq9ZQKkqETManyxf1329AlwaZeeUdSISLs5Hxv+i
cf6PYW/P6zEZ7HBI3CmwdxsaYIHhCPJNer9O00EPGLvVYB9MOZhXIe8ghJBj
gkhGF6Roo5uWNUbw4Ba4BFl3IHfa3E/kP4DywJIgTckawjiuH0aukYdYua30
nD0Wi43licJOo7/u+Ojg4MURzW5wWJVXvXIoZzUMC6fpgw+NKPz60mxIm5aq
uNZYWymEJgIzLnG/gK6jvi+U5YXX9A/8LLK4x0iylOKcSadJFsQIlXwJ0KAC
ynlhjkCgfi0ZR9C9ZEkYx5QnNTV2ajRi1qmhu9BNPev2JCkwM69nz/tmDwn3
DHAf9wBIpUvMv6mJgmatwq1GIQKLO9JcV17zaOxVOiETm2qieWof2uZpPddo
QdfTA4CELr/LECrY8vCPAy/Tkymr9Zw5tevaZyV3+2nm2t0jrqUyCuPP0wCY
bTqB+zJEK8pOc4SiAmWIYaDPHPRA2rtSDvOe6YOoWTCrQCkk+m4SdtozKRi3
L7/BpxI9A0bFaojEjAqhqCRWO8q9lqJX9bQdImFQFD/b3FXCQdassdAIXcjO
2U7qYnRdWPmCZplc+yMconXJ83aFlSbsSX2nz/IHJ7UkdAWzCDXh/ywyoH3e
bkHYkXuc+f3vY+BrEymalJLf9Ku6/v5pK1dczKX+ExaxDwAGEWliMmUnq2vp
cy3yJz81Ux5majvPKrr/5iw929QAWQRqlGnZz+VzU3swRR7Qyp9yy7873i5L
83o4klxLuK57bqh+NmeTpoBlqJR7ouvDzwGnt2lljcZqtKJrLsqnYw/KpKGc
hNNHAox5ijv3jpjgw6K5Qyp80S7NUUCXPGhIdEt8tNC4jtyg2p6ds2NhODU5
XVCMWthq5dK5Wt0keY+9Q5PHBc+EJgtvQVEtMUR4nwT5RLsJCb5iZY01VzQg
qWlDxHOBz8KSYxqStuAbqxXu3cZ06SoHQIIc4kctkk6rmMETdyN6kNGmXPzV
7ba9rVI5+NpQ9tV5RBwVQgiLl6VzasrnwgORBnuIEi/Tgk45zhD9JWcNB0wi
ZxDyuudYUa15ir80IW7sZLdoNsJ5pnNhNQvWp3wJ+BXK9hzRhuBnK437PQkG
tyMQjHpNPLs4lb22gFCPCBWtmXCzBqmIRdt/ArGTpFS0RizkEC4DMkeLXtLD
uKmZjHOQn3P7O9pYsImLXngqWgfEjdscF4HYrRef3UBVVtO3mKlx7JGo0oGk
moC/IIhklrO0M1xPFmLs8YXFo9gXhGq7DV8LgkAvGpP76LV5zMsuVjaXnCTu
EdwXPxK4MVwB2cGVQso6wMIy09Ju++K89yGJb6hfUbr1PGqsjyBoge30Bw4f
zD5aTw8YZIZY7UPtzg0gJGtqKip8PdnsuZbfKokPlaMyCrOs6HQnd8H+Fo0V
XGh8chPSMnehZ1ws5LsPYXaAYbjE/nx7y0rSOwg6F9wjreZiw4DcQnf3xR2L
yJqQ6UJTa9nIxi7OzYUlN98gPMLdztNjynYP9RxIGSe9fXRmbIFPRuoKC8cJ
nJqWboD7BI3iFcFEapcEFeMcT0W3dk8+WTvXGifoQndaoilSX5P9Liw+VJKL
BzGmIE7UKNsFIjfOoYUp10rwYR2vNM00yjlWfOL3MAEW1TIWwxVw6bsbgNXe
pAjBpIO6OdRmF+ijZIsffv9OFo36a8BaiyTUQ2hqubxsj8bQt5qGSfulLQuD
8Ygs2BkeYzi340b0UoGh6J3oOjBPKRYMOxq1rLREnso1USej0KY70Nxh8got
XAioXVlRjDalMLd0L8F9o5BPJE0SQc+0OAmlacYgm7Z4KBXxfhXMYIQAWnSW
XfYQJk1UhS/CV4Fdez423dd/jZpXuAk0M4opS8oBsRblGZsNCDYU9YNZxx1Q
3nPyQxZoUvrMkvrnTj2rrhube80FrHDyuVDeolM+4+tlVNiQ2QV/xHS9vY+D
/MwbFrQqK6bzcAl20kmfHJmr7S7ajCpCaZt30EwL0ZGsowD1P2UZQjOVpicm
mePBlZqYKwd5PlBZ9b/xbgYsmInGOY3MGqzgXl3VVkra99ynwY0s0hXca2Qb
8j3OQ+fa02oCT4ds6FCuDIz58OTo5Ojw6IT/+wd3g61MfkfO5KqAI/acCQ1U
WifXzVoTuNAo4vt3xSvULkxFidB2AFpRv/0R4xaFgklLB0PkgspedF4hhT0U
UDN0ntoc2zUGsJjv1VqxssiOPlAg1FZtICKswaPHC6lRETjUXknlwcPBuxyV
gCNyUwYzoFtRld45D4tWakYbts5ph9tfmQXFqRCVQdsYaKpTkuFAi0prNhBa
1y4HiOCNI6Q0sa9GEhqTB9BtSZQw2b7mvh8zfMyEBNXGYs6qZ3tEtOQBwTSK
zaxqDjVU5ZWV6bH8ONbuY8EIgSUZ+pUEhmiRTHz28We5mwQty/rgqfparcpZ
VbClCf51+BFiWHYdU0Mo3JAE1SsGuHcPEb1fhSEBsuu8HYlJ5v7mQ/z6qYYY
8G45/7s/vWIHmWqlLo7QRQc2SlDaZo8mNxCE24l4jZNo1x6ksDR4kydaJ2oO
CE2m5aqqZ3VW1IIbTHSuJBWQ6k+gkYAUwGJeXZdU8HkUt1iHBYSNCG1nainB
0qHbzBK+yXkOvZWHRdWfSlXjNaEo/61TNbSfWbKtcxFlswpQoVtKHfqUvDvw
wY1rzQVN3kV1X04oL4iQY3x/CJ6qeMVaKWEYiBP8I2qlD6d0kWuSoalGcZtK
8q6nnH05/NeX3Q2rn+7k6Pg4IcxmFZIoB1/KYjFhXc95r1RYEOf3y58nctYn
4dndIB9+uT2XT0ZMZVCXQ4NUG0qSLGTVFF6ixvDRMvGtWAWHxcER7mqRsyTa
yJqV2SHFAEQwF37SQo+zGmZFWHpdmOSEg062UNerw8ZJsPq86qZN/nt5V35z
d2/1I5pVnWmc/18Nq221OQP8bfx262XAzPyj0N/ldN6YMf/QNLOYJ9QRCxEy
TTwIoTb9xwybNpHVRsUwzJbfXWtcsoLV/t7dQ1t1bPkZkiges6RiLy/moTuL
WbdCN4vcmntkLNlxb7rFeqa9NmBeIq0V1xYMuXOHs5l/VRv8M9uumHFWWGZr
SGxN932wTzRrlla1VPeHJXngFnuRyuD79kSJwDURyp9EH5CemWZGkmuBCJml
cMBy9izrvow+7G2sY4lt3hVPqhWt4bUAFsLGoGaK3RkjiwgycvZ83rRNXeTn
Alzm74Ng345Vc03U3X6Zgt0Yc7q1JKFt5tUdAkbqntRPyTqc61ohORQ10cI8
wxrFFghQLBaehboqG/M7UnDyZ3MNxM2SHgkJZe6yyrUYRQoYsfA0mFWQ5tTT
GjAPG+z3BQLyTYH2KpybjBGER2vcs4crBx6yK+Enqf986XnYSKGwwIuytSwI
LagzU2pleww173uVkMKdKBdlULB+2PDObssKjBflN1bshwyifJEW9+pT6pYK
VBiSAqFf4y70xPf5+eeTvPQuS0lVc3Of7QlOjS1dOdIp063UT7Tfo61Eztox
6r1rY5uZ0fYP/OBzVhv8qOBgmG57lGu0DyxJ10z9kzseWrmjv//WToXItIO+
Tt6bBAuLvXekl0AFYBdfC5JIYNC6zyxt9qLoT6XiB0DvtGlbpwaBhsJBZtBq
CsYYG29mpcX8bKB4GBtSGK7u7G7q9Wow4TR5Uv56/Z941nq3s+JBnu357FbL
ephTYsWZscGVX5xaalO0iiwtyI5M4JKZfsCqHj/VsDjCkOZa1BMlB+rcyebv
9RTIRybOeVck5lehEde9cOd2LxTeBQBtpxsy7f4BXnBrL1stYvDOowf3G+P2
hgd8frM6gNdYu3GM86IKX89du59q1yAIV+pg3bSFwhplK3Cb7iE5mPzzgWWQ
ihtkp3HRzNylhejEa6KBqyGJWi4WbDRFWTjrtG++C9xb4ek4fbEaabKoU6qO
vlxgbqr7YHMMdaBngqVCm4tOc9y7DZPJ8gXkLdoilJlW2KkPRrOERY0tQv/I
4Aew/qDyb+TKhjSycBxQrpW2vHAmgf1tZRwUdRZ32fccFGvh7/fy7cEM1sDh
vZikD2X9h+zqj69w5sknmwdBz6/lvE0+5X8/Ve3XTf3wR/LIIX0FV7U113t+
t0dBUw+BgX9H3WLPlV7cPepWNYsjMvfNbGtTP2oQ4ckB4B9zmBagzDVV2B2X
MlvZef2Sm8SaiBaDLB4+03Q1SsiotajrqOj2m0CafabheNxfpJetDZO89+Jo
ErNTZpoSKDhusupuD7LkJFbIjhof+nc+iI2obVDx+QdZ9Tn/5I8OP3z4NMr/
/kn+53uW/dtHizYplQnN2EItEQL06E3UWC0R6RFXJ1sWcSHiCauvmrLvEE2e
4Bm4nNnVqn56+YQaHtbikOVBpT2Or7PEixf6svB3d+gz2Ib+pIZU86J9LLXR
pFuLQ01m1e4dpmmMcg1qoTuw3ILIg2aq4Y8QEMIeEAwplnd0ynic2FbdfR93
BdVt6X74p9J6jumtIZ2vKv9qWL1Br707N301elJKSCNjOAYQu/fw8k52CX+V
IMxNSW+72m2/v7cLwr6Z+YnQfGW9QtlJJFgUGrbFiWO+tqBL8Cm5KyNjSWtI
v4j+ChRTHVgZwItXcG89aKc71U/S/rM/UJpMw8z6jbsC1ZsXNTRCWXmPmG3n
k7YSEDIrkbF7m0TWkxdrqESd9I7gY7Pb3GmGSua0S4DdRbc0sKp6HsIA3g7R
tRwrMpizCSKZXqtuo7EgR/GwZCo+jjgMZlkoOLE+BBoO04U6KwFA6SQ7uo79
DXfC2xfmRaLi7DFOpVQAz8KVluMnOk0mqFQ1M1nEH9I8hE1tC7GUjY5Qc+UC
rbnfYTcaO0xDSaCX38HTyaLGJia3K0GjpJmvQv+v6tH6Qm6FY/WKc3Ru2odK
2uOPji8k5zhS9SIjzotjreeHk/1tXq4uLy/zN0cnB8evDl5qqGG4IPsS5jjK
RERqA9KYM/TzYlOKcSc8AWzOePPw5w+XApHfq1+qfBjXPNaWJxeX5/lvHy6B
ilfmS/90G/JvirRGYyxqgpIvKC903AIZs1/usJyN3mnR7OmHz79fn32S7zQk
OWBnFdqAH/wEOZ8Y/u7HuKZGLKuf4b3O8UeDfHgqpxbeBweX3JE1XTs5OnqF
a4SpwZMEgjuNDTRZgqhtXVBz/W8Bmu8ANLt7VoHt1gSJbcaQifZgePvy7ffv
45R4qAKzjUxoBwFmNeqTm/0egy/k99mymTHIGMrKZAsinu+YNtJpsC0ffroY
2c9es46p19LkRR5mlhCIaFmciWpgKeuENZlOcArTzHbQoMOA1YX7Yf0g10be
vL0+CP2SBgEcL3EctqV3ePzCTWl5FJZDToU2hNxdcPIzTeqtZR1Kg08OlIsA
lM9J5/34Dke0ieoR/4BigmAfGgAIyJYCeGhoPBHIWzX4h+vfDa1v6CAA9qn/
dgvF/c2zctJ7maAz1yAyz4tETrzEndEIQhWoksgT26Pj95HInT18aL4U2Mw/
ea/xHMBnugJ8tO7Q7bwf5usTXJz9403yD8wWsRidUPXt1c35r/3Tv9g5Pf55
i+eW1Enu+1eMIt7TtdzffBcCrwMECu/hi98HdEtiQmx4NblZNGvoG+ci90Q1
yn9tVitgtRULYxeeS5yZ1tBtVeFuVd+W7T7Rv9sxLYuZTSFxkv4I0qPXp3Hy
QiebVNndlneWcmFCGZkJJqkglPa8mUZ+arEEYHj9DA55ELjuP11OwHmB6xfL
v5oE9Re0B01DeW64IEsmhhKhjRIZsrvPjS+T7iASqiTvOCpzx7zWQJycaTVZ
nNw3TVoZRb0tlsCFcEFsvcvSP/lMgxPbP817P81DuwTlt1sLq+hbFtQqWf6i
LsGUgcYu0/RCr7XTVDkJreE5gcAK4baUOlzGl88fPvA2TKx+aTa3Vf0e0Zr3
oz2yVWM+1jPoc19SRkOojmwEL8AVZT0a6uzuj97kJy9ya4HJxtHQotfxwSSH
j8JC4xhp/wmg+eBD4EW71tjgXb5p74r6nfIKzIQC40iqX/Xz09cv8Lm6qTfr
RmGsvWoxMspiaiEDMj5jC7w5fU0mlN/Euk7PDnczmaF2DbdkliaqeO8wDU2U
iK5BOOw5lsD2+oPLWpZSOhOpzCukGb5gznDSlZprFbN1vYW0dZTrxYpAKEHB
wMvVhO3Hi4BRYukQhyyAa16MMBOGlzbO8sFZ7/ubMDOGCUa/Rav/n+GQbdvl
BEN4/oaRNdnar7jIs3hJOMXPfnnWP8wkKaZm6fVmP9poCAb9f92g7Ohs9ggA
z/KPYO6kzl6KSz48+3g1ijesuIfhXcQrQMro1VLiWsT0TaEnTxP+7lxMbnAs
AqhEmPA3uy3f+z/jloLl+OgEb5b9Jz4rNY3uq4eNGuJWxe69gLu0WHmowmKU
p8w7tv3LfqvTL1oxCmhE0jiKRUzl7CFWoAZfPKAhG3M7kwrjTqZjFlyF+eAi
Wl+Tzy0cEOgvwSk78sfZ9HmKrl/v22I1B3VdfL44e688GElRkKiecxWau2Uq
m0IXNWovM9FspvQwkK78u55OjRlpgnFpxnoPRHRu+C/TqJHnu6GJfdvLcRZ4
DoAity06nAnqL9Bndz1fBgX1iDxMa1nSN2+/x03lkApjRAQ95K9n7/fvXRtx
CUjmQ9YDrisr2HcuXIyv7l4OL2NDRpu5xNoyzHFAt45pzCAhhiHrJSSulDZr
hu9NO2B0SZZD2qxwUWoPyVkZYH98FAgK+od8/A9D4wRuNnejs7TXddAcovc1
wk8sB5C4RX+w04Qoku4chx2HCJgKqX7U7Vascua5pdHr8KTBWZijk470CoDW
0V7GBG66wdjO978yEEwOmjV3zAueqXFKMqDDkccotVeH4d1WYZZBeboQQIXe
eqRqsMUweCUY5ekGujzNeKVbjfPFUKRWUa8JNUw2CYZ2Ltt7JPl1IVliTwsP
QASHsG50ibMEVABHy7pX3FStvXMPS2oQO6YvKeNcOW2tp5Wp9luxTn/ut6xV
R3nSZSY2PictH+6hY3ZswXnYNIp7C87kVMlWbW+bvHaLsmLHDXbBpWzO2OqF
pXzeyLHdEmzggVfvr0fRluu5e1XFiLlaVzdXN9aQ//jlibVk+3xz/Ys1v3hx
QrUryBJtlNcgA6r1JorN1mWhzn2f5OhX90XSyjQSrs3dg2s7Ovudj+lAgFgi
YCbl27cvPdPzfNvY4D26fMyy4bV6Y3aYtvvOw0upiasqxvQzb/7iKhmDK5ZY
rNbvoqfMLnoada+MRL1lOvTkroon7bWdFGxhNo5njQbW2l9YEXXlrgdfsAm9
wo0Ik6WZPaTNQGOrgFmphfIpYHhEXSoK9WK9Rn4od5Nomwc6OwmtpMYBVtF+
8U51cxp0podGB7xwQfrbw1sEn7qMXlgWmaAum7JhYsLBcs59p8PY7y2USrhP
5fer9/vt1g9c8Hdd8AoXE73S7zcVi2KElhZP1QONVev+kngCezYdG2uYbWBZ
jt3m7k8B+lgxSIBtmWi1zgiMWXEc0aDvJ08AFmW7udlVb5OaMJyKTELhkMGp
ce4TpUCxWTGbwWVm/o11I3BmZyVMwdHufJY4hyVpauAmY6e21B8NKKtAPn79
hq6zoJ6TutAbyDaekuNZkioaW86eN2fXo/yi1AAx2MN5uVhsEJAKWq33Svz8
5ZIvx2+C5Xt2fR2WHco/fmj9pnv5cnlzixrby/qxahvWB4FtInnjx0bv8VF+
cgw9fdzPLdI8snReH/W5fzr7ILPDq5Z3+jZaglbM0HFwXDT3qMpbBDbYNhjN
Emow7H1ZGc81tlgrOvt4cxmkH55fq4f+9sNN73N06KS0EoUZQyxQtc6ZPJp4
VKy7LHl8vlmyo0YxI8v2xHZ7chwA7UuU3yy/pEPTBq38CovtdNjyuTVDmIVy
ztE4NmulBtMbZBKjnCEYM8qih5sCnXQHwe05CeY6Ywu8pBwmFmi35dzK1pPR
OjBL45Vm0YbSzGf/rSZATuQNE7j/Dz3apKPeLT4vxL/pmVO95gjZ4DN5SOii
qjTyz7j8+Qb0MnK36+nxC0+ZsrZj3o8y5F80Ql7C5nag4HennjDmpY131fXO
9pel3WWEFoBgO8odsziTtlY0ekENVNgQJ5haHS3EAosOLJeQjUGoLbuXGXkD
fQAm2B/jXbiA2WGJk7OyNrqRPoo8w/S1k/DX8OPJx9FW5uc4S/IcmGBjE8SS
8Tm5jsgJOYbU4uTvaG2n7XLJ+b1eEu6ebs1ypK3e8jlggWStLgmj3VyeKzYM
5a8fsryzDZxZa+c82N0Zh8OmMY0Ul7ZwSPjMKMzt1KKL2P+MobF+fEFDygFR
A1VUdf6j+xn3xgYSBTTzkX0VQ3tU7V4BHnCzp+WwUAAnYLuheAxXIdVx/YWu
KE+Zf+ToBQzJ3smZ4uCWHvbLnhsPcCo8J4p5BuFbxevjiS8Xi2oFXiZ3Ikg/
xI1YL/Kv5XNoVqnxdUahrbtvxxmeMThgxkXWsypS0+HLzVlvZa0zhbmR7Fe+
9LLjdEJDmArV3GeX5+qwx3pqVS01C5ICbeUDM20Q1iBpz2aN2umMpsTsg3CU
eSIUiiGDiVeFBhz2+2hBVJYKLPtjV4K9Hifq9je0uUMBgbCqXtE/dYQhWq+F
qiNrTafuMssiirUp+kSvSqk/Y1Gf3S5a0hQaTRBU82yAvmo36lEKa6Gd7M3H
EVUJz7VMMNe4V9oIUQef8nCxeKZfN0N3gk0opV738VrENz2kV5df4rGSN4XE
Ip1uGXLnvULI+CpmQ88QbVf/CpMb27KMXdyU+8c39JIKrPiysIiCjwLqjaGE
W32jAzozLYPELCvtmJ8kVD6n5bOxC1r0bRXrkCOFSl+2TCbQrG5Dtzt0J1hV
+wTECVQn54XeowV+iNFBMP/VVGaTnDXNbmXp9GH2z5NZ0w3raY9c4bWCkhMx
08GlmoOZdrzgPI3QK25ZfGOjck2wj3UeXUK0tNnCYAN8KwKYJnFunW4FA+/X
8H0Fl6u3OOEcFJ7MR2xxvgJSgvcVJTfLJ6vGooDSogNnX0mzWLC+YKIlDXiH
59e/ifScV8iw/SBvfKrQ366qrcB9p6p9jFLBiFlTJmGUJYaZYFKwiEbtD3pX
KgLFkJm35clcElBed0k3UtWnl6RYvyhmG21Wwixn2rPBeBMtaa8ftTZWhtFh
umVmwD20Ft234AY7t4Vetl7O49cm/JYNf+qu8Jayd94Z3psbWyrnVhqszm2N
NdTEpHDJ3i484EGWfUySkZKOw8mkVlNOLP9EJxZ0ZvsaC0oyHcepEMqcjFh5
tAVubWKo6aVtwY6VCSXEMSCxJUemo448hZHgRrFI4oo2HV3xObgI4GQyh+iO
Nyc6iYYxzRGVC9QCrdp9whl/1E7okEmkzZU33hsbu0/Tu6gDpfvoEXuPAwaE
oCQJ3TS880q/E18YwqFF60T1IZu7gEUGlsmyidADL2kOYokCmpoUrsZzBqNe
Lrx1qIpDcDDKXpF2lDDIkRf6B3dc1GK2uxZm/upQoL6dDejJT2YBRcI3l64J
oaJqmdQQRhcJaoLmNFX8oCfO2Vein6HJ86quF1urWtsLhnt/Sv/5PcuoLcSf
hhkqOLeJqnxbVEE3K5kif/ccs/miYZr1XslId1SEQ9Kqj/9oQ58aIeRa4KmW
/TjJzKJKbdGGA5PNcc9mnFlLVBZQtTB2vVka9hx6i1opFrYtIo754GGqTSU2
6TQLYnZbuKKWuUFOAxmOAj80pwh2kSs6aFJSzB7ZG1ENPbSpcydTHNfqvnvD
q9huiF0fu3dyRcWIIZSYN+ndEXyrfnAqka4Z2OPUZ2NrVdeKMoyV0ZzKAEg1
b5RO6/7orzwMU5wu6NbSIdH9Vwl2Du/6e/WCF+xuz8Y8aQ9jEopWx/wkqGhN
J6GFy/6p3CQTS5LBeEmJs/CnxcKa+a3TnXimafradbIIpMZwqttP02JsgZlz
gxr5pgAnBb+jjU9ybzm3CpCYjdKJfKxV9FR366YeaCCG0pC/ZCCOfb50Bziy
DgxEloTN2u1WTR3xKbkfpnBM543G/Rp7RbhXmzzomQE+P8YpMWjAFslSRarX
58u+Kbx1EXFLS7iJn4GxDrpFWa6eByGOqf9GCBlTVB0rnjBsXGe3OYL0cHyI
7sxhOt7IJ7uymdk4CoPgJ2ZFszXrSJz0SSNS09eYiCw0Is/7ZPao8ASHVD3r
BW4Ct+hJRafLHv/zA5BhdD3to+lsF9yEJ5tOgqrBkXxaItb3iGll+9FpUtne
M6cGZordeLgytcluxCazfNLTo9fwuBbR1aBZqYn9qHXtPhI+aJDW1My0vtim
JTl45Pl0w3eqti/LQt222VBLCksGyuWDkdkPu8JeFPubj9uWaVSBtZ2RTvek
irOdJKT36d5pZay5z2rG5mZoPzAtgivKeLlYr7pvbYYjih8V58OQfgC9RtjN
xBk9fuclI/8IFq9yVoXXQx3TZ50sp9v0NPg3x6/Mdxlbz1AvSjaO3e4ABa5B
6/UPt7t21+lPZ/spsf4DvfMU1An//ulJUOh7lplj6fgtej3p8PnEYtlfppEP
NXQuasHIMhSTt9EBk+EtB/nvWy0VU6PDSnHR7c8yuLotYVnwdzgQpOVvgVU8
k69MNpyOtkvWPOBN6I57c3s28kQANef9pqnquAqXnWmXsWtVnodn1xhcypmk
G+T3pU4II34dmawDlDudUgsemgoPIENmw+c0dqkckXJJxKpGTPXNprbzkgYf
Q5eRGjZp+Odn9uYTgv949fEzsoFEzalBWEz9XaPJ2BTzLTRTQ/e5p7Om96kb
MDKhPEQH2SUaCXZSiYJtDQcYvHKbHpTMHNDghzm7Hru3jadKXCppgjwbzzEk
CwWKKVsHKqOv1uzAqFiwf0hq8P5o7GcrmNejyMeqyHrmt446Uu7h3cND5scW
pgfjwCbMaz6Tyv9LT2UFESBmDoTUkmHPvd4+f6OfuOli92LhvxtKThekP5kg
zbLe53STxMLzJPPBM0KSYdJ18OIG+lC7DWp2ar5AhLIKdjdvIIlIJUH31CB0
y9abcUVnhQXrOQwCgSjc8dprG9flXdNwzJKp174O/Ka0kuZeD0h/fMaCYe2t
gUZgzBdUuylPzFnBqhnK8GeYirsuhbtosaGWce0ynszV/wUKo9sZHUzK5Mzb
BHktBzAHV1pQFqPKlnul0ynCOpkV1gRcpWnO163nzgi2cyVoQXas3abDwqsN
NVfqjr1GkX3SlhOQ7LJYTY5EfLzT2AIrq4sOLvLEgd8lKJTdmatIfSfTuek2
wU5L1WNBIQ790AVGOMw3W8eE1+vTl8ffv2dlPdccXU3ltnfLq9j7it6XFI2R
UcNsvbADQm+J2gtON2jcrY6qd2/xeeANuU6OjtEvzTId2pLaQ4qTmKWi5Yg+
g2j3k10AZbo5OTRgmQ7bJOckLrI3LOxO5npBynPWZnq4nk8zZCVnTOf5hzvU
B4RlLfTbZdW2TTth3lurZSV7H+C9IFVBv0fdsVygPsJ4SjefaLA5LvJQFQw1
6lN6gp2HwKeE2IraFiswtSW+qC3mcpTeCqZkTEKqdVxs9+l/992E0JzMmslT
OYEh8YPzCe+rhAuErR/knyKH3JeVFyanfa6th46opUGngTnVLHtX6kplkgGh
yLmnpUi2leRG37Q1iLFaVtM/o1z4+++e34YwoVr23TxFWVJ+/o95Hsg5+XI5
CgUqlkrctBhQiq8mX7wU7u3xa6ZwX3kr+R1uoRbbQ0X/sftsLAxsn8ZGxMit
cdmGxErq01R1QEOipvVWdqsuKiGdB8BoKHNdnR4E054m/FkdLmwrDG8Hc9fa
4OLTjdXDuYIcyt4G+d/49ubiu9ernb4QFibEcEegUsKl9uDAl/jCM7dbOT54
9N+/jkgrGsL9ZFZ33WzStSuA/Sb2jajVHQUJx66X6Ea9TtmyJcKlPQLU2JU3
q8NWPVrehUxkzzNay+3YDONcD+8NgYu0j+9+oLo5DiTuhbNlN7dzJMf8Yxmd
PvbH0Db/h0vFkcaxLbN20yJoE3rQq0m55fnsKXd22xxw1OQQmOR10R+AIpOY
9hxVE7qWNWdsiIZVaAWrYFFeO2R+3f/fiV95mmeWRfPH6ET9OLuJs8YNKPCv
N3c3m7sUxcgUkS0Azi+IpGPOiywUuBNVcDCK86rsUb298wBIX2OYzkdBm41V
On2gWj6Ubz5+GA3GMK6CWyJT3WCnOSqnDeL22HNRtUfviEdfgFemhRG9P3rx
wN9s9ScvTywLAlYORiuPQ/wvSbeNIdZ/A9WKbiTc+JfS0uet/vu8H6r6opHS
sxkaA1WdGgSDsZfrvEYQPZTGd4ca6vVWgpqNrmlTO4zWe7zFsRGs0thTtjvQ
Yubgvb17zh7Ug4jmwMsl55Pc0/Xus0UiEQ32nQA1W2ej6GvvR0+ymdeiOHM3
E6eXXAYG/gNOPzSvcz8M+uXMXzgyeySdo+gTnuVmPl2YQ+vN6TGEozvXw2k1
dXDNRgb3hbwAKgCDJ8U6S28meLq8Wal3Q94qlOjn/8vNyBY4LTc05nvOMyt7
DiGapPb5wLWnefFVLFtILNFm2hmSQ3plHJN6lpZwhFJRfXMWx9f1pinea2NB
bJ44YjFMNjMr9ICu5ApLFdWl30ZD55WmDWg+FrVcAyktVIdlmVW/8TcB2dL2
MeFv+hO8oYsm96Yh3thfwJm2e6rpdQjZXWkjSEuJEYit8/dtNRPSjP8YOOMP
U5Wsz1o6kI38xC52GQ8Y3WNnHA1gHTH+SYDx5X88yMuBgiFpW11lmXmovJRy
ys78QEu1V2DciMX6gPcvla2p13mq5X4LNkbpMRqffdA31Af/VKo3yA9zAxSf
EN6UhY68+i56ZAepBza/a5BoKGxsMK3a6QaN8ORKvurPB2hT7b8ecNuDjm8w
pITdNzhgsWQskaASltyYRcfKfoVEtTRABKj0p4az6NUYtguITHB8zkAZu0a1
D9aQq+9y7bfaglEG33aBDhwPZayxOtbZwkyZvI45RXaAFOOsVo18hGmm/8GC
zl4KbTY8PRV1QzharyUOCTWlom636iH6NJE3EcbSkQXEbST1FkQML7Mm3T+1
mH1d21S9lbxBq3uIi5DAzwyyiUG/njyX64leIlA65IKuKQpjI8zAM2xoQy9D
aN1k5WOzeCzT2aXwFvQntSahrqr7qrxik/hw27KqH9V3560d5R7LxWHSb9mb
BM6g6d2ZAzPdc8ixbkt1CSLFJ0sFCrmE+fn6DFGw4WPMd48354XpAcgWIwzO
wnWM9MfEHV5WxsvqMe0QVNQGbGliXHiB413x2I9xZBh2yG49TBUWRuqtSDUq
6IA4yBmVTLlRb7cRkbrMOKh1QVda0PAqzF8drqfZ26LSFWzyEJsGeHcTr2bd
wotemXY+FLtGyAf9yb4rHY7e5Yp8ppbn22wHo3SKwBUIm6C2Cakr3Xt2EFsK
YVw3hXnTRY5BvMnSzLC7MI02RuXdWID5WiRVTru5HCxin5Xq0SdO+vgqQsOr
Xg7ym8S31IMFNSE+PAcnA06aa5nY0B8zFdy4GtUOjVS1SUJ+81xP2ya/lpWa
NqkB0/wRG97jjgbGNTUXa4H+loeWywJfaWiCz0xbfepBuU0yckTeJpoOR1vD
h6iP0WucDCjcEfv6yjm67g1fHR2eHv36V29AIOTeuoJ7dZQ0MAb2OR/nzMsZ
zoO5h7qUD+mAgagDWEz94YWHTMW7TatTwmyz6HhMscE1EaERxYDIVSxRAYAh
Ik2SiybAQYZxWScfZA+N7wUg0YbV3jIMgBJ05VDzZ2/dBr50v+VNHEISY57D
6E5U9K+Y4znO4uwupeowuMtSh0GM3ui3ESaufnO3mwpPxed4ANSZzDLPP4Gz
hjrVfpzpNwZUl+ZDUywsUyupEXYs+CsElLNtiMWEmohJ4xxHxwQaH5sD2Fte
XjBHddRIps7wllPRKk14iCvBMlUET+3D34T7wT68/vjbyNNCq5bNajM1Djlh
YuEF6Vorpw2e4Ez+L+YrDDDgfcahARl6/VmIC2zBskZvzs8uzkK/eO553zxC
75qcDhPo59oOtEEw+IAHajg3BRZJVSTFF49V57UYbnfELkcpu0y0y3GecXBn
ty7D+CogjnYQWOnylZqgdr8rxY+YeSOwRVfSWkRLBaV4lIxmsOR3fx0m667Y
XE4PWi3LVMVb6ryoWABgFMTcMk+uJ6T17Bi2fG/Ra1GtgvyRq1b/QdLGS/sg
cNxRI2ItsqzQ4bNWoZhoVKmQ7g9D68crlXmU31ZMbGDTXE6poZGZunjpxGyZ
uUwhFppWBhctJ1Qsqeiiu8bds+ZGKRm/OPpP+dCbSYj2w7IZvHPObk2H7Dza
rSdcm1NbR2NzKvjlRt1KuaXO05XzzaskVJ7OLKq9jBbl40MRQGRaWv/UA7x+
Fdh9eX9f6riyRRgDRzQoIGAPFVp0qWJuhQ0hDU/24PvEabsemXdzgH1Bec1p
rl6S2pteTsSy2KY/3bx3qwp9P1HDARZWTKcb2q578Sa09sDQ7uD91uA4O4J4
s9do2LhKoQNF9q8aO7PrMCuI/oFx5JyTK4Iz0UPKL+H6ub1+fOllb6/eIm6U
WRpLEwdnQ3H1dS8v8+vb62jCV7GxvtXBWEgkhGKroDYiXqg5SpxTEkk4XBXM
iwetlLckwhBG1ZCyXPTlOlSlWYyUVL8Rw9kjkRg1q70ZEBAsH0NjYL2baVIX
/9FSDwgjWm+PQlHDj7dXl6O8RDyMNUALnRUnuzzOl105Fa5f9s3Pv//+dHZz
fXX+4fP5fwuNNwafRM7N87MlutbIj/sSU7tBAeNxFfi1XEXatzlwyH4+T9br
I92PzHf6BuO5UWa42x1zDeqHxlINWCxpptxvN2doH4OQyNKG46hHB21imsvR
D3w88KkFbREZQmznbu3R0dg8y85YDzxhFxIG0MyjJfpSWywmd8unB9WSJxt4
8GJlrzug2DuSvkPvymReIG21sbRX4jp2YvJ5MjPBW9dmW/URIimmc/jTmM6g
jIVTZbwm/++/Lz+eweIISO5WIvKP0lZkyV6yyD52d0WhpH6rm4vPHKhAswlQ
OulB6c+SI8k79/Vh2rX8+4dQGie+/wRMTEoOLnJtqOolm+o8mTwKl9cZAjRg
g5O5h2AhBs+fiBS494TG0KTImx4ABEQUVqRWK+LLlmuKkFH/HECMmtq/fyKw
04EwWo5VeVcVRPQw8vjj1c9eLWBWahJVDbIp+usw/Vvza6nrO+eOKQoeFt1B
c6EBbIr17gr1pPvp8VGu3U9feU1rSZnGbnvjLCREu9tGsxKL/RXTciZPy/ei
XUUm7IXMjXvTwYrWoFThHmFM/TC2pnYLNivMfWgsVutEuylzZULyY+LedGjS
LO/3n+FlhbMMu2ZRomyk8GMA1Q53ewZmQ9yZ5uQGB3pI1cR0Xw4TcvFyyGbR
nJKpj1dr786QD1haQJNGLBIrp4q62DjoTtBvbaet96pxh2XDqU2WE8MMlKMX
37+PODuDTvdFUXWlcacImUnRTueIAXjqV6ZJO+zup4iMJ8Rc0p5n7PsNdZsp
ZaKjMSvAsG2qFfB12JH7En5/z2g6ELYtE4ecrt/9AFXzXxChxJV5h7MXJwzM
D75s9d/Z5eYDTTOxnpneM+b07Zs3FGlbTu6w9jgf0BmoJHLv77c07zXNt/lz
RzU2TPYxRoTY/g6emO9p53N1dXaaPSUEqAfIksNfWN1FF1HRTqmtAUSRyS/h
/Op9Cv0DHbqFErR8xQL3FcaLsnBdEEG0Q3ekjINJVH5Du17bh70iKJ6aTLLj
nt8ZCk70GmtcOGM3vnEYHTVD74eZfZmf+QYNkS3PTbZwFsqOF88cZ5jcg9Je
T3Xvdi0210y34DXQ3BaIiQc0g+BAAm9gxGLTkMcZvMPRmZlwJc+moyMVnEip
hlTlGoeZ40wMcUVvEPqsEPHDscaJgE0BTCbpSmJ00DkXTDrIikp/3VzmbEi7
qJwDosAV/vQu6XsAhbF9LCtkLyGNRLbQ2jF0TFQ8Z8wL2JOHS4FsKYx4tc9Z
EwldWcIpUVeYIEY0tw1QdSv8apOh9vXoTNILQz5hFnoMuE3NdPBGruJQtOVZ
89T12lf3bUv7jZdOignHnu07XXhtvo4YMgsWmeBwPqry6jptJZFGmHYESTBO
ElEMAoRYhAz+dHt1+z8n8g/vBPP2BRuahu5ImQYpTJ7oSA20SKorERf5b79d
XZie6PyIBF75qCHLXIrVFJnWNaupGJuy+q/GiccMR1Ytqaay7kdWz10YlmcF
NVue4yI8hyXcfPioHMQx3Bp6UkfAIWJrS9fUlSm/PD2ywFIGaUoQy2/GDO5y
Mcw4Ruw91NonKqw2hoo/6/4P7jvCXkOW9u+by083n7/gY335i5dsM8oxFtrA
iXZHVizNTUszu34ItliPy6NjYykwu7o8d3UkgCDbcfTsdgF2BhKMRMWb68+/
X36ZXN7+evnl0+Vtgj8vTk+QcYrXUobgEmOMaXd5h/xvNXldu1kxEdlu4kb5
SJcPf7u+GfG/9V2aOHB8qu3hgp261eBNHZdOpTbsWHHDdtfNN2vMbuKQV2do
aMBhg2gAMmiFRbWgM8hdK7+xr0c/tdpy1x0Zw2CrQ6qFxO6D7KZaVgsS1jhy
YLES76nrqMb80XR8l3441c/2sojAjpuvXr9GehJVDJEf9pvEK+z7jBfPIcL2
Ek8pUgLZc//GLyhF+1zj5vbs9jK5+5cnp29Cr1D4Zd24YODOQ8fFQhv9qu1j
vCKG/oJoCtThgh0h3JDcuWsAUnQkL+mJ4qHOLx7AZce8qLtnBM/nzTr8Kx8w
FDnQ0dkHITksVLAjMUg7c32zQFpIVAFcsug+sUG8PVbjWBisqJj7F4Jnhpls
QJf1q0C7XudBR89CY/AP1ozRdxA6jRg7ylRTiNHGGLz1MH6QtoYIipd9ne5c
1TNFAmeMx9TaFfmQSHX56fLL+/85+fzzf708v52cf/50e/k/yCAIhauzT2cT
e+TL5Yez26vPn5QD3jXrpEkd8/yAQgO3ToywVIGMaqOpjCnPi+wmTRxyNS1z
rcygPuCYvS0lnMc64ASbXvvHfpJtLfob/E2lSart4oXgmQzyKtSXIhDfH33d
k310Cw4+QFJ+YJVtnAoRGrhhtNTF9SgLPgmvcqERrzOdk4kK8uyEN3F5wdsw
lRouGznoL9oXa/wjE8gskR+0uR6ktp7PmlbXWJJoQZRS5wJe2x4qtTZsQOEU
PlZa04IAyKgit65Ua+96EFtSQRRy9LxxukTpgkOUA9E2i9khnoGkztiNNWlr
nrK75FKiowCuh0ermtwx5+nAM5XB2/4mmVdpVxLv49LruUonjZkhdMnG5t/X
ZyJWMTeMf3z3ecovDnUoB61dS50PPrzD4L/D4ZP0Ly+wHWe9MmKNxqdjDber
FWUjVzfXozAGEiMJs8EqnnjglrX1ttVBvsjn32HPYZRkWz7oUMFsqM0F7if+
0SgKWNrx1gnH1JSZV756DhnYTdLIG3Gc0OTCTcA76+hDG+YbLYchE/S8zBGt
o+kvGoW1gkB3rVwJGAFhsU0OQw6CuvaCgeCkluGFgj/YubZJoZ5YTnUqSSIm
mtazA2mQ2DZ3U/TSQ/gIqlwDK2yIHntSq7Y22Y9O73CxKP/oUy7cMn+hL+IE
Q9jW+2pEMpsCVW8NE/NGASsrmRfKpVfJtkEcCf3j8cCt9eq4rB8EIgThu/xL
Tw09MyvNLfIrlneEftS6U869lM1CMfbSRuZHPJdMnjSAvPT6FeGMdTFp1w9P
D5OymK6QCPytRBs9RlEsos+uMObOMocvCtqSssM0Q92bMnsgHO42MwMszsG6
0ogNCa6wGLWXgBBSsASwPsN5xlZqkB1D9PO24NzILR/L7fXAmYY9vQIjdvW1
lwZdN6e1KjovooVkfMY3MzsYkmgY+tA2Mj6fzIhh6KWzI7E8YMYhmThCJhRl
gtNnLkpibn50QvxTUqf+NKb1/+E/FXz0/keO9+rfj/nhylXT9HANA/78/lpF
kMXxtQYHvtWBly8t/+zaAtVOSg0k10nRmctSfxHTgmdcMri5Okv9FQacNGzP
gtIXu+qCC6XmCjF6ZH3bzUPE/pfasm7WspNGqMZIGiq4iybkqliGTmwbWDAQ
DMeBWIyFRwIZ+98qxMJMuqrzUDVrfz1zBj5z32zgRuvQj2eX41M/DU0hNNcg
VGl6LMTzcWgcxQCFVQ1SO6LMD56wxGuuROM9AUOBoTbXIE27h8wyf8192mt5
h9ck+Z4W+tEjV0uOM63XslvtbhUbiqWZJoHNb2pkAG2ZoZxRH6oqrs+zEIK1
5jQohy2/cYq6T1lO64ExLRjB/UC+9wknCb4xSJgJRQzoOwoZ7VjhPRTBUvOb
i0/5YXSfth4e8SI7QytqzY8lCzAytbo82TDJS3SVhDp3L9GQYUJKfSUI5l/K
q5MXi4LPXJ6YSzSkQjAvC6D0KDQOf0w77MbuEqEJ+wtYnodJQ3bLLu2sTZ6r
BeOk1WRgtxz9x3OGRA1PnUwzfH4wUjyQJIWsEua68UIGVDUmOf0/5Z+B3Sqg
alitFmOEHkIdZyeo23wtlqIwTqZTQajJshKEriYPglvdhFoX3HuiQf1H1ytS
Wu2qpa5/aj/UP60XhrJDk8tZIpfz4RqJwAvkUPT0Rp/Va5aXgOR9HKKVsyfk
8D3+ZzTO1Ox+RKZ998NhkFEQrrSn4H11l7bKQGwr+iMRQVqaoIJqkIdwYIwZ
R8PF/SGhijGW0yFD+htn+e0UIpQxVGeBUDcqN6TWXj8WepnSAWdTdQE26NFb
WgLn9fllHHlK6KStQAwbJoYNpsvthJdCgCapdfOclBt6t4IU6zZ/bb5WE5Ep
3SR186UFLQWZJiktDTdH9VdT57KL8/7ohKCkM8spDZju1HP0Q93qgV+1leV3
BmXenSNhtNm/Popy8dBaMzhc7sV5PsG7aKDAq11kQ/mMW9ANeR+4MsHhqt+a
KPGK6ZgSXWD0wysIJYZKTyw9QtPmUCd1K2K7cy06qA6qaK6qpWoNahT7IBh5
7/D66qPuetRvy+I0qtaSd/pZNFOTMvxu3sBx4fFj9wUNLtHHTnSezhqRXIsq
AWfd+Ucx4QSZADSx7aBI/hIsUw4E+2WU9s3u+lZYUP8CO78LZb8hSV4lYHQ3
UPMFw8Tbe4WrlpndhRFU24qRm0o5Hd5sOWrL6MEhsX0KGlX+8ANXX6OBheZW
9Cet53GWr+4g6eLKzc+0KVJUq5nsbF4hs+STZTyC0SG/R+cLsYkhSwD4VzD5
NNHnfbHqUkPt1vJS99G0G+SOV0+qhFq+SgCV6qaqEIe6ha4XCieArCsXe4l1
W1UTw6Q0JZXqamRop5e0AbMWE0YyUbWRLJrS1v1zGhcsNfeVWt+DAEBdnEga
6TYPKADtoiKGu+LwxfpdPvggVKlzEIEzoVg+CayP3baI8IgpeRdUrKwcausx
UV/SlCqvks1/TnKW8MS8mZmgwgiIGw74s6SYpPIvPZ0pTmaBwcNSYKYW8xP6
6U9Rg82QGM9COzQrXZXUTtIRD/EtwsERiW9WZa1jhZhbHHq2x6HsVl2IFxxe
fYGOyxEpgoQ3xJJneAx+vsiy7P8FCswUmvrdAAA=

-->

</rfc>