draft-eckert-ietf-and-energy-overview-06.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.7.1 (Ruby 3.1.3) -->


<!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-06" category="info" submissionType="independent" tocDepth="5" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="IETF Energy Overview">An Overview of Energy-related Effort within the IETF</title>

    <author initials="T." surname="Eckert" fullname="Toerless Eckert" role="editor">
      <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>
    <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" role="editor">
      <organization>Orange</organization>
      <address>
        <postal>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author initials="P." surname="Thubert" fullname="Pascal Thubert">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>45 Allee des Ormes - BP1200, Building D</street>
          <city>Sophia Antipolis</city>
          <code>06254 MOUGINS</code>
          <country>France</country>
        </postal>
        <phone>+33 497 23 26 34</phone>
        <email>pthubert@cisco.com</email>
      </address>
    </author>
    <author initials="J." surname="Tentsura" fullname="Jeff Tentsura">
      <organization>NVIDIA</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
      <organization>NC State University</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>cpignata@gmail.com</email>
      </address>
    </author>

    <date year="2024" month="January" day="06"/>

    
    
    

    <abstract>


<?line 256?>

<t>This memo provides an overview of work performed by or proposed within
the IETF related 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 that work, but 
interested in it, in the hope to raise more interest in energy-related
activities within the IETF, such as identifying gaps and investigating
solutions as appropriate.</t>

<t>This document captures work until 12/2022, at which time the "IAB workshop on Environmental Impact of Internet Applications and Systems" revived interest and triggered new work in the topic within the IETF/IRTF.</t>



    </abstract>



  </front>

  <middle>


<?line 269?>

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

<t>This document summarizes work that has been proposed to or performed 
within the IETF/IRTF. Particularly, it covers IETF/IRTF RFCs as well as
ISE RFCs and IETF/IRTF or individual submission drafts
that where abandoned for various reasons (e.g., lack of momentum, broad scope).</t>

<t>There are various aspects how a given work relates to energy that are
classified into categories.  Such a classification does not attempt to propose
a formal taxonomy, but is used for the sake of better readability.
Technologies are listed under a category that is specifically significant, 
for example, by being most narrow.</t>

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

<t>This document captures work until 12/2022, at which time the "IAB workshop on Environmental Impact of Internet Applications and Systems" <xref target="I-D.iab-ws-environmental-impacts-report"/> revived interest and highlighted the need for some structured activity within the IETF/IRTF.</t>

</section>
<section anchor="energy-saving-an-introduction"><name>Energy Saving: An Introduction</name>

<t>Technologies that simply save energy compared to earlier or other alternatives are the
broadest and most unspecific category. In this memo such an energy saving simply refers
to energy savings in some unit of electricity, such as kWh and does not take other
aspects of energy optimization into account.  See <xref target="sustainability"/> for more details.</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, the 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"/> 
obsoleted by <xref target="RFC2822"/>, <xref target="RFC5322"/>),
group communications utilizing 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"/> superseded by various later version
of HTML, see <xref target="RFC2854"/>).</t>

<t>Conventionally, digitization had only "incidental", but not "intentional" relationship to 
energy consumption: If it saved energy, this was not a target benefit; in fact, it was not
even recognized as one until recently.  Instead, the evolution was driven from anything-but-energy benefits,
but instead utility benefits such as improved speed, functionality/flexibility, accessibility, usability, 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 amongst 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 IP/MPLS 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-iconic-example-telephony"><name>An Iconic 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"/> superseded by <xref target="RFC3261"/> 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"/> superseded by <xref target="RFC2460"/> and <xref target="RFC8200"/>) 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 were the ones who at least during the 1990s 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 embodied through the IETF "Transmission Control Protocol"
(TCP, <xref target="RFC9293"/>). 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="global-vs-restricted-connectivity-the-internet-routing-architectures"><name>Global vs Restricted Connectivity: The Internet Routing Architectures</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.</t>

<t>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 were 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. Such approaches resulted not only in higher cost of those services but also (likely) 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 were 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"/>
<xref target="RFC4346"/>, <xref target="RFC5246"/>, <xref target="RFC8446"/>). This further strengthened the ability to scale service/applications at minimum additional
cost for the underlying packet transport, arguably driving innovation 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
(e.g., real-time vs. non-real-time) which previously used 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) widely adopted technology promising converged networks was  "Asynchronous Transfer Mode" (ATM), 
which was designed and deployed at the end of the 1980s 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 1980s, it was proven in <xref target="BOUNDED_LATENCY"/>
that variable length packet multiplexing in network can also support non-NP-hard calculations for
bounded latency. This led 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 superseded as explained in the following
section - for its original use-cases (voice and video). However, this type of services is 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 INTSERV versus regular (so-called Best-Effort)
Internet traffic, the INTSERV model was already recognized in the 1990s to not support highest-scale at lowest
cost, leading to the parallel development of the IETF "Differentiated 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 workflows 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)-digitized is orders of magnitudes 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 
<xref target="DVDvsStreaming"/>.
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 from ten to thirty 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>Some Notes on 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 (e.g., ore depletion required for building hardware).
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 fossil 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, 
the Internet itself can similarly to how it does for digitization play a key role in building sustainable
networked IT infrastructures. The following subsections list three exemplary 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="optimize-generated-heat"><name>Optimize Generated Heat</name>

<t>The majority of energy in cloud DCs 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, DCs 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 DCs 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 DCs, can be recovered when it is coupled to heating systems
ranging in size all the way from individual family homes through larger buildings (hotels, for example) all the
way to district heating systems. A provider of such a 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 netnews (using e.g., NNTP) as early forms of Telecollaboration,
then telecollaboration history through IETF technology reaches back into the 1980s 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 2000s, 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 reference for hundreds of commercial
and free tele-collaboration solutions, including Cisco Webex, which is also used by the IETF itself, Zoom, and
the collaboration suite the IETF most recently uses, Meetecho <eref target="https://www.meetecho.com/en/"/>.</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 factor 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 fossil 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 airplane if it was exhausted at surface level. One
publicly funded organization offering carbon offset services calculates a factor 3 of the CO2 consumption of an
airplane <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 fossil fuels
in air travel.</t>

</section>
</section>
<section anchor="energy-optimization-in-specific-networks"><name>Energy Optimization in Specific Networks</name>

<section anchor="analysis-of-routing-protocol-inefficiencies"><name>Analysis of Routing Protocol (In)Efficiencies</name>

<t>At the beginning of much of the following IETF efforts was an<br />
     understanding and analysis that prior protocols for routing and<br />
     subnet management where not able to ideally support evolving network 
     and device models: - lower compute performance due to low energy 
     (batteries, energy recovery), bitrates especially on radio links, and<br />
     lower memory footprint.</t>

<t>The two documents from 2008/2009 that capture this analysis/ 
     understanding are <xref target="I-D.levis-roll-overview-protocols"/> and 
     <xref target="I-D.ietf-roll-protocols-survey"/>.  The overall challenges also very<br />
     much related to energy of IPv6 over wireless are captured in 
     <xref target="I-D.thubert-6man-ipv6-over-wireless"/>, which is ongoing work.</t>

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

<t>Low Power and Lossy Networks (LLNs) are networks in which nodes and/or radio links have constraints.
Low power 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 energy at short time
periods, radio energy tuning to just reach the destination(s), minimization of multicasting
to eliminate need of radio receivers to consume energy and so on. <xref target="RFC8352"/> gives a more detailed
overview, especially because different L2 technologies such as IEEE 802.15.4 type (low power)
wireless networks, Bluetooth Low Energy (BLE), WLAN (IEEE 802.11) and DEC ULE.</t>

<t>In the INT 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. Among these, the Problem Statement and Requirements <xref target="RFC6606"/> gives details about the power and energy approaches and goals.</t>

<t>"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>

<t>It is important to understand the 6LOWPAN Overview, Assumptions, Problem Statement, and Goals <xref target="RFC4919"/>, including "conserve energy".</t>

<t>Outside the 6LOWPAN WG, <xref target="RFC9139"/> connects Information-Centric Networking (ICN) to Low-Power Wireless Personal Area Networks (LoWPANs).</t>

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

<t>Since 2014 and before 2023, 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-Track RFC documents, <xref target="RFC8724"/>, <xref target="RFC8824"/>, and <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>

<t>Notably, a key specification produced is <xref target="RFC7668"/>, "IPv6 over BLUETOOTH(R) Low Energy", using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques, as well as the related <xref target="RFC9159"/> for the formation of extended topologies, an IPv6 mesh over Bluetooth LE links.</t>

<t>From a management perspective, produced <xref target="RFC7388"/>, LOWPAN MIB, as well as several specific improvements around power such as <xref target="RFC7973"/>, <xref target="RFC8025"/>, <xref target="RFC8928"/>, <xref target="RFC8931"/>, and <xref target="RFC9034"/>.</t>

<t>Finally, the 6LO WG also produced <xref target="RFC8105"/>, IPv6 over DECT Ultra-Low Energy, and <xref target="RFC9354"/>, IPv6 over Power Line Communication (PLC).</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 focused
on the "IPv6 Routing Protocol for Low-Power and Lossy Networks" (RPL) <xref target="RFC6550"/> <xref target="RFC6551"/> <xref target="RFC6552"/>, 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"/>. 
Further, some RPL RFCs were progressed in the 6MAN WG, such as <xref target="RFC6553"/>, RPL Option for Carrying RPL Information in Data-Plane Datagrams, and <xref target="RFC6554"/>, IPv6 Routing Header for Source Routes with RPL.
<xref target="RFC7416"/> covers a Security Threat Analysis for RPLs, which is also relevant to energy efforts.</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="RFC8138"/> <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"/> superseded by <xref target="ISO10589-Second-Edition"/>)
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, Wi-Fi and cellular mobile network connections are
not considered to be lossy networks, and personal mobile nodes with both connections
are order of magnitude less constrained than nodes typically attached to LLN network.
Therefore, broader work in the IETF than focused primarily on LLN typically uses
just the term lightweight 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>

<t>Further, the LWIG WG produced <xref target="RFC7228"/>, "Terminology for Constrained-Node Networks", which includes important energy and power definitions of terms. These include scaling properties, classes of energy limitation, and strategies for using power for communication.  It also produced <xref target="RFC9006"/>, giving guidance on TCP usage for saving energy.</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 readable 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 ubicuitous
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 anchor="satellite-constellations"><name>Satellite Constellations</name>

<t>Emerging communication infrastructures may have specific requirements on power
consumption. Such requirements should be taken into account when
designing/customizing techniques (e.g., routing) to be enabled in such networks.
For example, <xref target="I-D.lhan-problems-requirements-satellite-net"/> identifies a set
of requirements (including power) for satellite constellations.</t>

</section>
<section anchor="devices-with-batteries"><name>Devices with Batteries</name>

<t>Many IETF protocols (e.g., <xref target="RFC3948"/>) were designed to accommodate the presence
of middleboxes mainly by encouraging clients to issue frequent keepalives.
Such strategy has implication on battery-supplied devices. In order to
optimize battery consumption for such devices, <xref target="RFC6887"/> specifies a deterministic
method so that client can control state in the network, including their lifetime.
Keepalive alive messages may this be optimized as a function of the network policies.</t>

<t>A_REC#2 of <xref target="RFC7849"/> further insist on the importance of saving battery exacerbated
by keep-alive messages and recommends the support of collaborative means to control
state in the network rather than relying on heuristics.</t>

</section>
</section>
<section anchor="sample-technical-enablers"><name>Sample Technical Enablers</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 go through the standardization process 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 somewhat 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 Wi-Fi 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
alternative (with so-called ingress 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>

<t>As an additional pointer, <xref target="RFC7731"/> defined the Multicast Protocol for Low-Power and Lossy Networks (MPL).</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 forwarders as well - compared
to better alternatives.</t>

<t>In 2006, the IETF published "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 in Wireless Networks</name>

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

<t>(a) Unnecessary wake-up of power constrained Wi-Fi 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) Wi-Fi 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 Wi-Fi 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 Wi-Fi multicast to Wi-Fi unicast packets.</t>

<t><xref target="I-D.desmouceaux-ipv6-mcast-wifi-power-usage"/> focuses on IPv6-related concerns of multicast traffic in large  wireless network. This document provides as set of statistics and the induced device power consumption of such flows.</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 Wi-Fi 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 resource consumer.</t>

<t>A 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)", normalized
proxy infrastructures are best built with published 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"/>, later updated by <xref target="RFC8505"/> is 6LO. <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 anchor="lack-of-power-benchmarking-proposals"><name>(Lack of) Power Benchmarking Proposals</name>

<t><xref target="I-D.petrescu-v6ops-ipv6-power-ipv4"/> presented some measurement results of the power
consumption when using IPv6 vs IPv4 with a focus on mobile devices. Such
measurements are not backed with formal benchmarking methodologies so that solid and
reliable references are set to compare and interpret data.</t>

<t><eref target="https://www.ietf.org/proceedings/103/slides/slides-103-saag-iot-benchmarking-00"/>
presented a benchmark example but with a focus on power cost of encryption.</t>

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

<t>The 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 appliances". 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 is 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 above-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"/>): 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="synchro-phasor-networks"><name>Synchro 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>Synchro Phasor Networks are networks whose goal it is to support synchronization 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
sensing 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 hottest or 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 SynchroPhasor Initiative" (NASPI), https://www.naspi.org is an example
organization in support of synchrophasor networking. It is an ongoing project by
the USA "Department of Energy" (DoE).</t>

</section>
</section>
<section anchor="limited-energy-management-for-networks"><name>(Limited) Energy Management for Networks</name>

<section anchor="some-metrics"><name>Some Metrics</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 other 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 publications 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 management 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 Wi-Fi 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"></xref> specifies
a MIB for monitoring for Power State and energy consumption of networked.
The document discusses the link with other MIBs such as
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 "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 power failure based on UPS battery capacity and device consumptions/priorities.
Similarly, the EMAN "Definition of Managed Objects for Battery Monitoring" <xref target="RFC7577"/>
defines objects to support battery monitoring in managed devices. 
It is important to note that, outside the EMAN WG and as an Independent Submission, <xref target="RFC9271"/> specifies "Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses".</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 of 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.
Such intended applicability includes home, core, and DC networks.</t>

<t>There are currently no YANG equivalent modules. Such modules would not only
be designed to echo the EMAN MIBs but would also allow to control dedicated
 power optimization engines instead of relying upon static and frozen vendor-specific optimization.</t>

</section>
</section>
<section anchor="power-awareness-in-forwarding-and-routing-protocols"><name>Power-Awareness in Forwarding and Routing Protocols</name>

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

<t>In 2013/2014, some drafts proposed how networks themselves,
specifically those of Internet Service Providers (ISP) could dynamically
regulate their power consumption based on the required performance, for
example by switching off or low-powering non-needed components
(links, nodes, linecards) or changing speeds on links, or reducing clock-rates
of processing elements, and/or routing traffic to utilize as few components
as will support the required performance. The authors called this "Power Aware Networks" (PANET),
 even though no awareness of actual power consumption is required in this approach.</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 down-speeding, 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="sdn-based-semantic-forwarding"><name>SDN-based Semantic Forwarding</name>

<t>Recently, <xref target="I-D.boucadair-irtf-sdn-and-semantic-routing"/> provided the following
feature as an example of capabilities that can be offered by appropriate control
of forwarding elements:</t>

<t>Energy-efficient Forwarding:  An important effort was made in the
past to optimize the energy consumption of network elements.
However, such optimization is node-specific and no standardized means
to optimize the energy consumption at the scale of the network
have been defined.  For example, many nodes (also, service cards)
are deployed as backups.</t>

<t>A controller-based approach can be implemented so that the route
selection process optimizes the overall energy consumption of a
path.  Such a process takes into account the current load, avoids
waking nodes/cards for handling "sparse" traffic (i.e., a minor
portion of the total traffic), considers node-specific data (e.g.,
<xref target="RFC7460"/>), etc.  This off-line Semantic Routing approach will
transition specific cards/nodes to "idle" and wake them as
appropriate, etc., without breaking service objectives.  Moreover,
such an approach will have to maintain an up-to-date topology even
if a node is in an "idle" state (such nodes may be removed from
adjacency tables if they don't participate in routing
advertisements).</t>

</section>
<section anchor="miscelaneous"><name>Miscelaneous</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.: various L2 technologies such as switched optical fiber networks. It primarily
claims the issue that the existing management objects are not sufficient to
express energy management 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 ingress and egress linecards).</t>

</section>
</section>
<section anchor="gap-analysis"><name>Gap Analysis</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="acknowledgments"><name>Acknowledgments</name>

<t>Thanks for Fred Baker for his review and suggestions.</t>

</section>
<section anchor="changelog"><name>Changelog</name>

<t>[RFC-Editor: this section to be removed in final document.]</t>

<t>The master for this document is hosted at <eref target="http://github.com/toerless/energy"/>. Please
submit Issues and/or Pull-requests for proposed changes or join the team of authors and edit yourself.</t>

<t>00: Initial version</t>

<t>01: Added Co-author  (Mohamed Boucadair) - long list of typo fixes, editorial improvements in abstract, introduction and other chapters. Added section on satellite networks, devices with batteries, power benchmarking and SDN-based forwarding semantics.</t>

<t>02: Minor text edits (med), add pointer to additional draft (med), Added co-author pascal (tte),</t>

<t>03: Added Jeff Tentsura as co-author</t>

<t>04: Various textual fixups, added new versions of RFC for references using obsoleted RFCs, so that both original and latest are referenced.</t>

<t>05: Added pointers on analysis and limit scope of document to 12/2022.</t>

<t>06: Full review and throughout addition of references and context on energy and power-related IETF work, full editorial pass. New co-author.</t>

</section>


  </middle>

  <back>



    <references title='Informative References' anchor="sec-informative-references">



<reference anchor="RFC768">
  <front>
    <title>User Datagram Protocol</title>
    <author fullname="J. Postel" initials="J." surname="Postel"/>
    <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">
  <front>
    <title>Internet Protocol</title>
    <author fullname="J. Postel" initials="J." surname="Postel"/>
    <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">
  <front>
    <title>Transmission Control Protocol</title>
    <author fullname="J. Postel" initials="J." surname="Postel"/>
    <date month="September" year="1981"/>
  </front>
  <seriesInfo name="RFC" value="793"/>
  <seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference>

<reference anchor="RFC822">
  <front>
    <title>STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES</title>
    <author fullname="D. Crocker" initials="D." surname="Crocker"/>
    <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">
  <front>
    <title>Host extensions for IP multicasting</title>
    <author fullname="S.E. Deering" initials="S.E." surname="Deering"/>
    <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">
  <front>
    <title>OSI IS-IS Intra-domain Routing Protocol</title>
    <author fullname="D. Oran" initials="D." role="editor" surname="Oran"/>
    <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">
  <front>
    <title>UPS Management Information Base</title>
    <author fullname="J. Case" initials="J." role="editor" surname="Case"/>
    <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">
  <front>
    <title>Hypertext Markup Language - 2.0</title>
    <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
    <author fullname="D. Connolly" initials="D." surname="Connolly"/>
    <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">
  <front>
    <title>Internet Protocol, Version 6 (IPv6) Specification</title>
    <author fullname="S. Deering" initials="S." surname="Deering"/>
    <author fullname="R. Hinden" initials="R." surname="Hinden"/>
    <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">
  <front>
    <title>IMAP4 ACL extension</title>
    <author fullname="J. Myers" initials="J." surname="Myers"/>
    <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">
  <front>
    <title>Specification of Guaranteed Quality of Service</title>
    <author fullname="S. Shenker" initials="S." surname="Shenker"/>
    <author fullname="C. Partridge" initials="C." surname="Partridge"/>
    <author fullname="R. Guerin" initials="R." surname="Guerin"/>
    <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">
  <front>
    <title>The TLS Protocol Version 1.0</title>
    <author fullname="T. Dierks" initials="T." surname="Dierks"/>
    <author fullname="C. Allen" initials="C." surname="Allen"/>
    <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">
  <front>
    <title>OSPF Version 2</title>
    <author fullname="J. Moy" initials="J." surname="Moy"/>
    <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="RFC2460">
  <front>
    <title>Internet Protocol, Version 6 (IPv6) Specification</title>
    <author fullname="S. Deering" initials="S." surname="Deering"/>
    <author fullname="R. Hinden" initials="R." surname="Hinden"/>
    <date month="December" year="1998"/>
    <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="2460"/>
  <seriesInfo name="DOI" value="10.17487/RFC2460"/>
</reference>

<reference anchor="RFC2475">
  <front>
    <title>An Architecture for Differentiated Services</title>
    <author fullname="S. Blake" initials="S." surname="Blake"/>
    <author fullname="D. Black" initials="D." surname="Black"/>
    <author fullname="M. Carlson" initials="M." surname="Carlson"/>
    <author fullname="E. Davies" initials="E." surname="Davies"/>
    <author fullname="Z. Wang" initials="Z." surname="Wang"/>
    <author fullname="W. Weiss" initials="W." surname="Weiss"/>
    <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">
  <front>
    <title>SIP: Session Initiation Protocol</title>
    <author fullname="M. Handley" initials="M." surname="Handley"/>
    <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
    <author fullname="E. Schooler" initials="E." surname="Schooler"/>
    <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
    <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="RFC2822">
  <front>
    <title>Internet Message Format</title>
    <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/>
    <date month="April" year="2001"/>
    <abstract>
      <t>This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2822"/>
  <seriesInfo name="DOI" value="10.17487/RFC2822"/>
</reference>

<reference anchor="RFC2854">
  <front>
    <title>The 'text/html' Media Type</title>
    <author fullname="D. Connolly" initials="D." surname="Connolly"/>
    <author fullname="L. Masinter" initials="L." surname="Masinter"/>
    <date month="June" year="2000"/>
    <abstract>
      <t>This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2854"/>
  <seriesInfo name="DOI" value="10.17487/RFC2854"/>
</reference>

<reference anchor="RFC3261">
  <front>
    <title>SIP: Session Initiation Protocol</title>
    <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
    <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
    <author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
    <author fullname="A. Johnston" initials="A." surname="Johnston"/>
    <author fullname="J. Peterson" initials="J." surname="Peterson"/>
    <author fullname="R. Sparks" initials="R." surname="Sparks"/>
    <author fullname="M. Handley" initials="M." surname="Handley"/>
    <author fullname="E. Schooler" initials="E." surname="Schooler"/>
    <date month="June" year="2002"/>
    <abstract>
      <t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3261"/>
  <seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>

<reference anchor="RFC3433">
  <front>
    <title>Entity Sensor Management Information Base</title>
    <author fullname="A. Bierman" initials="A." surname="Bierman"/>
    <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
    <author fullname="K.C. Norseth" initials="K.C." surname="Norseth"/>
    <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">
  <front>
    <title>RTP: A Transport Protocol for Real-Time Applications</title>
    <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
    <author fullname="S. Casner" initials="S." surname="Casner"/>
    <author fullname="R. Frederick" initials="R." surname="Frederick"/>
    <author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
    <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">
  <front>
    <title>Power Ethernet MIB</title>
    <author fullname="A. Berger" initials="A." surname="Berger"/>
    <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
    <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="RFC3948">
  <front>
    <title>UDP Encapsulation of IPsec ESP Packets</title>
    <author fullname="A. Huttunen" initials="A." surname="Huttunen"/>
    <author fullname="B. Swander" initials="B." surname="Swander"/>
    <author fullname="V. Volpe" initials="V." surname="Volpe"/>
    <author fullname="L. DiBurro" initials="L." surname="DiBurro"/>
    <author fullname="M. Stenberg" initials="M." surname="Stenberg"/>
    <date month="January" year="2005"/>
    <abstract>
      <t>This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3948"/>
  <seriesInfo name="DOI" value="10.17487/RFC3948"/>
</reference>

<reference anchor="RFC3977">
  <front>
    <title>Network News Transfer Protocol (NNTP)</title>
    <author fullname="C. Feather" initials="C." surname="Feather"/>
    <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">
  <front>
    <title>Entity State MIB</title>
    <author fullname="S. Chisholm" initials="S." surname="Chisholm"/>
    <author fullname="D. Perkins" initials="D." surname="Perkins"/>
    <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">
  <front>
    <title>A Border Gateway Protocol 4 (BGP-4)</title>
    <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
    <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
    <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
    <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 "class" 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="RFC4346">
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.1</title>
    <author fullname="T. Dierks" initials="T." surname="Dierks"/>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
    <date month="April" year="2006"/>
    <abstract>
      <t>This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security 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="4346"/>
  <seriesInfo name="DOI" value="10.17487/RFC4346"/>
</reference>

<reference anchor="RFC4607">
  <front>
    <title>Source-Specific Multicast for IP</title>
    <author fullname="H. Holbrook" initials="H." surname="Holbrook"/>
    <author fullname="B. Cain" initials="B." surname="Cain"/>
    <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">
  <front>
    <title>Neighbor Discovery for IP version 6 (IPv6)</title>
    <author fullname="T. Narten" initials="T." surname="Narten"/>
    <author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
    <author fullname="W. Simpson" initials="W." surname="Simpson"/>
    <author fullname="H. Soliman" initials="H." surname="Soliman"/>
    <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">
  <front>
    <title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
    <author fullname="G. Montenegro" initials="G." surname="Montenegro"/>
    <author fullname="N. Kushalnagar" initials="N." surname="Kushalnagar"/>
    <author fullname="J. Hui" initials="J." surname="Hui"/>
    <author fullname="D. Culler" initials="D." surname="Culler"/>
    <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">
  <front>
    <title>Internet Security Glossary, Version 2</title>
    <author fullname="R. Shirey" initials="R." surname="Shirey"/>
    <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="RFC5246">
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
    <author fullname="T. Dierks" initials="T." surname="Dierks"/>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
    <date month="August" year="2008"/>
    <abstract>
      <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5246"/>
  <seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>

<reference anchor="RFC5322">
  <front>
    <title>Internet Message Format</title>
    <author fullname="P. Resnick" initials="P." role="editor" surname="Resnick"/>
    <date month="October" year="2008"/>
    <abstract>
      <t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5322"/>
  <seriesInfo name="DOI" value="10.17487/RFC5322"/>
</reference>

<reference anchor="RFC5548">
  <front>
    <title>Routing Requirements for Urban Low-Power and Lossy Networks</title>
    <author fullname="M. Dohler" initials="M." role="editor" surname="Dohler"/>
    <author fullname="T. Watteyne" initials="T." role="editor" surname="Watteyne"/>
    <author fullname="T. Winter" initials="T." role="editor" surname="Winter"/>
    <author fullname="D. Barthel" initials="D." role="editor" surname="Barthel"/>
    <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">
  <front>
    <title>Industrial Routing Requirements in Low-Power and Lossy Networks</title>
    <author fullname="K. Pister" initials="K." role="editor" surname="Pister"/>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <author fullname="S. Dwars" initials="S." surname="Dwars"/>
    <author fullname="T. Phinney" initials="T." surname="Phinney"/>
    <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">
  <front>
    <title>Home Automation Routing Requirements in Low-Power and Lossy Networks</title>
    <author fullname="A. Brandt" initials="A." surname="Brandt"/>
    <author fullname="J. Buron" initials="J." surname="Buron"/>
    <author fullname="G. Porcu" initials="G." surname="Porcu"/>
    <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">
  <front>
    <title>Building Automation Routing Requirements in Low-Power and Lossy Networks</title>
    <author fullname="J. Martocci" initials="J." role="editor" surname="Martocci"/>
    <author fullname="P. De Mil" initials="P." surname="De Mil"/>
    <author fullname="N. Riou" initials="N." surname="Riou"/>
    <author fullname="W. Vermeylen" initials="W." surname="Vermeylen"/>
    <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">
  <front>
    <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
    <author fullname="D. Mills" initials="D." surname="Mills"/>
    <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
    <author fullname="J. Burbank" initials="J." surname="Burbank"/>
    <author fullname="W. Kasch" initials="W." surname="Kasch"/>
    <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">
  <front>
    <title>The Trickle Algorithm</title>
    <author fullname="P. Levis" initials="P." surname="Levis"/>
    <author fullname="T. Clausen" initials="T." surname="Clausen"/>
    <author fullname="J. Hui" initials="J." surname="Hui"/>
    <author fullname="O. Gnawali" initials="O." surname="Gnawali"/>
    <author fullname="J. Ko" initials="J." surname="Ko"/>
    <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">
  <front>
    <title>Internet Protocols for the Smart Grid</title>
    <author fullname="F. Baker" initials="F." surname="Baker"/>
    <author fullname="D. Meyer" initials="D." surname="Meyer"/>
    <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">
  <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"/>
    <author fullname="P. Thubert" initials="P." surname="Thubert"/>
    <date month="September" year="2011"/>
    <abstract>
      <t>This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". 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">
  <front>
    <title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
    <author fullname="T. Winter" initials="T." role="editor" surname="Winter"/>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <author fullname="A. Brandt" initials="A." surname="Brandt"/>
    <author fullname="J. Hui" initials="J." surname="Hui"/>
    <author fullname="R. Kelsey" initials="R." surname="Kelsey"/>
    <author fullname="P. Levis" initials="P." surname="Levis"/>
    <author fullname="K. Pister" initials="K." surname="Pister"/>
    <author fullname="R. Struik" initials="R." surname="Struik"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <author fullname="R. Alexander" initials="R." surname="Alexander"/>
    <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">
  <front>
    <title>Constrained RESTful Environments (CoRE) Link Format</title>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <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. "RESTful" 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">
  <front>
    <title>DNS-Based Service Discovery</title>
    <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
    <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
    <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">
  <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"/>
    <author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti"/>
    <author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <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="RFC6887">
  <front>
    <title>Port Control Protocol (PCP)</title>
    <author fullname="D. Wing" initials="D." role="editor" surname="Wing"/>
    <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
    <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
    <author fullname="R. Penno" initials="R." surname="Penno"/>
    <author fullname="P. Selkirk" initials="P." surname="Selkirk"/>
    <date month="April" year="2013"/>
    <abstract>
      <t>The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6887"/>
  <seriesInfo name="DOI" value="10.17487/RFC6887"/>
</reference>

<reference anchor="RFC6933">
  <front>
    <title>Entity MIB (Version 4)</title>
    <author fullname="A. Bierman" initials="A." surname="Bierman"/>
    <author fullname="D. Romascanu" initials="D." surname="Romascanu"/>
    <author fullname="J. Quittek" initials="J." surname="Quittek"/>
    <author fullname="M. Chandramouli" initials="M." surname="Chandramouli"/>
    <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">
  <front>
    <title>Requirements for Energy Management</title>
    <author fullname="J. Quittek" initials="J." role="editor" surname="Quittek"/>
    <author fullname="M. Chandramouli" initials="M." surname="Chandramouli"/>
    <author fullname="R. Winter" initials="R." surname="Winter"/>
    <author fullname="T. Dietz" initials="T." surname="Dietz"/>
    <author fullname="B. Claise" initials="B." surname="Claise"/>
    <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">
  <front>
    <title>Enrollment over Secure Transport</title>
    <author fullname="M. Pritikin" initials="M." role="editor" surname="Pritikin"/>
    <author fullname="P. Yee" initials="P." role="editor" surname="Yee"/>
    <author fullname="D. Harkins" initials="D." role="editor" surname="Harkins"/>
    <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">
  <front>
    <title>Terms Used in Routing for Low-Power and Lossy Networks</title>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <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">
  <front>
    <title>Energy Management Framework</title>
    <author fullname="J. Parello" initials="J." surname="Parello"/>
    <author fullname="B. Claise" initials="B." surname="Claise"/>
    <author fullname="B. Schoening" initials="B." surname="Schoening"/>
    <author fullname="J. Quittek" initials="J." surname="Quittek"/>
    <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">
  <front>
    <title>Monitoring and Control MIB for Power and Energy</title>
    <author fullname="M. Chandramouli" initials="M." surname="Chandramouli"/>
    <author fullname="B. Claise" initials="B." surname="Claise"/>
    <author fullname="B. Schoening" initials="B." surname="Schoening"/>
    <author fullname="J. Quittek" initials="J." surname="Quittek"/>
    <author fullname="T. Dietz" initials="T." surname="Dietz"/>
    <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">
  <front>
    <title>Energy Object Context MIB</title>
    <author fullname="J. Parello" initials="J." surname="Parello"/>
    <author fullname="B. Claise" initials="B." surname="Claise"/>
    <author fullname="M. Chandramouli" initials="M." surname="Chandramouli"/>
    <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">
  <front>
    <title>Definition of Managed Objects for Battery Monitoring</title>
    <author fullname="J. Quittek" initials="J." surname="Quittek"/>
    <author fullname="R. Winter" initials="R." surname="Winter"/>
    <author fullname="T. Dietz" initials="T." surname="Dietz"/>
    <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">
  <front>
    <title>Energy Management (EMAN) Applicability Statement</title>
    <author fullname="B. Schoening" initials="B." surname="Schoening"/>
    <author fullname="M. Chandramouli" initials="M." surname="Chandramouli"/>
    <author fullname="B. Nordman" initials="B." surname="Nordman"/>
    <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">
  <front>
    <title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
    <author fullname="K. Hartke" initials="K." surname="Hartke"/>
    <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 "observe" 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">
  <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"/>
    <author fullname="E. Baccelli" initials="E." surname="Baccelli"/>
    <author fullname="R. Cragie" initials="R." surname="Cragie"/>
    <author fullname="P. van der Stok" initials="P." surname="van der Stok"/>
    <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">
  <front>
    <title>Reducing Energy Consumption of Router Advertisements</title>
    <author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko"/>
    <author fullname="L. Colitti" initials="L." surname="Colitti"/>
    <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="RFC7849">
  <front>
    <title>An IPv6 Profile for 3GPP Mobile Devices</title>
    <author fullname="D. Binet" initials="D." surname="Binet"/>
    <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
    <author fullname="A. Vizdal" initials="A." surname="Vizdal"/>
    <author fullname="G. Chen" initials="G." surname="Chen"/>
    <author fullname="N. Heatley" initials="N." surname="Heatley"/>
    <author fullname="R. Chandler" initials="R." surname="Chandler"/>
    <author fullname="D. Michaud" initials="D." surname="Michaud"/>
    <author fullname="D. Lopez" initials="D." surname="Lopez"/>
    <author fullname="W. Haeffner" initials="W." surname="Haeffner"/>
    <date month="May" year="2016"/>
    <abstract>
      <t>This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" (RFC 7066).</t>
      <t>Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7849"/>
  <seriesInfo name="DOI" value="10.17487/RFC7849"/>
</reference>

<reference anchor="RFC8200">
  <front>
    <title>Internet Protocol, Version 6 (IPv6) Specification</title>
    <author fullname="S. Deering" initials="S." surname="Deering"/>
    <author fullname="R. Hinden" initials="R." surname="Hinden"/>
    <date month="July" year="2017"/>
    <abstract>
      <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="86"/>
  <seriesInfo name="RFC" value="8200"/>
  <seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>

<reference anchor="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"/>
    <author fullname="J. Hui" initials="J." surname="Hui"/>
    <author fullname="D. Popa" initials="D." surname="Popa"/>
    <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">
  <front>
    <title>Energy-Efficient Features of Internet of Things Protocols</title>
    <author fullname="C. Gomez" initials="C." surname="Gomez"/>
    <author fullname="M. Kovatsch" initials="M." surname="Kovatsch"/>
    <author fullname="H. Tian" initials="H." surname="Tian"/>
    <author fullname="Z. Cao" initials="Z." role="editor" surname="Cao"/>
    <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">
  <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"/>
    <author fullname="M. Behringer" initials="M." surname="Behringer"/>
    <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">
  <front>
    <title>Sensor Measurement Lists (SenML)</title>
    <author fullname="C. Jennings" initials="C." surname="Jennings"/>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <author fullname="J. Arkko" initials="J." surname="Arkko"/>
    <author fullname="A. Keranen" initials="A." surname="Keranen"/>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <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="RFC8446">
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
    <date month="August" year="2018"/>
    <abstract>
      <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
      <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8446"/>
  <seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>

<reference anchor="RFC8575">
  <front>
    <title>YANG Data Model for the Precision Time Protocol (PTP)</title>
    <author fullname="Y. Jiang" initials="Y." role="editor" surname="Jiang"/>
    <author fullname="X. Liu" initials="X." surname="Liu"/>
    <author fullname="J. Xu" initials="J." surname="Xu"/>
    <author fullname="R. Cummings" initials="R." role="editor" surname="Cummings"/>
    <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">
  <front>
    <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
    <author fullname="G. Selander" initials="G." surname="Selander"/>
    <author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
    <author fullname="F. Palombini" initials="F." surname="Palombini"/>
    <author fullname="L. Seitz" initials="L." surname="Seitz"/>
    <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">
  <front>
    <title>SCHC: Generic Framework for Static Context Header Compression and Fragmentation</title>
    <author fullname="A. Minaburo" initials="A." surname="Minaburo"/>
    <author fullname="L. Toutain" initials="L." surname="Toutain"/>
    <author fullname="C. Gomez" initials="C." surname="Gomez"/>
    <author fullname="D. Barthel" initials="D." surname="Barthel"/>
    <author fullname="JC. Zuniga" initials="JC." surname="Zuniga"/>
    <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">
  <front>
    <title>Deprecating Any-Source Multicast (ASM) for Interdomain Multicast</title>
    <author fullname="M. Abrahamsson" initials="M." surname="Abrahamsson"/>
    <author fullname="T. Chown" initials="T." surname="Chown"/>
    <author fullname="L. Giuliano" initials="L." surname="Giuliano"/>
    <author fullname="T. Eckert" initials="T." surname="Eckert"/>
    <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">
  <front>
    <title>Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)</title>
    <author fullname="A. Minaburo" initials="A." surname="Minaburo"/>
    <author fullname="L. Toutain" initials="L." surname="Toutain"/>
    <author fullname="R. Andreasen" initials="R." surname="Andreasen"/>
    <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">
  <front>
    <title>An Autonomic Control Plane (ACP)</title>
    <author fullname="T. Eckert" initials="T." role="editor" surname="Eckert"/>
    <author fullname="M. Behringer" initials="M." role="editor" surname="Behringer"/>
    <author fullname="S. Bjarnason" initials="S." surname="Bjarnason"/>
    <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 "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" 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">
  <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"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <author fullname="P. Thubert" initials="P." surname="Thubert"/>
    <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">
  <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"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <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">
  <front>
    <title>Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN</title>
    <author fullname="O. Gimenez" initials="O." role="editor" surname="Gimenez"/>
    <author fullname="I. Petrov" initials="I." role="editor" surname="Petrov"/>
    <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">
  <front>
    <title>Multicast Considerations over IEEE 802 Wireless Media</title>
    <author fullname="C. Perkins" initials="C." surname="Perkins"/>
    <author fullname="M. McBride" initials="M." surname="McBride"/>
    <author fullname="D. Stanley" initials="D." surname="Stanley"/>
    <author fullname="W. Kumari" initials="W." surname="Kumari"/>
    <author fullname="JC. Zúñiga" initials="JC." surname="Zúñiga"/>
    <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">
  <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"/>
    <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <author fullname="S. Raza" initials="S." surname="Raza"/>
    <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">
  <front>
    <title>Constrained RESTful Environments (CoRE) Resource Directory</title>
    <author fullname="C. Amsüss" initials="C." role="editor" surname="Amsüss"/>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <author fullname="M. Koster" initials="M." surname="Koster"/>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <author fullname="P. van der Stok" initials="P." surname="van der Stok"/>
    <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">
  <front>
    <title>Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks</title>
    <author fullname="J. Arkko" initials="J." surname="Arkko"/>
    <author fullname="A. Eriksson" initials="A." surname="Eriksson"/>
    <author fullname="A. Keränen" initials="A." surname="Keränen"/>
    <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="RFC9006">
  <front>
    <title>TCP Usage Guidance in the Internet of Things (IoT)</title>
    <author fullname="C. Gomez" initials="C." surname="Gomez"/>
    <author fullname="J. Crowcroft" initials="J." surname="Crowcroft"/>
    <author fullname="M. Scharf" initials="M." surname="Scharf"/>
    <date month="March" year="2021"/>
    <abstract>
      <t>This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs. The objective is to help embedded developers with decisions on which TCP features to use.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9006"/>
  <seriesInfo name="DOI" value="10.17487/RFC9006"/>
</reference>

<reference anchor="RFC7228">
  <front>
    <title>Terminology for Constrained-Node Networks</title>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <author fullname="M. Ersue" initials="M." surname="Ersue"/>
    <author fullname="A. Keranen" initials="A." surname="Keranen"/>
    <date month="May" year="2014"/>
    <abstract>
      <t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7228"/>
  <seriesInfo name="DOI" value="10.17487/RFC7228"/>
</reference>

<reference anchor="RFC7388">
  <front>
    <title>Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
    <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
    <author fullname="A. Sehgal" initials="A." surname="Sehgal"/>
    <author fullname="T. Tsou" initials="T." surname="Tsou"/>
    <author fullname="C. Zhou" initials="C." surname="Zhou"/>
    <date month="October" year="2014"/>
    <abstract>
      <t>This document 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 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7388"/>
  <seriesInfo name="DOI" value="10.17487/RFC7388"/>
</reference>

<reference anchor="RFC8928">
  <front>
    <title>Address-Protected Neighbor Discovery for Low-Power and Lossy Networks</title>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <author fullname="B. Sarikaya" initials="B." surname="Sarikaya"/>
    <author fullname="M. Sethi" initials="M." surname="Sethi"/>
    <author fullname="R. Struik" initials="R." surname="Struik"/>
    <date month="November" year="2020"/>
    <abstract>
      <t>This document updates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and 8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8928"/>
  <seriesInfo name="DOI" value="10.17487/RFC8928"/>
</reference>

<reference anchor="RFC8505">
  <front>
    <title>Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery</title>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
    <author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti"/>
    <author fullname="C. Perkins" initials="C." surname="Perkins"/>
    <date month="November" year="2018"/>
    <abstract>
      <t>This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8505"/>
  <seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>

<reference anchor="RFC8025">
  <front>
    <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch</title>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <author fullname="R. Cragie" initials="R." surname="Cragie"/>
    <date month="November" year="2016"/>
    <abstract>
      <t>This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8025"/>
  <seriesInfo name="DOI" value="10.17487/RFC8025"/>
</reference>

<reference anchor="RFC9159">
  <front>
    <title>IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP)</title>
    <author fullname="C. Gomez" initials="C." surname="Gomez"/>
    <author fullname="S.M. Darroudi" initials="S.M." surname="Darroudi"/>
    <author fullname="T. Savolainen" initials="T." surname="Savolainen"/>
    <author fullname="M. Spoerk" initials="M." surname="Spoerk"/>
    <date month="December" year="2021"/>
    <abstract>
      <t>RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol Support Profile (IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9159"/>
  <seriesInfo name="DOI" value="10.17487/RFC9159"/>
</reference>

<reference anchor="RFC7668">
  <front>
    <title>IPv6 over BLUETOOTH(R) Low Energy</title>
    <author fullname="J. Nieminen" initials="J." surname="Nieminen"/>
    <author fullname="T. Savolainen" initials="T." surname="Savolainen"/>
    <author fullname="M. Isomaki" initials="M." surname="Isomaki"/>
    <author fullname="B. Patil" initials="B." surname="Patil"/>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <author fullname="C. Gomez" initials="C." surname="Gomez"/>
    <date month="October" year="2015"/>
    <abstract>
      <t>Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7668"/>
  <seriesInfo name="DOI" value="10.17487/RFC7668"/>
</reference>

<reference anchor="RFC8105">
  <front>
    <title>Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)</title>
    <author fullname="P. Mariager" initials="P." surname="Mariager"/>
    <author fullname="J. Petersen" initials="J." role="editor" surname="Petersen"/>
    <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
    <author fullname="M. Van de Logt" initials="M." surname="Van de Logt"/>
    <author fullname="D. Barthel" initials="D." surname="Barthel"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.</t>
      <t>The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.</t>
      <t>DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.</t>
      <t>This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8105"/>
  <seriesInfo name="DOI" value="10.17487/RFC8105"/>
</reference>

<reference anchor="RFC8931">
  <front>
    <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery</title>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <date month="November" year="2020"/>
    <abstract>
      <t>This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8931"/>
  <seriesInfo name="DOI" value="10.17487/RFC8931"/>
</reference>

<reference anchor="RFC9034">
  <front>
    <title>Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
    <author fullname="L. Thomas" initials="L." surname="Thomas"/>
    <author fullname="S. Anamalamudi" initials="S." surname="Anamalamudi"/>
    <author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand"/>
    <author fullname="M. Hegde" initials="M." surname="Hegde"/>
    <author fullname="C. Perkins" initials="C." surname="Perkins"/>
    <date month="June" year="2021"/>
    <abstract>
      <t>This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time-critical machine-to-machine (M2M) applications running on Internet-enabled devices that operate within time-synchronized networks. This document also specifies a representation for the deadline time values in such networks.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9034"/>
  <seriesInfo name="DOI" value="10.17487/RFC9034"/>
</reference>

<reference anchor="RFC9354">
  <front>
    <title>Transmission of IPv6 Packets over Power Line Communication (PLC) Networks</title>
    <author fullname="J. Hou" initials="J." surname="Hou"/>
    <author fullname="B. Liu" initials="B." surname="Liu"/>
    <author fullname="Y-G. Hong" surname="Y-G. Hong"/>
    <author fullname="X. Tang" initials="X." surname="Tang"/>
    <author fullname="C. Perkins" initials="C." surname="Perkins"/>
    <date month="January" year="2023"/>
    <abstract>
      <t>Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9354"/>
  <seriesInfo name="DOI" value="10.17487/RFC9354"/>
</reference>

<reference anchor="RFC7973">
  <front>
    <title>Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation</title>
    <author fullname="R. Droms" initials="R." surname="Droms"/>
    <author fullname="P. Duffy" initials="P." surname="Duffy"/>
    <date month="November" year="2016"/>
    <abstract>
      <t>When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7973"/>
  <seriesInfo name="DOI" value="10.17487/RFC7973"/>
</reference>

<reference anchor="RFC4919">
  <front>
    <title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals</title>
    <author fullname="N. Kushalnagar" initials="N." surname="Kushalnagar"/>
    <author fullname="G. Montenegro" initials="G." surname="Montenegro"/>
    <author fullname="C. Schumacher" initials="C." surname="Schumacher"/>
    <date month="August" year="2007"/>
    <abstract>
      <t>This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4919"/>
  <seriesInfo name="DOI" value="10.17487/RFC4919"/>
</reference>

<reference anchor="RFC6606">
  <front>
    <title>Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing</title>
    <author fullname="E. Kim" initials="E." surname="Kim"/>
    <author fullname="D. Kaspar" initials="D." surname="Kaspar"/>
    <author fullname="C. Gomez" initials="C." surname="Gomez"/>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <date month="May" year="2012"/>
    <abstract>
      <t>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.</t>
      <t>This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6606"/>
  <seriesInfo name="DOI" value="10.17487/RFC6606"/>
</reference>

<reference anchor="RFC9271">
  <front>
    <title>Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses</title>
    <author fullname="R. Price" initials="R." role="editor" surname="Price"/>
    <date month="August" year="2022"/>
    <abstract>
      <t>This document describes the command/response protocol currently used in the management of Uninterruptible Power Supply (UPS) units and other power devices often deployed in small offices and in IT installations subject to an erratic public power supply. The UPS units typically interface to an Attachment Daemon in the system they protect. This daemon is in turn polled by a Management Daemon that notifies users and system administrators of power supply incidents and automates system shutdown decisions. The commands and responses described by this document are exchanged between the UPS Attachment Daemon and the Management Daemon. The practice current when this protocol was first developed risks weak security, and this is addressed in the Security Considerations sections of this document.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9271"/>
  <seriesInfo name="DOI" value="10.17487/RFC9271"/>
</reference>

<reference anchor="RFC9139">
  <front>
    <title>Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)</title>
    <author fullname="C. Gündoğan" initials="C." surname="Gündoğan"/>
    <author fullname="T. Schmidt" initials="T." surname="Schmidt"/>
    <author fullname="M. Wählisch" initials="M." surname="Wählisch"/>
    <author fullname="C. Scherb" initials="C." surname="Scherb"/>
    <author fullname="C. Marxer" initials="C." surname="Marxer"/>
    <author fullname="C. Tschudin" initials="C." surname="Tschudin"/>
    <date month="November" year="2021"/>
    <abstract>
      <t>This document defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.</t>
      <t>This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9139"/>
  <seriesInfo name="DOI" value="10.17487/RFC9139"/>
</reference>

<reference anchor="RFC6553">
  <front>
    <title>The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams</title>
    <author fullname="J. Hui" initials="J." surname="Hui"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <date month="March" year="2012"/>
    <abstract>
      <t>The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6553"/>
  <seriesInfo name="DOI" value="10.17487/RFC6553"/>
</reference>

<reference anchor="RFC6554">
  <front>
    <title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
    <author fullname="J. Hui" initials="J." surname="Hui"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <author fullname="D. Culler" initials="D." surname="Culler"/>
    <author fullname="V. Manral" initials="V." surname="Manral"/>
    <date month="March" year="2012"/>
    <abstract>
      <t>In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6554"/>
  <seriesInfo name="DOI" value="10.17487/RFC6554"/>
</reference>

<reference anchor="RFC6551">
  <front>
    <title>Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks</title>
    <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
    <author fullname="M. Kim" initials="M." role="editor" surname="Kim"/>
    <author fullname="K. Pister" initials="K." surname="Pister"/>
    <author fullname="N. Dejean" initials="N." surname="Dejean"/>
    <author fullname="D. Barthel" initials="D." surname="Barthel"/>
    <date month="March" year="2012"/>
    <abstract>
      <t>Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6551"/>
  <seriesInfo name="DOI" value="10.17487/RFC6551"/>
</reference>

<reference anchor="RFC6552">
  <front>
    <title>Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <date month="March" year="2012"/>
    <abstract>
      <t>The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.</t>
      <t>This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6552"/>
  <seriesInfo name="DOI" value="10.17487/RFC6552"/>
</reference>

<reference anchor="RFC7731">
  <front>
    <title>Multicast Protocol for Low-Power and Lossy Networks (MPL)</title>
    <author fullname="J. Hui" initials="J." surname="Hui"/>
    <author fullname="R. Kelsey" initials="R." surname="Kelsey"/>
    <date month="February" year="2016"/>
    <abstract>
      <t>This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.</t>
      <t>MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7731"/>
  <seriesInfo name="DOI" value="10.17487/RFC7731"/>
</reference>

<reference anchor="RFC8138">
  <front>
    <title>IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header</title>
    <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert"/>
    <author fullname="C. Bormann" initials="C." surname="Bormann"/>
    <author fullname="L. Toutain" initials="L." surname="Toutain"/>
    <author fullname="R. Cragie" initials="R." surname="Cragie"/>
    <date month="April" year="2017"/>
    <abstract>
      <t>This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8138"/>
  <seriesInfo name="DOI" value="10.17487/RFC8138"/>
</reference>

<reference anchor="RFC7416">
  <front>
    <title>A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)</title>
    <author fullname="T. Tsao" initials="T." surname="Tsao"/>
    <author fullname="R. Alexander" initials="R." surname="Alexander"/>
    <author fullname="M. Dohler" initials="M." surname="Dohler"/>
    <author fullname="V. Daza" initials="V." surname="Daza"/>
    <author fullname="A. Lozano" initials="A." surname="Lozano"/>
    <author fullname="M. Richardson" initials="M." role="editor" surname="Richardson"/>
    <date month="January" year="2015"/>
    <abstract>
      <t>This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7416"/>
  <seriesInfo name="DOI" value="10.17487/RFC7416"/>
</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">
         <organization>SITI, University Lusofona</organization>
      </author>
      <author fullname="Rute C. Sofia" initials="R. C." surname="Sofia">
         <organization>SITI, University Lusofona</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.claise-power-management-arch">
   <front>
      <title>Power Management Architecture</title>
      <author fullname="Benoît Claise" initials="B." surname="Claise">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="John Parello" initials="J." surname="Parello">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="Brad Schoening" initials="B." surname="Schoening">
         <organization>Cisco Systems</organization>
      </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"/>
   
</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">
         <organization>Universitaet Bremen TZI</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.castellani-core-alive">
   <front>
      <title>CoAP Alive Message</title>
      <author fullname="Angelo P. Castellani" initials="A. P." surname="Castellani">
         <organization>University of Padova</organization>
      </author>
      <author fullname="Salvatore Loreto" initials="S." surname="Loreto">
         <organization>Ericsson</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.chakrabarti-nordmark-energy-aware-nd">
   <front>
      <title>Energy Aware IPv6 Neighbor Discovery Optimizations</title>
      <author fullname="Samita Chakrabarti" initials="S." surname="Chakrabarti">
         <organization>Ericsson</organization>
      </author>
      <author fullname="Erik Nordmark" initials="E." surname="Nordmark">
         <organization>Cisco Systems</organization>
      </author>
      <author fullname="Margaret Cullen" initials="M." surname="Cullen">
         <organization>Painless Security</organization>
      </author>
      <date day="12" month="March" year="2012"/>
      <abstract>
	 <t>   IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
   neighbor&#x27;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"/>
   
</reference>


<reference anchor="I-D.zhang-greennet">
   <front>
      <title>Power-aware Routing and Traffic Engineering: Requirements, Approaches, and Issues</title>
      <author fullname="Beichuan Zhang" initials="B." surname="Zhang">
         <organization>The University of Arizona</organization>
      </author>
      <author fullname="Junxiao Shi" initials="J." surname="Shi">
         <organization>The University of Arizona</organization>
      </author>
      <author fullname="Jie Dong" initials="J." surname="Dong">
         <organization>Huawei</organization>
      </author>
      <author fullname="Mingui Zhang" initials="M." surname="Zhang">
         <organization>Huawei</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.fossati-core-monitor-option">
   <front>
      <title>Monitor Option for CoAP</title>
      <author fullname="Thomas Fossati" initials="T." surname="Fossati">
         <organization>KoanLogic</organization>
      </author>
      <author fullname="Pierpaolo Giacomin" initials="P." surname="Giacomin">
         <organization>Freelance</organization>
      </author>
      <author fullname="Salvatore Loreto" initials="S." surname="Loreto">
         <organization>Ericsson</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.fossati-core-publish-option">
   <front>
      <title>Publish Option for CoAP</title>
      <author fullname="Thomas Fossati" initials="T." surname="Fossati">
         <organization>Alcatel-Lucent</organization>
      </author>
      <author fullname="Pierpaolo Giacomin" initials="P." surname="Giacomin">
         <organization>Freelance</organization>
      </author>
      <author fullname="Salvatore Loreto" initials="S." surname="Loreto">
         <organization>Ericsson</organization>
      </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 &#x27;proxies&#x27; 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&#x27;s
   request upstream.

   The Publish Option and the &#x27;proxies&#x27; 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"/>
   
</reference>


<reference anchor="I-D.giacomin-core-sleepy-option">
   <front>
      <title>Sleepy Option for CoAP</title>
      <author fullname="Thomas Fossati" initials="T." surname="Fossati">
         <organization>KoanLogic</organization>
      </author>
      <author fullname="Pierpaolo Giacomin" initials="P." surname="Giacomin">
         <organization>Freelance</organization>
      </author>
      <author fullname="Salvatore Loreto" initials="S." surname="Loreto">
         <organization>Ericsson</organization>
      </author>
      <author fullname="Mirko Rossini" initials="M." surname="Rossini">
         <organization>CS Dept. University of Bologna</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.ietf-core-coap-pubsub">
   <front>
      <title>A publish-subscribe architecture for the Constrained Application Protocol (CoAP)</title>
      <author fullname="Jaime Jimenez" initials="J." surname="Jimenez">
         <organization>Ericsson</organization>
      </author>
      <author fullname="Michael Koster" initials="M." surname="Koster">
         <organization>Dogtiger Labs</organization>
      </author>
      <author fullname="Ari Keränen" initials="A." surname="Keränen">
         <organization>Ericsson</organization>
      </author>
      <date day="20" month="October" year="2023"/>
      <abstract>
	 <t>   This document describes a publish-subscribe architecture for the
   Constrained Application Protocol (CoAP), extending the capabilities
   of CoAP communications for supporting endpoints with long breaks in
   connectivity and/or up-time.  CoAP clients publish on and subscribe
   to a topic via a corresponding topic resource at a CoAP server acting
   as broker.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-pubsub-13"/>
   
</reference>


<reference anchor="I-D.ietf-dnssd-srp">
   <front>
      <title>Service Registration Protocol for DNS-Based Service Discovery</title>
      <author fullname="Ted Lemon" initials="T." surname="Lemon">
         <organization>Apple Inc.</organization>
      </author>
      <author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
         <organization>Apple Inc.</organization>
      </author>
      <date day="4" month="August" year="2023"/>
      <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 IEEE 802.11
   (Wi-Fi) and IEEE 802.15.4 networks.  DNS-SD Service registration uses
   public keys and SIG(0) to allow services to defend their
   registrations.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-dnssd-srp-23"/>
   
</reference>


<reference anchor="I-D.jennings-energy-pricing">
   <front>
      <title>Communication of Energy Price Information</title>
      <author fullname="Cullen Fluffy Jennings" initials="C. F." surname="Jennings">
         <organization>Cisco</organization>
      </author>
      <author fullname="Bruce Nordman" initials="B." surname="Nordman">
         <organization>Lawrence Berkeley National</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.manral-bmwg-power-usage">
   <front>
      <title>Benchmarking Power usage of networking devices</title>
      <author fullname="Vishwas Manral" initials="V." surname="Manral">
         <organization>HP</organization>
      </author>
      <author fullname="Puneet Sharma" initials="P." surname="Sharma">
         <organization>HP</organization>
      </author>
      <author fullname="Sujata Banerjee" initials="S." surname="Banerjee">
         <organization>HP</organization>
      </author>
      <author fullname="Yang Ping" initials="Y." surname="Ping">
         <organization>H3C</organization>
      </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"/>
   
</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" initials="S." surname="Raman">
         <organization>IIT Madras</organization>
      </author>
      <author fullname="Balaji Venkat Venkataswami" initials="B. V." surname="Venkataswami">
         <organization>IIT Madras</organization>
      </author>
      <author fullname="Gaurav Raina" initials="G." surname="Raina">
         <organization>IIT Madras</organization>
      </author>
      <author fullname="Kamakoti Veezhinathan" initials="K." surname="Veezhinathan">
         <organization>IIT Madras</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.mjsraman-rtgwg-pim-power">
   <front>
      <title>Building power optimal Multicast Trees</title>
      <author fullname="Shankar Raman" initials="S." surname="Raman">
         <organization>I.I.T Madras</organization>
      </author>
      <author fullname="Balaji Venkat Venkataswami" initials="B. V." surname="Venkataswami">
         <organization>I.I.T Madras</organization>
      </author>
      <author fullname="Gaurav Raina" initials="G." surname="Raina">
         <organization>I.I.T Madras</organization>
      </author>
      <author fullname="Vasan Srini" initials="V." surname="Srini">
         <organization>I.I.T Madras</organization>
      </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"/>
   
</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" initials="S." surname="Okamoto">
         <organization>Keio University</organization>
      </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"/>
   
</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" initials="A." surname="Rahman">
         <organization>InterDigital Communications</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.rahman-core-sleepy-problem-statement">
   <front>
      <title>Sleepy Devices in CoAP - Problem Statement</title>
      <author fullname="Akbar Rahman" initials="A." surname="Rahman">
         <organization>InterDigital Communications</organization>
      </author>
      <author fullname="Thomas Fossati" initials="T." surname="Fossati">
         <organization>KoanLogic</organization>
      </author>
      <author fullname="Salvatore Loreto" initials="S." surname="Loreto">
         <organization>Ericsson</organization>
      </author>
      <author fullname="Matthieu Vial" initials="M." surname="Vial">
         <organization>Schneider-Electric</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.rahman-core-sleepy">
   <front>
      <title>Enhanced Sleepy Node Support for CoAP</title>
      <author fullname="Akbar Rahman" initials="A." surname="Rahman">
         <organization>InterDigital Communications</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.retana-rtgwg-eacp">
   <front>
      <title>A Framework for Energy Aware Control Planes</title>
      <author fullname="Alvaro Retana" initials="A." surname="Retana">
         <organization>Futurewei Technologies, Inc.</organization>
      </author>
      <author fullname="Russ White" initials="R." surname="White">
         <organization>Akamai Technologies</organization>
      </author>
      <author fullname="Manuel Paul" initials="M." surname="Paul">
         <organization>Deutsche Telekom AG</organization>
      </author>
      <date day="24" month="August" year="2023"/>
      <abstract>
	 <t>   Energy is a primary constraint in large-scale network design,
   particularly in cloud-scale data center fabrics.  While compute and
   storage clearly consume the largest amounts of energy in large-scale
   networks, the optics and electronics used in transporting data also
   contribute to energy usage and heat generation.

   This document provides an overview of 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 ones to improve the energy efficiency
   of high density, highly complex, network deployments.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-retana-rtgwg-eacp-07"/>
   
</reference>


<reference anchor="I-D.suzuki-eens-requirements">
   <front>
      <title>Requirements for an Energy-Efficient Network System</title>
      <author fullname="Toshiaki Suzuki" initials="T." surname="Suzuki">
         <organization>Hitachi, Ltd.</organization>
      </author>
      <author fullname="Toshiaki Tarui" initials="T." surname="Tarui">
         <organization>Hitachi, Ltd.</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.vial-core-mirror-proxy">
   <front>
      <title>CoRE Mirror Server</title>
      <author fullname="Matthieu Vial" initials="M." surname="Vial">
         <organization>Schneider-Electric</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.vial-core-mirror-server">
   <front>
      <title>CoRE Mirror Server</title>
      <author fullname="Matthieu Vial" initials="M." surname="Vial">
         <organization>Schneider-Electric</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.wang-roll-energy-optimization-scheme">
   <front>
      <title>An energy optimization routing scheme for LLSs</title>
      <author fullname="Hao Wang" initials="H." surname="Wang">
         <organization>Chongqing University of</organization>
      </author>
      <author fullname="Min Wei" initials="M." surname="Wei">
         <organization>Chongqing University of</organization>
      </author>
      <author fullname="ShuaiYong Li" initials="S." surname="Li">
         <organization>Chongqing University of</organization>
      </author>
      <author fullname="QingQing Huang" initials="Q." surname="Huang">
         <organization>Chongqing University of</organization>
      </author>
      <author fullname="Ping Wang" initials="P." surname="Wang">
         <organization>Chongqing University of</organization>
      </author>
      <author fullname="Chaomei Wang" initials="C." surname="Wang">
         <organization>Chongqing University of</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.winter-energy-efficient-internet">
   <front>
      <title>Towards an Energy-Efficient Internet</title>
      <author fullname="Rolf Winter" initials="R." surname="Winter">
         <organization>HSA</organization>
      </author>
      <author fullname="Sangjin Jeong" initials="S." surname="Jeong">
         <organization>ETRI</organization>
      </author>
      <author fullname="JinHyeock Choi" initials="J." surname="Choi">
         <organization>Samsung AIT</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.zhang-panet-problem-statement">
   <front>
      <title>Power-Aware Networks (PANET): Problem Statement</title>
      <author fullname="Beichuan Zhang" initials="B." surname="Zhang">
         <organization>Univ. of Arizona</organization>
      </author>
      <author fullname="Junxiao Shi" initials="J." surname="Shi">
         <organization>Univ. of Arizona</organization>
      </author>
      <author fullname="Jie Dong" initials="J." surname="Dong">
         <organization>Huawei</organization>
      </author>
      <author fullname="Mingui Zhang" initials="M." surname="Zhang">
         <organization>Huawei</organization>
      </author>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
         <organization>France Telecom</organization>
      </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"/>
   
</reference>


<reference anchor="I-D.boucadair-irtf-sdn-and-semantic-routing">
   <front>
      <title>Considerations for the use of SDN in Semantic Routing Networks</title>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
         <organization>Orange</organization>
      </author>
      <author fullname="Dirk Trossen" initials="D." surname="Trossen">
         <organization>Huawei</organization>
      </author>
      <author fullname="Adrian Farrel" initials="A." surname="Farrel">
         <organization>Old Dog Consulting</organization>
      </author>
      <date day="31" month="May" year="2022"/>
      <abstract>
	 <t>   The forwarding of packets in today&#x27;s networks has long evolved beyond
   ensuring mere reachability of the receiving endpoint.  Instead, other
   &#x27;purposes&#x27; of communication, e.g., ensuring quality of service of
   delivery, ensuring protection against path failures through utilizing
   more than one, and others, are realized by many extensions to the
   original reachability purpose of IP routing.

   Semantic Routing defines an approach to realizing such extended
   purposes beyond reachability by instead making routing and forwarding
   decisions based, not only on the destination IP address, but on other
   information carried in an IP packet.  The intent is to facilitate
   enhanced routing decisions based on this information in order to
   provide differentiated forwarding paths for specific packet flows.

   Software Defined Networking (SDN) places control of network elements
   (including all or some of their forwarding decisions) within external
   software components called controllers and orchestrators.  This
   approach differs from conventional approaches that solely rely upon
   distributed routing protocols for the delivery of advanced
   connectivity services.  By doing so, SDN aims to enable network
   elements to be simplified while still performing forwarding function.

   This document examines the applicability of SDN techniques to
   Semantic Routing and provides considerations for the development of
   Semantic Routing solutions in the context of SDN.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-boucadair-irtf-sdn-and-semantic-routing-01"/>
   
</reference>


<reference anchor="I-D.petrescu-v6ops-ipv6-power-ipv4">
   <front>
      <title>Power Consumption of IPv6 vs IPv4 in Smartphone</title>
      <author fullname="Alexandre Petrescu" initials="A." surname="Petrescu">
         <organization>CEA, LIST</organization>
      </author>
      <author fullname="Siwar Ben Hadj Saïd" initials="S. B. H." surname="Saïd">
         </author>
      <author fullname="Olivier Philippot" initials="O." surname="Philippot">
         <organization>Greenspector</organization>
      </author>
      <author fullname="Thomas Vincent" initials="T." surname="Vincent">
         <organization>Greenspector</organization>
      </author>
      <date day="13" month="March" year="2017"/>
      <abstract>
	 <t>   This draft documents preliminary results of measuring the power
   consumption of using IPv6 vs using IPv4 on typical applications on a
   smartphone.  The smartphone is connected on a 4G cellular network
   with either an IPv6 connection, or with an IPv4 connection, but not
   both simultaneously.

   The preliminary results expose a roughly 5% increase in power
   consumption on IPv6.  More experiments are planned as future work
   that may confirm or infirm these figures.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-petrescu-v6ops-ipv6-power-ipv4-00"/>
   
</reference>


<reference anchor="I-D.lhan-problems-requirements-satellite-net">
   <front>
      <title>Problems and Requirements of Satellite Constellation for Internet</title>
      <author fullname="Lin Han" initials="L." surname="Han">
         <organization>Futurewei Technologies, Inc.</organization>
      </author>
      <author fullname="Richard Li" initials="R." surname="Li">
         <organization>Futurewei Technologies, Inc.</organization>
      </author>
      <author fullname="Alvaro Retana" initials="A." surname="Retana">
         <organization>Futurewei Technologies, Inc.</organization>
      </author>
      <author fullname="Meiling Chen" initials="M." surname="Chen">
         <organization>China Mobile</organization>
      </author>
      <author fullname="Li Su" initials="L." surname="Su">
         <organization>China Mobile</organization>
      </author>
      <author fullname="Tianji Jiang" initials="T." surname="Jiang">
         <organization>China Mobile</organization>
      </author>
      <date day="4" month="January" year="2024"/>
      <abstract>
	 <t>   This document presents the detailed analysis about the problems and
   requirements of satellite constellation used for Internet.  It starts
   from the satellite orbit basics, coverage calculation, then it
   estimates the time constraints for the communications between
   satellite and ground-station, also between satellites.  How to use
   satellite constellation for Internet is discussed in detail including
   the satellite relay and satellite networking.  The problems and
   requirements of using traditional network technology for satellite
   network integrating with Internet are finally outlined.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-lhan-problems-requirements-satellite-net-06"/>
   
</reference>


<reference anchor="I-D.ietf-tcpm-rfc793bis">
   <front>
      <title>Transmission Control Protocol (TCP)</title>
      <author fullname="Wesley Eddy" initials="W." surname="Eddy">
         <organization>MTI Systems</organization>
      </author>
      <date day="7" month="March" year="2022"/>
      <abstract>
	 <t>This document specifies the Transmission Control Protocol (TCP).  TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet.  Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion.  This document collects and brings those changes together with the protocol specification from RFC 793.  This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793.  It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements.  It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state.  The TCP header control bits from RFC 793 have also been updated based on RFC 3168.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-rfc793bis-28"/>
   
</reference>


<reference anchor="I-D.desmouceaux-ipv6-mcast-wifi-power-usage">
   <front>
      <title>Power consumption due to IPv6 multicast on WiFi devices</title>
      <author fullname="Yoann Desmouceaux" initials="Y." surname="Desmouceaux">
         <organization>Cisco</organization>
      </author>
      <date day="1" month="August" year="2014"/>
      <abstract>
	 <t>   IPv6 networks make a consequent use of multicast for several
   purposes, including mandatory functions such as Neighbor Discovery.
   Although this use of multicast does not create real difficulties on
   wired networks, it can become painful on wireless ones, notably in
   terms of power consumption.  There might be little effect on home
   networks, however, such effects become more important on large-scale
   networks.  This memo provides statistics about the multicast traffic
   rate in a large IPv6 wireless network and the induced device power
   consumption, in response to a call emitted at IETF 89.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-desmouceaux-ipv6-mcast-wifi-power-usage-01"/>
   
</reference>


<reference anchor="I-D.ietf-roll-protocols-survey">
   <front>
      <title>Overview of Existing Routing Protocols for Low Power and Lossy Networks</title>
      <author fullname="Arsalan Tavakoli" initials="A." surname="Tavakoli">
         <organization>UC Berkeley</organization>
      </author>
      <author fullname="Stephen Dawson-Haggerty" initials="S." surname="Dawson-Haggerty">
         <organization>UC Berkeley</organization>
      </author>
      <date day="24" month="April" year="2009"/>
      <abstract>
	 <t>   Low-power wireless devices, such as sensors, actuators and smart    objects, present difficult constraints: very limited memory, little
   processing power, and long sleep periods.  As most of these devices
   are battery-powered, energy efficiency is critically important.
   Wireless link qualities can vary significantly over time, requiring
   protocols to make agile decisions yet minimize topology change energy
   costs.  Routing over such low power and lossy networks introduces
   requirements that existing routing protocols may not fully address.
   Using existing application requirements documents, this document
   derives a minimal and not exhaustive set of criteria for routing in
   low-power and lossy networks.  It provides a brief survey of the
   strengths and weaknesses of existing protocols with respect to these
   criteria.  From this survey it examines whether existing and mature
   IETF protocols can be used without modification in these networks, or
   whether further work is necessary.  It concludes that no existing
   IETF protocol meets the requirements of this domain.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-roll-protocols-survey-07"/>
   
</reference>


<reference anchor="I-D.levis-roll-overview-protocols">
   <front>
      <title>Overview of Existing Routing Protocols for Low Power and Lossy Networks</title>
      <author fullname="JP Vasseur" initials="V." surname="Jp">
         <organization>Cisco Systems</organization>
      </author>
      <date day="12" month="February" year="2008"/>
      <abstract>
	 <t>Networks of low power wireless devices introduce novel IP routing
   issues.  Low-power wireless devices, such as sensors, actuators and
   smart objects, have difficult constraints: very limited memory,
   little processing power, and long sleep periods.  As most of these
   devices are battery-powered, energy efficiency is critically
important.  Wireless link qualities can vary significantly over time,
   requiring protocols to make agile decisions yet minimize topology
   change energy costs.  Such low power and lossy networks (L2Ns) have
   routing requirements that existing mesh protocols only partially
   address.  This document provides a brief survey of the strengths and
   weaknesses of existing protocols with respect to L2Ns.  It provides
   guidance on how lessons from existing and prior efforts can be
   leveraged in future protocol design.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-levis-roll-overview-protocols-00"/>
   
</reference>


<reference anchor="I-D.thubert-6man-ipv6-over-wireless">
   <front>
      <title>Architecture and Framework for IPv6 over Non-Broadcast Access</title>
      <author fullname="Pascal Thubert" initials="P." surname="Thubert">
         <organization>Cisco Systems, Inc</organization>
      </author>
      <author fullname="Michael Richardson" initials="M." surname="Richardson">
         <organization>Sandelman Software Works</organization>
      </author>
      <date day="8" month="March" year="2023"/>
      <abstract>
	 <t>   This document presents an architecture for IPv6 access networks that
   decouples the network-layer concepts of Links, Interface, and Subnets
   from the link-layer concepts of links, ports, and broadcast domains,
   and limits the reliance on link-layer broadcasts.  This architecture
   is suitable for IPv6 over any network, including non-broadcast
   networks.  A study of the issues with ND-Classic over wireless media
   is presented, and a framework to solve those issues within the new
   architecture is proposed.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-thubert-6man-ipv6-over-wireless-15"/>
   
</reference>


<reference anchor="ISO10589-Second-Edition" >
  <front>
    <title>Intermediate system to Intermediate system intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)</title>
    <author initials="I. O. for" surname="Standardization" fullname="International Organization for Standardization">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
  <seriesInfo name="ISO" value="ISO/IEC 10589:2002, Second Edition, Nov. 2002."/>
</reference>
<reference anchor="DVDvsStreaming" target="https://www.smithsonianmag.com/science-nature/streaming-movie-less-energy-dvd-180951586">
  <front>
    <title>Streaming a Movie Uses Less Energy Than Watching a DVD</title>
    <author initials="S." surname="Zielinski" fullname="Sarah Zielinski">
      <organization></organization>
    </author>
    <date year="2014" month="May"/>
  </front>
</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>
<reference anchor="BOUNDED_LATENCY" target="https://ieeexplore.ieee.org/document/61109">
  <front>
    <title>A calculus for network delay. I. Network elements in isolation</title>
    <author initials="R.L." surname="Cruz" fullname="R.L. Cruz">
      <organization></organization>
    </author>
    <date year="1991"/>
  </front>
  <seriesInfo name="DOI" value="10.1109/18.61109"/>
  <seriesInfo name="IEEE" value="Transactions on Information Theory ( Volume: 37, Issue: 1)"/>
</reference>



<reference anchor="I-D.iab-ws-environmental-impacts-report">
   <front>
      <title>Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022</title>
      <author fullname="Jari Arkko" initials="J." surname="Arkko">
         <organization>Ericsson</organization>
      </author>
      <author fullname="Colin Perkins" initials="C." surname="Perkins">
         <organization>University of Glasgow</organization>
      </author>
      <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
         <organization>Cisco</organization>
      </author>
      <date day="23" month="October" year="2023"/>
      <abstract>
	 <t>   Internet communications and applications have both environmental
   costs and benefits.  The IAB ran an online workshop in December 2022
   on exploring and understanding these impacts.

   The role of the workshop was to discuss the impacts, discuss the
   evolving needs from industry, and to identify areas for improvements
   and future work.  A key goal of the workshop was to call further
   attention to the topic and to bring together a diverse stakeholder
   community to discuss these issues.

   This report summarises the workshop inputs and discussions.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-iab-ws-environmental-impacts-report-03"/>
   
</reference>

<reference anchor="RFC9293">
  <front>
    <title>Transmission Control Protocol (TCP)</title>
    <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
    <date month="August" year="2022"/>
    <abstract>
      <t>This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="7"/>
  <seriesInfo name="RFC" value="9293"/>
  <seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA829a3PbSJcm+B2/AsGK2SVjCOp+837oliXZpW7J0lpyeXp2
JhwgCZIokwAbACWzHPXf9zznkpkgqdfvTMRG7ETPWzQFJvJy8tzPc5IkiUbl
OC+m7+JVM0nOo6jJm3n2Lr4s4oeXrHrJs9e4nMQ3RVZN10mVzdMmG8c3k0lZ
NfFr3szyIm5mWXx78/whjtLhsMpe3sm/5DdumGhcjop0QWOPq3TSJNnoe1Y1
SZ7Re9NinGTyilIfT/ZPo7qpsnTxLs6LcbbM6H+KJhrRBKZltca3kzLKl9W7
uKlWdXO4v3+xfxjRj2i0b+m8LOhV66yOlvm7KI7jphzJv+UzjdjM3sUn+GdN
i6mySe3+Xq8XrX+PysWCXq5fROmqmZUVRk3wV/w/WdlzmVXzrK7jG16c/bEq
saXZOG/Kyr4rK9rzD6tmVWWvWR4/Z6NZUc7LaZ7V8ZenS3sMW5A17+LDw8P9
+IrmUKXz+ObHsqK3vKZre2yUN7QjT2nRpPHVPK1S94dyTK++uowvTvZP9v23
KxqJfhG8KVuk+Zz2ssn+dVQPJulqMM62V3hfzui/4/h9uRql4zSvfrnGhyot
pll7op+zopCd9XM8Otnf357gB/r1KNuY40ImMRjaJP615JcM6Jy2p/yY1iPa
tOfZahicCc/tKq9HZfy0rptsUffj22I02Nz445P4cj7PsnhMB/NQLeh/k/j9
4wGRWz9+v8rnuD3x9cZBlMtZntIlavJlOc83Vrp/enhyHN8/fPl4++npFyte
zpiOO//16Cg+vjiLD4/iw9P46LizsSVEzLy8fx1hSbwR2zvxb9lkQpRGhLzy
FMIb8emP2+vby3+CPP6kIeiCNQPc23+d4ss3XnaVVvOyjh/zaZE2aVW233cV
PzV0k+MvRU4XvqZd+ydePlrKYOF76f+BEVSLtKGRcCc/f7g6Oz23TxcH7tOR
fjo/PNRPBwcH/uOx+3h6aD8/OD89dR/PbYDD/XP79vDQjXB4eOy+PXIj0Jf7
7uPZiX08OXaD+ekcnp8c68ejw1Ob+NHxkT17dHJigx2dHroHLo7P3cezM/14
fOg24fjwzJ49PnKTpIm5Z8/d244vjo/9xwv9eOLXdnLk5nty4l58cnpmkzw5
P3TPnp/aK04u9m3xp4f7p+7j2aH7eO4++mWenl64j2enR+6j28nT83N7xemF
26jTi3NHAftHNsLZwb694uzITfLMnxB9dORy4nby7HT/yH08dg+cubednblV
nJ27PTsnFmEf94/sbedHJ4fuozuh8+ND/9Ft9fmJWyYdkCPfs0M7ofPzA/fA
uf/24sI+Xuzvn7uPB/v+o63i4uDgwn10p3lxcHbqP/oR3LmdHbr5nh25rT6/
8Ks4ccd9vn944gY7uXA76Rd/4J+9OHIz2z9yqzhy9+LswtHZ8YWb+umpm9mF
p/WLgyP3wMnJkf947D8e+I/uCM/cHM4Pjtwyjw/oFeBzv5G+sMjirKrKipSQ
+HuVLsblaxG/zrIiLsomXtWQCcn+fjzLKuZJt8n1IP1zVeRlZYpO+ppW9LGu
E5BJpA+N5mleZ8myfM2qZJEW6TSD5pGk1WhmAw3B7YoiGZVVllRlOl6ky0S2
kIdISZzN52mRyxPpXBkj/3GW0nyHadXkSVFW9NPqe2tGSTG2Z/+akVBNpiQH
SVo39u2krGvitTL2oiwg8JNy2eRlsfOR5WpIEnC28cg0T4l957qImgTscr3x
CGuG/OdRSQukcerVsPXHcVHX46SulvbtnzRT2vraVrSs8hGUW/0z7RqpT8lw
8TrVHV7VtMHuz3/WdJRpkSxTWm+SFw09kdb6aF2uqtH2s1UzxWj5Qh6zv5ff
00XZlMlolC6WySIfl1WeTBfLOc3tR5MVNS2U1On/rO0HVTrDcOF2FKQt1Mm4
TF7pVLJs/A8eXVblcJ4tkhpCFQTz9rPuLxnJ8VTnn6Ujt4n16q/V9zyhU68x
w1VeZaL86t9fctpDOf0cdwAv/7F+86816fN+X15BUqQrzp2+T2e+yP9KcfJJ
PZrRu9yzcgL6ICkedJi4C/x1QJFCp3Job26E0xWTvCLSqccFWx01qRakpY1o
TqsmIJVlRvpfPVolL6flsk7y5cup0gF9PLan5jNQi7yyvVkJXQC6hHmDo2ta
VNuMloukmoxIIRnmblfpqBc0xSxd/ZC3LXCPk9d8ku+iVR6J95FeT+ZMSYRF
Wt1L5g5inr3ktTzibCr3rD2kWmNyCiLh1+JZeitZesSa3jFbenogBn1+kTxl
o5K27IZ0fL2mZEmJudi5xZmQTp5DqatZoSYrK971dQ4jhsiadLgixrZn4JZO
iSuLOPsxwpFmsc03pr8RV83AbmkOxEhH/CAMUDY/Ww/SP15yVsvxJ3q+yPhx
rIg41jiLP2XNa1l9j5+wL6Ms7tIa4/Pjs6Oe6NXewIsDvVYVW15TwTMls+Kh
mhKnFfrltz/B/kyrsX7HP6Y7QHYdlqhj0oY9PXTid9jcvdubq5h3+B1pDIf9
WPY51n3ux5/Kl0GMPw1YTFz/cf1SP7FprATrj8F9HadkqtGZx19qslju2CYV
e/yZtjb+mjajmTxGw+1YNBk5G8t+IqtyFv/3PJvnRf0957+O6VjJNj2P79M1
zfDgWCaTVlOYTrOmWdbv9vZeX18H9YKOqiZpkRaLdArVfa/GbR7R/UhhBO/V
NnU6Ipp4wqeld3/8Mk4OzvcvTg5Io+RN+OMKr2sv/qpcLNMqp7fAZYGzl5/3
41FaDelbOhh6eAGaqJsaDxGdZEQ3xYTkdDHiDaFnSCwtySihXyzIBoRA2blD
Gxt0DeFDNmIxfeOB53xBh1JW9Rt//yP/k7bxKX9JWbSEO2xbu01I1w+374h6
Bgf7B6d7f2Jj6f8G+MGACGZ//+LtI5H9H9NdHzXhiexBOxjNs71lnu890Uik
vZLee0z2Oanu2P1Pl0+Pt1d3D1f/3jqBZ+zt07oYzarS3Ql1EN3M6S0kjuNH
MDO1uf/hruqu8Lt2D/2c1t/jD2Wl5rLs1T1UJezY2ZsrL9J6mQ/IEN0jwzOr
98bZJF3Nm71JTkS3V2VCDdm3cTlaMTffa+pm8i3TJXxjfvxN2Nm3KluWVfNt
WRTzb4enR0cH3xaYwTfM4Nv+YDmeYMfeP3z5dH1z/e3u8vnm09V/tAn3kgh0
PlrNVzVzkEK50zibp+tBfDtw/IpmwPPBphKdz3kbdtHm9jbGnwd3g/iqWv0V
7NXBxcXBP6IrJqyD/Yu9g/PBKT447nVzc9OhmT9XaVGnzF3pPhXEGz0Xf55l
ZbWOu/Ef5XyFKRyd9ePbul7hxcpoN08nz7Lsx3JO6sMAH/mM7BT2ZAZRkiRx
OiR2Qe+NoucZ3blFtiiV7RO3I/5WBr5L3jm6z5hZNo6H61hkxLKs6Z/iw4yc
D9NcnCS8hHuAI+zRL1gPfhc7tb0fe/W8DynTkKyloaMqG69EPNHL6ft6tVja
P40hgcvUK1JS8iId5qQm0GvoVJvw9TalgS7S9oFOPn6t8oa0SDw2y+ZLepYW
E6+KCXHQeZ5WJhnThpffj4erJo5YccpqjA8Comnr5ZyVywxjVTA+4gVtf2zP
4pGs5f2NcN4vJJtoqzc8wH1aFF0+LAXO2nyyBkudpsta+eoLjZhPU/DUiOh3
JYRDz6dLnEgFPWFrvaN0CQlRy0muaNx5fHC4d7h/SMISK5zl9FJm7JhI5/by
PT9a07JAlDfFS05cA2ORwL4lITFqcBi3qkfGl8vlPB+lOhmaqHoEO3QcL2Q8
jf1usAip8umU/jmmm/oqk9I9aMolcbiNTdm7/UyHGAvhkiUwnmdR9BveXpVK
KZsrJpIhJpL/ZWvmg5zRNg2JBj3t0omBlB1pR7vf/Mj8fDVPqzmRHhHZCNej
9o/AvuVTeCWVlf4b3T7d6He0XP8Y27tjOvvxijaSrLFFXsOQEY9+HQm9weal
C0o/LQuaFDgaSbS8JO5GEr7GHnezwXTQj+fp6DsOYlFi1asFkSnM2bgeET32
mA54LPr/NgJxbmLCNVHsK+kuUzqcQrZIiLMO7i3Phn4bkU1N05zkco5lrCEE
ot9BHD8xwcb2jFABnQQNBVM+pWtG1xfD6rZHacw8bk7M60dZlIu13C46v1Wt
68UB1On3DIsbZjREhaWP9aoPopa3H8sjCxm3clWM6dHUZqhroJGxap7dfL6O
63xa8D/AeCK8L/tBVuY864O5DVmdXpCGQ5yfLLDXQcgkV/WKx2AhVxubacL5
DFtviDOQDagBx2/zkBOP2XVLKmpEtFMuHVFiSLoadF8GMb+a/o8ZZIollaqW
LxYlaBncZMSaPfNfJ3PpwYhn2R7R3qkjM99I6Qh5gZgvPU0rJPLAjusa9Qx4
ezk+xPyeft+UUEnAOkir5UkIM0n9St3erONXWqa7fHwZ5Apn40F8wz+Q81mN
RiQgJqt5xEtq7e5rTldslr7IeireWD7l1XLMBMwcNC+IvxKJgbSh9f//hiH+
/PkvbH6mw+QV6nkwUJLzQLCDoRH9/fdu7jnLp7M5/X+WcnysemnYq0ZinVji
CsxVxcz6TX5KTFRtmqf0hWOYl8UmWw23nre5plnijHACyihGbDeozCdqz+lY
aD4lvZAu41ytvRe9qvRtxGzKFsRXbVU4grHLS5obJm03TySjCVNMAPdUpyPX
MfLMS/7Mih7vy4oIghUI1UFpX7yw/f51xjNxXKth3oP5R8YwnfIRhx4XYYjp
iIMu4IZZRkfc1kzoIHE8rBWMM/rDvCaS/O23+DqfEpWqmRuF/0KwbFTlQ950
2jJoiV4xpKnQLcIVob9PqnJBcy4SbDnHTscYCLQPFUZ1YWwVdkcmET6Aw1vB
TeSfHMAm0FNNh/PM3ka7XJOaT5obJjWW+eImi3qWY5NIqepHYOfM/Oev6Zoe
52k5YoFCx2+5oo+k51T9uMWDveHZ0v6UgrMXVXvoZdGCBk6nTAcNhDR94P0g
DoMFIsrFByvyuqHDn5JpKFfSJKKQqeNl2GYQcqBe5cVovmJ/SJbwkPT9PP+L
vtgxc+ZYnSeQZUa2FD3NOj5udPyoXpZO3H26f37sE6lIOI1IJCqH9MasEQ2b
/3DIf9GnEDb6++9eP5pW5WrJ7J9o2niMm1EwBzN6PmWv9e5JfPrkJoHAFw0f
q/BN57iViAyCkxJbyRrRxoO36rmTwFvl8wZ8sQF7nART+H1NytVz9qPZ/f7f
n/H+SBa7f35K2yCKPfN/MvR7fadBhYORifqd9uAuLaYrsiB4pPs7XQlCjjRQ
vYILIhvLftphQ8epTARGNFf5Yc3XViOItA10P4k4X6CCw0kFtW8cXs8ZKVll
QXynQ7TBqno674gaA7rvgGHrbzuiWWGjZvmSKWubuN/FtxMoluCqY2fkMO+D
zOS7pLYeyeIim+TN/4ULMSEezxqpPhVl0OeqbFSS/oGrCb2iyFTE0fc0qzkx
VuKsJI/ScX/jSmGYccVKId+jtFhDdEwTWpn6kuz9tVzzXAYSAmz8X70hs4Bd
SVMhPprRCyfqe0zx+N5knv3IhU32wUbp2N0/V3VqH5GAYP+IQBFsI9KgcETR
YZGgoGmOa4hF2HKr6WzjxJpZhW/jbYWCKS5UD5l8VZJHrG7M8+8Z/YG1Dvx1
jpOoG9HJ8qHs3absiVPSz6aQcTQC+1hLLI64gtefVfOli0bzmNeip83SimUj
VOa8WJZETDE739a7lKo9otqBP8+8cXwYenC5GOaFkxqstb3OiM2AX4rtMM6W
83JNW+l828Ix6faYi9Z0TNUA3Kpb1oIuWvc5Cjefpsez0m10Cx3CDKSFgjtj
k9oj5U6twt92bB7PJhK7Rc5VbD2b0ju2f7xS5u0zHlH4/u3j3v3j3ZPJSbMm
eKLhHNtzG9M9m5dL6G2RMrxlSk9NyJ4dZyPoNnE+ERbxhjiDPvGfq/wlnbPB
Ko501fRFnRrEDyLyVELRsfRxgmueo9vFUQrHvllNNl9Y1g0xTLwHn3fMYJjJ
T3WH1URwU4m8dm6yl9do63OxA7/BhWikMzDqBHdWKCJtNp5D9tuYVZuFaEIt
NZQME7mrTzQCTH16AIopzZ0o/0aE7bv4maQ5snvWfP1ZiRylNe7UTorkKehy
mVg8ve/SX7uBelOxfuW+6IWqARk0pGyDqlU7MgHovVimuNgJ0ERpf+ikhPJF
mTKiKQKNbRB9+Cf0ItxhVeheSliCjW1Ma+mql2TicLhl+4h/7+Rx1H26NXUA
+TVbQlQUhcPTg205TVtPmnla53OIALpiND3Z0KH6w3TmLgrJLI03gmedkEpI
HCUe0hh8s4uITigvK7eogGWbbEmJO5VTHJDtQIf93Ndk9/Ay7+lActq8H6Qi
PF/f94K9gbLFk3WXgMVt5IVhLlRFD9F1xxwCBrKcrWuIi2SermHk0G4QsX/X
fwZKdzjvgdAymNIjcV+6CW5+ePSxgjKxBMl/Iv5S0anN2U8qPF1v0Ywo1BHZ
UoZZhMMgQEe8dKFsfbj2xx/My1F/dPsYd/lkzy4OoAGywvX4cqrfIm1rNyUg
M0spQfXY/X0M0JSBBc/m/JIVP+xv1OIKQyFPTv4Qn0ZwN4x4sRWk6NRQ3LDH
Ip/Mx88xfrry3nsQRABqkdQV0xOrqWN2nIKvuGcG8ddZPs/8LnnGIG6GshG3
IR6Y5BUEVuVubl6pg8ducJFh5aRuCuuPmDG9ko7Iz5islXPbdR58z8lmz8RU
hvpWQ2bj/OcZM+BVZYr+wcXFfi22TzaGfTessvQ7fOxrUeBEdPgVDekLtol5
C5z4Fx98QN95Eco4PDhZVTxWSNARH7U/3VhPVwn9phgnTZnQf7z6H0WXjZ51
xRMIVbuY1dcVa8lF+dqPc7F/2d3xmrF2B9Ei25eoWcqGWQFDdezUj0xeTf8B
r4RExI2ekxIRRB1ixJnIumF/CVadLYblOPfDBIyTF2Du2isNVgSs8/mKWee/
cAbVxRFsCHGw6XWc5wsoYtlYueGPJXJYiLywnlm57AcLi/3CnI8iei1X8zG4
qWZJiM+HRE/OJjoNkQzXGAnfvyJ+Hsg+fUl8+fn/7qt3C6r+94zdiXYnOZeg
qvkaRsSoEfUnGljrcX6cl0MImTr+TPtJtjJWc6XZAS+ct9vStz5LRkh8Gexy
LToZ2e0zXIOM5kXHhP9qZIB2OcdbY80ncfakjbpx0v6I3pNOQcN8pE0G+Xf1
9b3ITinuvv9o8g0ZneBdAUenLc2cOAO/LeTyYJNgZ5VVm7O1KdfkCOnyNkOo
FVkjq0GaGE1+gliraM0SpdM/1DGd6eg7TLOI5puXzmlr6xbxz7lgI1XvoV1G
sETFbuJYFnyD8IZNVxIGy1u5FgG/8VkdtdtKGRa0ojnERKtFuSxbI47TJvW8
UyjjQ0WmXakJK0X5Qg9GURdK0+1jzzNjtUqguI7zsXqI4Gmm7V+AzDsTGQg0
ketAJLklsufMGlhpXifF2ffYiZ+GTtdqxZlswqfzZhBavAj1uUkxo5XT8Bkv
q+VcaU9vZOPcF1B7I+wzxBFLe6e7O8+5qNIioMSQMvfsOEMYFANX4HUrMsTI
3MO7nDrthtMlRN6xgnVIvEW99pn55DLZTjY48iLW+bE85QuEJbuBYXPyKXTF
0OmB+Dlmzz5zXMQub3Uvyn6M5ivwPI48kHBpTB7Y+mhnoNLx68nwb2wTadmj
jL3XPJm68SvWpCF1H20Li5tiVK2X4hX9OlPJW6e0fUNkhoLWvUnK58dHL/om
qTM6NecYgQdE2Yi/zDWkqTDJMhIVvCXvmKcEYiRzk1IHQyBVTR/teC/XHZPG
UzYiYd2soX7ePZluTYrT33+L1wvp5N7Fdxj8A2nMXoqY9EWSTzGlj4V6/y36
rWzc7e5e6zaQ7kDiJ1+sFnE6lrSodB4xeZjhyLGdOcebN2meNINquiKmtmbn
kGSb8e10HvBQSdul/a4jUZHZrp5zBkuo7CkNsM+NFLaxJWyQuLh8gw2L1mGi
S4Km284diWHiUgp1OE2ZONBESJ7NZPbvKylHGl0lap8nHAR6ISWx4HxT/aan
QnSJCE25qmlRHLusM7jMm5C98LVeL9W3RBo+jM2GXRl+o6INM+FG1QXW53XK
zubYGNy9UyXmXiD/WTsWW82eUhVaTfAgUBltRE5YF1Ojgy/fFA84XxK78yQg
hVwfte/2oLlrTIbshJSMN5dI+CmZlPNxtHThpbajqTaXiFxBM6lo6x/geF6R
9dEnzZsMvcK56a4uH2/+Gz/6gA8Ihetu9f2Wrsl0h8c3OBWeNtFfwm4wcbI6
pVSC7JIyWUjY234o7ujWRsF1l4fuxz9XnPRhbmEWXyyenM+J3RTxQjzEYJBE
hz25ApzWgKxKftF11tBFEJVJLA8RqhB5ZlOkY+KjIG4fZqUdJk1VpbxeKE8z
NJ24c1lrKhic4sy1ECi+J3IhVnX5fN/rx5HXE4mIiE70uJ0Ro7QB5qjc9eDi
fL9uXc/Qr9qyUukXnWuoEn+weY+B/0AuYacfyV1mS2Xjj7SXjfqT+BI6VRiK
fQLlAQG2rAKvI41/RIOArY3Z7V+M1kJU5WvyZ87xbCaDlIPZJABLsbjIooM9
CkdCYo6ExBnq6kfwBMHzdLeLja66TFRHuQ6VJSlriHbY7MrkNyLldHLrwFAw
f0mCKyZukvGKs47gbh+RGpuEN5+TQiMRVQNndW0elpOR7KRnn8fPnxu5diSr
eM8RQ2FbY84iaKfzwfuv2CPEWoYRA0j302MC97bm6+m9p2lHGyelOzJvZ3JJ
mvS0YkX0ydSZrx+JZm8/PT/dfP6j16I+iGUSXETeTQb7WPTc5Uq4yyZxmCbz
kqcmqA8QmUvENCnVUbfIxV1Et4QjD3JdkVxEa52k0AdpI0koN3OO3I5azlY4
NsoynpZN6FKB7UkqaJoXXrElZkmkyv4KUdRpIuAjOG1jg5A6ibCT7ou7K5yU
S5rD7yT1XhBeZdvcvMGhq1lyXSDEkMgpJmWq0fnKgn7+HaKYnJyd0K7oLIVF
0RmYXVnP2FAVI0iEiCkvRhl5MalSl6gQGZOCFMEEbstnzXYbr2BnciCXrSRY
R8wkr0l4Y9uj6FquAKbCJoRqvjuNaTYGZohWQb8TguFYIGdWwcCp4q6/vO9J
aU2kUrsXOftTqUSDvTqIGPmvHFlA2sw6jMHpTomvhj0bjSNR1Y0T0d3g4imR
pMOqWT/QUNXbhzAJvWhDVfXX49qUmnzHFbm+/fBB7ghPNxpnE6M39efhYPXm
MT3nOBIomyDfUrNhxig74kQhz66CS7fB5aN0MxXG0V8gy7ElTsiYRuq2vOQc
C8t4er563PNK/gYx9aOWyJk4/7G7F2IRfrl2Xs/TczgtfYz/8/OjerpPTsy/
+XT7aPKZPkYR/Q/vkGSJlQ3rxmGQhObmPIKB78cr32/Mvw5VShNvbN3K/W55
sG0jXe6DRRrYIXm4v7/vUjwWZI3RRdrLsKfLCizMe/74XKKmHKestFUZCgjg
VHtR20sTPJg70IvVst97gnW/7YPv3j5df/IT9Qaf9zn0I4sbEyFCORMdEVaq
hVPqgFBwYuk4XTbO4sgqsgUyTpmegTDNddV9fn+NNKZ1HHFiWImCcouOYfiG
jGrkqk33ggHdm/6lxywm/l24CP3qU/Zq0akrH3Rx2TqIaDuBB3QBpK/SPyZ0
j+FqtFBNOwjC7mhRNVqRJandpgOi8+ScQAyAmNzbr8AB09oRe+FrqLEsjZ24
5yRGjsMwMYADQKF8/XZgyRQOe1S1DshltuB4GUJzUWsde0wgen3D5aXQ4eF+
kGRfUEuxWgyx1cGMIss8JVLSQXrBKHAEVZyZCH0/JS7brHDPQl+/bG6Qe2be
BrILnDHWiv3geRUelsuAhCpeqAWoNdugFZXLOHnSdoiG6taS+9NkP5qeVN4b
EdStTCieaE0amdQRzSXHEgnJ9JoRaUmD6AY3sA5qkri0B888/6E1B/9gbBYE
VqOENJt25RPx+o1Akz+VdAFKbJ2KymQLc+4gGM6FspyryE9b44JEpqSJfa91
swOH62aUzAVkuGLN3j8vy++aXwJephkqsW739nyiRYbL0heNSY9QBa1GqmUt
EkDYWg4uH6f519l8YhIwLcjgq1dZK+T0ak4qHWWMosgxZ4rDZQYvXV5/Z+FP
mwCdZtnKCDHT25vGfehRiKqQMSN0yN6UaqHimeY5ItLGXSjKV2Jla/OOcgkC
SZppip1jz1bHODPq4srFutNXf0nop9yVcVcHnosRK4hpHdGOL+QyaBqIhCHk
lqk1Egp9n2b5qsnY5pulzWUD6YqlEjHv66ueMipvJ/8y7m0ZPiotbR8CzwZs
z5KNIccZiPiS1q/DNNUBxzEkcAez6nsBg1BvvIsU+0SRiD2DpDeuKq6Cg4s1
5RTnIu7QmZaThP4Pu9zRdEtVh7owVItpz3RnFxLXkdbRSzpfafIq7Cnx2IHu
tXiFZlLB+5cvWKESKdMq3jP+wHHbIFuRTBBS02UCUZdtTVagBSmIlTetbZGY
wmQODUVcUigLd6+Rxbsp91BtFTCVKLx9xlnDjAumDhFXwQZy0cMcTke4StLv
GccAZC5REIRRlUcMBCEe8VPNgyxVT/rYt3G9Iy+BM/ZadrZNdo/PIMIZtNI9
RVUio22k/LtsRCAVKO6Yp8OyCjNs+cgln3GPrThxS9as3KnndFqVr81MPP11
S3iDIE3oZs6vv+GD7zu+JisTtmtZdWKNVWu5+vrTaBTE7+hu9v3Pw/CVTjrY
94ULLWR15up4RCdRwtCtj2zrQcBDVCd95ARDVKCoLi+3xftUAtbaMgQ4Hp/9
gK/Dm/N6o8V8ACFJEgXdriBHpSeEAuYTVpdtBjE48omfrYY5cZOGK2YkuuZS
dTYTvThuTmx9zsYUHfsL/JRFxuutU61B2VHJwK7EN1aqifKyzSTgSBZwLQlb
1dXGDhtxS2rkG+wyb1S8SB5K/ARp9qlsRIl+atfS/fxtI4WdTJ72ExqZd9uN
KyVJyCxVGeuBHaNp/Gp7wIkNYzGAxzk76Wa46CQPsIF+i520s0InSZ2n14Sc
XixFy+rgtEnUFpIIeZ+ty8LiIzSqFGxlG57b/mYFoZVA8a2t+GialvupnSZa
hillEYoaX9nnYYv3FQMIPCD8gs3JfsxI6TQCBNIHZ+bqj/wV9umPW5SDiOBU
gvG04IV6CNjXjltIKiW+mkukBqXwuasv5TObA+khVLMq2GjZwvhiUQbplK01
M5d0LgnJR25vYl+STB0hq/bEd4E2gGvoOFJNt59IkisuJmY8mjCmGSKhDiEf
wKKBjNwxu9eR2qTXlw729nnTkBYh7pxoqLarLeCNajFEvTMcBzKlEN1M4fdX
xUh3F+LGygOhg/YjOI+Z+7oFBtEuKAUyaQ9kIfmNH0oXFzZjcl6uxvHTaEbs
COZoFH12BKRU469RFzxvKbG6V2Sw93CNxB9iecmhfLZClVVDgkeqOcxeQe5i
WrWfQNgjKP8rEMbYgzOAGahGHNl1uCo4FWeg09/S3py1m7YiS96aYNp4jnES
CMHKNAbCjLCN8zIdi9lrQSQiTdkk0RbsBU5sc/FNNWbMNxdD9y9MX8ge4V2t
NvdX4xfQnfrMk+TYLFylB0uTC1bi5wgOjR/RvnGoAfKFR3KJ79gWrsEi/iPb
ddX6kq9XV/7EErDlK+NSDN5akDu7+rpTtqdIPjajAUeGIXvb2zY0i0ldgBiE
pG00Xhf0Y7nFXWG0HEJZ5OxOZwaCCc5LLe6Q2OLKpWtub58yKpcq34WdAp5g
Yv3h+ZkWNvo+hDQ06d6TCj5GtYk17DZJh1xGWLpUFrbNFiSdMCfxTtHRl4ht
8Gxn4TJpunuyDiSb84V7kBqtLP4oQUvaid/JEtPso/TPsmIDfxLQkZ1RLUYV
KlQtWf01rRvz0jP3RhZm0w8Ihl1lgT7JWh1NeK7RnYw5tRNvsseBsqXTQC2f
cWFivIVceTfOB3Zj5XUkIcq+zLbgB2A1zPMFLrGnwZ8/DRiAq+/5VhA1DYpy
TzBxAOGjw+8h9QB8GgXx2G+psRAHoOrvdBg7VIu2qdUN0EY3TBEON0TOILEQ
wpWu2JOYSA0h8UApgk3LwkEppBRzzOPVCPlELJrZ26fOLuyT1D04+s6lrEaL
+VSZaKXHr2T3A4EThMAjqYZC6ZyyybJKp5lQH0gt/pyx1rGOopsW0YSpqrDk
bBRYw1d1X9VkDiCI0sLeBUmA4swkYYQYjOWaVJZGAPBUo7oG4VtKv0sFDSrP
GeVgzZ5Tn/2l7jMTtMTQZ3T/kJAaGD09GzdirQ6JXJIKuDmfQXxpgBKViA6u
CrYD0UUnU3c98XvO6TZvbMQ6Q6bLsF0apaQWKdwDq4nCQgC4IImLQYa585oG
Ns4gjjsivP4PPqYOl954654t0wKsYSJeaS0nbjvpwzhG5C8ZsFGYjdDfsR4G
hXldJnCVAICDDg+MGoXG+3v7XHC8/41ng6kkX5EmuUzhcr3i5ARWU5PHspHM
LGChwGkHEkP1w4i0CpiZqdXqbnzFIYpUtknqG12QQqE6zPuFVHdLM+EciJah
slmlADN7IiaOVnDW7O0EaW3UJSKW6lyCOJACxYhdAfgT3R5FiD3mrawbQtdi
3XlrOVz8UnBcYWOZurbdNV5QpCRVDrJI0pV8sgIbYVLzgSh5hZgwh+qCak7J
4yuQWsZ5AAAWM8tEcuQPOFDM2QWinvksVcvc8GTJKwT/SFfjvNyTqJRVdYbr
svUoHsucgwGaVWhH4pijBi3x3f17OpuALLNi8Jp/z5eAEWNEGPxr7x5imWbt
0zxY1nEeU1g04GqX2X2WKhEga07vt0nq9uRdqPq1gEgwQKj/ak8vGVQjX4pf
xAFFwSxxWtz4RWUI4m1bwS3wShfZ2kEWmhavwkWKVNVtIemzPKxoXrXWxeAI
Ay0syPFjfchdEkcXjM+Cs6uDakAL2aaNB1arV3S5I4lPwfhhZ5vmgjPr2dPa
cIugv2ai2Et2UPylFsW0nSeyqYQx1UY5doWdWZIGwmJ4a39w5FKBwVbuPJ9k
CYsOpsg+/r4HpiqExeVWxDEQpv8lbYUPhxcjllRBVZX8NOXSm9Zy+Xnvj8/b
Exbv3uH+wUFwN8ulS4XsfEZ6HhcAXbXqlIlyvmbDhNb6Sky77sTdz89XX2/e
9zhtQVwTJRJnWJRELkcmtWI3jhQtAo+M5l5pzBuRrQoZSKSaNFw/7iCw+BrM
iKdUUOy0gloolp01nLOElSYbtGsVZv0gMi1o27SU7Id5jPO3bq1oUP34v5fl
oh8bYsfGS0CS/ie8MqsRxoj08nu6lkRtZdwWcgv9mgVcVuyxVPJlNFZt/TYv
Z/NJq6t8hGfDpS+lMFHKkAX1aFXXDuJlw3MTRPI4GcoD2SEg4ZhPU9GFmscK
ChNxZY856jWMNGph4FklthR2a5xlaP5rtRTzyjlrNv0y/SjdSlwNJz7YJbUl
HStfSA2R5nrgeFvhSudLt3QJx1AR0E+8R0gWzQZJkHGB6JsmcsDKtrzqtvje
a02s5jreOn0VfamBgwPUCWOE1VdMTjmcuwDmecWdrMoija9oczmVHzf5oi/a
baATtysW9MQ4i1uqE6pylg8RixJvp3ybGYyRQ4CAzITEzSyBGpUXiHfM55Zr
usxKdVyySOWfzSTGNw4AFYIbu81DG7KdZF/IFJQ4Wcp3URy3jvIwwUbTkdUB
X3JIR3zZkKYckHgReZXuYNeOuWzL/iR0xy8szRp5FBrHEX4XOWkGVWfE+toO
c84g1IKrMCS1I3O615toj3paWsM8z34wRIBLI4rnYf2wPCUeLHcLXV4gNG+c
hax4El89HMaZ1V8FhdPlJNoR6+prUrK/p5x0JS6l3Q5yueRcZMYacaPsNNK7
/YZbfcb1BW+VGHTDafdiCSSCJcmYoS9zy11LZ/Tzp8B0It0Omvy0LMdhHDLd
eUZyCKwZbNNrylfEMWiZZxSi2Aj5s7bxxqbXgrVXi6kgUXZcM6g7KYcvS5ZZ
DjCA0UP3PO6F0urW7EZW4wbjThIo6dPZf+G1FtuwogNA8m199ywFPpxXojWc
Hv3MDk40f4XJlfg9En4zacxCVNVipxJxR1RTvZCyomBBtbnj7L2WB/nC2XOG
oMVJVhEjd7yU1c5deOc2aDPnkJPrp/CYK1x6PvexQI0kTFbK65UM+PHVcgD/
skh20gZy9+eZqf0jAUmCbGXdrB5VUGS9aAVpsxOJ1kX/nHK5pJAGc1M/aKSO
1ZR0ZcnMMe0kUNfJtPU2KpfX2tVX9waOLbWMnLZU9VcyLcJL7b2+INxQJaLJ
cdQDoAya8KyePMljr1ecTxbPIWyBu5BFUmoHg1SyhMsQp9h5BxQYl/6NZFmX
R+bWglurwv/IGAQmt5HIkBaRm2Jb00obYu0T+uNgDAthb0KW6jQrvtGkvn2H
v4++WU2JMr9nsyr4lv/3Na++r4rpt+ARUdVuC4VIXL/boZuJ20C3fkvTYnyX
VgTfq1UFVz9E5rDZVKTegp+wNAOwjhnMDVzKhrXaLb8zLo+rTDI7WfLQfCjG
wmiSrcbC0Sss4k9K691mkSSfSWAfx+fvysaE+WbvpM8gdid8NLib4LXBoIMA
hO2hjSsWPxnYiy+GYiSMdL5WDcoqbH2F623Ru1FHA9IoXN7/MCPFr9DCCzY9
dRU+QCYFb8z/pEqENlUxrD3un8n81GahRm5ehlXmXJmsc8PTOky9GoKbBQXY
XhXiE4ZkHGdpCBoAOAYWjOb5kKGkEIWzSjmZuX5HSpDVlYmnMIjbWaEEYnBK
iTJMdwh8SkHicVE3cdv2+ihMq/gOB+op9KN0nJdSm9QPlyevB1ZdBa28bBAc
Bygc/5kjD5wW7AAaWeM83N8/30PvLZOVDE2oKUa6y3u7z6ECs/glVL3a3zKC
PP82+D3yv9np7lIe7T6qnOBEIR2M6Wgb7xeSC/gRrKcaEj7PVhfHnv9wPr9A
0Udgwpm7ZTEtueKPY3NcEBDf0bkKLDZWeke3be0uTdy9u/vUi3/+Rv/5O4p+
+SgZLGkVlIo5SEtXS4dMmIAGRFSBsxG10IGT4oaXLJUYPcMLHmFuxeOpL0oM
MysgkvCjAtRyfVymj+PPUeD6drBI/DuhZoe4rOcxSyuGDTZnNv2sK8neApqj
SngvltAw+kAQmyJVqRxJDNGFVTEHRBTTxZA9mZZOoaNuv49nBatmYbGs10wx
BXk9EdhGnv1Vcv0SR74sImCjsfsxg6Km0UvdkLHuiL28plnCy0sc9Slj4hWO
9vWjnhDmzYnRSIIxCmIAH2drS3oDVuzrGYgknCPW3H8RF367RCfv40M14UDL
ZI5O4BOeCu6lqO4hqvYb9oRhRLeR9sJbiNCDwx9aGkLTpsdW4DhIDGXIaH8O
ElCCF0u4UYJcRuF9dWk4EPW0SUOkDT2LeqHbKparC6MZYK0ZAFqEM2MsWebN
lbha+0Qc6ZSRT3mJXeewcPVYiuUhMWUZqNYaGceb+/aGITHHuXpe2aa0TAG5
qj7mr4m1pO1HREl5OaYxWs80q0LH4VJOjh5o+ANUzdPtAppQt9SVxC4sOMAV
vaUv/JDLjKJ/fg98bPmLQutuJDTI8cYATdtFRgGIKBGJ0VMrqGhqii9wvjvc
DZ8EEPr4fP9wcHAyOJbQXHdurKsXOdbtE/Pez1dZU6LiESxO9Zbu+7sb2o2v
d5efSAFxYx4IlND1zVX85e4GVHirsadPz5xsE5YuAYJRLi3um4O5w+XNfuR1
083GvXdSJH569/D1kV719aNE8zte2Hi+y090v9oKHtlEpNEv8V7j971O3D2l
BRPHgyuYTqdwMvkEBwjbmxfhrtmpxxvmwluRdIAd+Id7GW/tZTRcixpr5jVf
sTFHFwUZ4OL4giPy/so4ydp1WClgUb32JdPfox0c/T4i9cjBclt7BFJah5xz
VYuuE3c/Xff0Z2coAmthAR2FvWVoDwFsHpG+rGUcvNXMaVz0hN1OtjMArbhc
lOIrrRXH7FF6/kgTQ1fv/TloAKTTOd0/deRvARL/7qWT5HZ9PDAGvp2WKTu7
og0AH9vIR2UqTD3tIzQi6bjjOMZ2cpMUO48PvCtStIjhkA8lALPbAybv2ce1
MaydUueTHcq1O5SWPeDeYYSeiBbzCxInAr8rcUIg9uCA8T1fo4ROHgYhpxf4
RFMYX07Z5K22a/fgeM6ld6b0tw9UVOOPOADbwQMmaB/P6ID3cR6QnF6HJvKw
ahBRbr0SURoeAg3paO4az6/DbhnJlZZGffL5eN3bq09cEPy/sF22WyAacJu7
x6/Ka57YjelYwlAKxg/3D4+EpDf4kL1vnCWtVxDP4TGZ48zSQIQf42ax7wZZ
hkLaCDQJs/RM2Nj3Xfk5xeR+FYzDc6AxVeMQcbIeS3VC12L0nZmas0sMgOTs
8NijkZzLPxzYG1ogai4CseTn26er39u7tL0r+OcznuMWUpzYGtwPAA+cNkT8
s+2dOXM7kxp2L37v7moQ+2YAwORpXjaMTkWqCmmz8e/lcgmKUIADzMKKLiJV
9OoN6IANyICs2qWtbWNLRrVL6XRZ5exd5UoSK7llVJGaJinqVpUNNdNM9Sik
Y6l2AV1ix5vZZRk6YdxmWEUgFjlwIvNXh+NuANwKmniaOIsFjAvKoQhMd0Ba
aQG9T6BlOTVhEqtQZaYFeZ4HRRle/z7gY3WcTWy++SFZzmGxJ6vavqrXBUU9
HLo4APoag938adz6ady12yPCcmNgUVnQWI0Onz0HEuAIxV9gvzuQe5QTsZ5i
jpTIdzUJ9fBPUirc1zzh9tQcuefKMdHiE5cuOKb3d19unh8enn/vfu4FOlin
r56mtohY/hM8z0mIniiJ+X+utKbB5L8kY4qVr2z45EJB7cWFFADTc3PGMZPk
UvVNcA2ZGGDfdB1ekbxRmJco+iAFfYF/CK79pcDQ9f3+yOYcnfPmqIy4v33f
mrSpk06VVBxqrXeWPB/ZH58sqf1RPdfbPzzx/7g4PA/+cXSwwQ+PjpkffsgV
MFwlGO4KX+329NGzFQP4AyNF+Tn+MkdvP3+w4RuOTo7bvxARc4fGG+2Eh+7j
3ZWTYJ8f7u749qv6/blcPefFRyRBfOztUMQllUK9dw9ttdr7TAovzvACsISo
xbNr5TX75+i5rSDV3JQDhnbjHwyS5aVnDmcBhOBMYKsdT8/bjpvOu3hVDdPi
neJonRyfi6bhACTk+1M5WwnyrppSyFaQuNB1WV1lrtbAP6MDnJ+e8SE/OWSE
vivVMk8z57CNEH2ItOBC7u+Ws5a5o9NMdqyKtvbxzvRyASOwzwfB50PnH4us
h47U3UB3QOQrk1RnVw6TWHcJBXptJWCAXzsjBZPShi6tJAwwttdSSEvTpTQ+
4PqG8ln2SfG+bP3d6YcCFvnF+9N/vT/RpruOt8c9/8TpLDS133G+l/7ssArX
aV6xO1UbRhNqOfXorYk6Pve/O0Ga0eX4BRs8ju+hYzCjbmWUxt3L+9ueP/lI
2c/RKRyy0QcBUOlLSJwGlYvC0Hd0j6awR3w+9em96swtxoYOziAU/PrB12tf
pVXF5hq+D7vPaXFu8shBKWfZBAwJjaAdQ7LN+V0cPdzIk5UI/osVVdFLBrI2
tINmVZ79IKlDygP4NzKBXZgDI9HP6s2MJ8i0FzVVPLY0FDnp95MZ49MU/gpJ
h+pAYWWEZIKpH0TzJGWfM2QrfdGdtAX9+pbKeg72D8EasI0+fiZuqEk+XYnT
UxF1rAdCCyurK6voxaHW5UGKoy9F+IeKhCc77NgT5cu0s/HUo2G4lICZUI35
9NhO3yrNiFzUMu5ce1dX8lDB2Qs0K+50SR8uR+sRcEg/VulyBj51/XB9+VGU
J2RtQxW2tHCHSxuJUukCQ0wQpClAaBknsr+1PBloIm7sDv3Y6XNYUNfaLnYq
2yhhIovl6Wt4Jmw1THvbAb08V4BgJc4xR3+BZrZwNjr7ILRcN3z15ovMR+kS
d5UHwZr4a20dqgxwGieCKgSkaOLsolQUJDslG93cy1a1j7CMBiOqzDUkA1DY
yKe7ajzNpzEIa0QNM94bAnPVQUpmiLQ8zwT+emwuKbL59ln8YbdgRWj45h80
Zqd904ZftRbtNE7/92Fhv3/EYsAhNSMFMw1uSAAatldzIydzvJa+Q4PPs6Y1
z7QMULqZdi5d96hWDyfbaOmerRzhqe70dX3/TM9t7eADb8ZY/IN8JzjSw8vI
BENMCW+j9lx3eTSnjXLQv3zFIVVcyzSnzIYTqOOwVofjGeyKQR1+ztaJK9OW
NoPiamTcsaAawCVw7sAWUx6s9Bd6qnEL4OVuWvXbeWOYgVwnjHw2duJHYh1I
MhYDcehvB3H8vg3EL3ImALjzHV/4Mu/tuMgMJIf1MFwlz82F8UJTWWy2zeu1
XXfuocAY259Vm0g6dSPebUjT1YZeAIZ4+/Gx5wVwK84mGpoPlt8+3T5FirV/
cHy4A2v/jQbif//dYwXt4enxgyJ4HYmJ4oSQ2h1I7a4MD7rcOFhg9ewSOW2w
A38NI8nkkw44Lv7ooTWN54kV5KshzXC6OLYalqtN9wKfuc926D6K83yLw1uA
072UbW/RejkobQh2pv1yhogWT4kfbN4yJ+Ytm6ZdMUv2c/IhF9lGxiWjxC3K
Ye4X3QLTRsNMzu3U0hjHkdvvEPpemkVuA5auswrjSgYDcxq0QJyHsEeC+hPu
EK9VBvJqQdo08IrzXAINfyAdQuHJ7LtNCxuySinNjH05IyVci5YS5+TgqHsJ
UsYjjplxXS3q90N5ovV1Ns+uB6d1taHqr7r7evtxt8PqDiMlX2XAW5yPjyB+
XOVcBkzXb/6aT9lLpUh2Qfym5cxhkDC10rSKo14N/8zQVcuyZFTtLKTPt09N
YXe5vJ/ZCIgp2i4+y1uTlIqocFd4F/Y0m0TbQfHFjdLxWBV73k5ujQuUSDQv
FChh9aNjSDbucI4eVjaMH3ovwsHZOQccnEHElyy5cRMPb2XQxzJIMroqLx97
8XUmuW5sRdjFcFoxPCFmtWBueqSbTpxDYVise+da08ID+kkkYA1+YGcHWIQ5
RMdwgkmuNrtbDfxgwhTp8jT19w5BGkI2qxr2V3Ez2xaCA8spLUrQqnj0ocp1
/eJ8k5dKHWngjkG7tWaXD4iUWcb7nkrq71TpNxaQQ/Q/m4o2op2MtFo+igwt
+/MNTwbn4dw7l4+P7si69I83XTzhOX++eXoGqkvQ2BRSDPm9b3t2DvbjwwPY
UP12+rlUGoSJQaxe/4quOpESlgb+LvZ93o/UxNZoxBJ75wWbWZqp5yx19BR0
tbz6vijos2qeUiBAGgghKlRowzlc/Xz31PoesO2sPJAxg15qwEnirpPm+Kyj
4PHZasHAa+hVrBhwXHArT/bdRtsQ2Q9NQa4BGSY4Am6wLSRWa7jYhZOD1tnr
eyx/VihbzfV8to9LTOhFPubL+hXzNOhRlrqq8QiObQV11R4SqMpmCpQU9ISE
k8UfaeTtW6mas99KjUxCb+Dcrj1LuxiVChKeMtxavGqZui1orqjzwPzZOww2
2MVbtPzwdPXwGXkKwhZPD44sq17haQ2Y3KXp4noJx2rvgp2dhBe4dKG/bT3V
Or8oBCGkuwAC29K1uc4ngD9lhwRuA+vPiFyPFHcFEpfj3VpuwrB0+MNqmI8E
sQgZpu0dDMjfZ3/gBMZ7GZbOQC3eWXpPqgKcyofuU/f+8L63URzUj4KEWM7C
1q66QU9HnmpQh8JaNX32rpCwiQKLVYPfgPeybrisfaNRUYzNQEJ/HSSVPN1c
CTl06dObPO9yBZ9tY6wHs8NXdAxBmD0kpg0iIkbTi1plnwFQLoeG29Fc4d6O
Ut21yIv4rfPphw3JhQakOobht50sk5RbMIGnHY0o6AqQTp8uzXA/gEOczSP5
hYxIT6kY3j+CYd9aOef6meWN+TLM2xQen3VgKEXQbHJ/fLzim/k8X4KZXSGp
NO7iRLR1zfds7XDLJdGM87G0wQNstjoIuaqxF7WsvNCU+/x02RpZUEtg/gXz
pT8aik3Y7Mu1Ki0n0c2VhFQwnli5C6mUYYkm7VGqbKxQ2p0Ax1c7+3CIj0Vm
ewt7kWXMA1bDmdy5w3zT33srLddyMZofo1jtdAeKBvBEApa2ulHhSp+FQKLo
ZkGqglWvhZWwbRwDIMZwFp/zLLR2GkFJVmuDyLN2oGk9p7UuJJzROLvdFJsj
1ZFwN4S1yYogA1F7FbuAo5XTqy3dU5vJyugBasEZim79LQtNs6BJfCTq/EAT
dT/BpLaNQpdr8H2Ak6C1g+BNcBPP1oq6XrvWDC7Rw2y/R6391uMwjZiJ8L1l
lkfRPQAlNlrLhfABRxfHjEHN/nwnB3QLSbiODfLG1V/DAszH43k2LH/wMeaF
NNyALF1V0hJ7NM+l6LCMGbIUxca013Qk37Nsmc5FnvJpqjq7Zm4mrFwjuoUl
FSe44NxkR/Lua27PLgZpU0aWAOpykDeBYWsBl1QlQ3S88/MzuDuE9vgsWjkY
AHCdlZwPKbnxvCAFwpQObOyTMWPV9/1xhydXDTcLKReD6N9t5bH8r8pyuQl8
t8NkVtEwjW2bPDHLbllC4nHG8eW3zzdX/+O3QzwiHPX8mEPkinxPSh0cFCoB
zWIRDE1V7m3fiKhHWTXkJGA6UBxVsjFXEapcTFVIzbrjvqyPuWoW/lFaWJ4p
dizatWMxPTwz6ORAXM8yElw4CW1Y/yRC6ZmvLTrR3AgeYS303wUeuEPIULx0
iZtoZ1e+GcETLUSNVwHNMgHKz27Ca0jeulSsiWuuA7BvDTW5sdDE5Om+x3aL
1f75uzctW4k7tSZDOfQ57XYfukBSTi7x+A9t6Ae2KavM9eWNuKUwhx1vbz77
vOCwRMby/Hl4X+RtKBeq3hUpgJK+flQMUK7Dq7LMg46LEurf0Er0VSih1BId
tCFu+AjnEbFjhy6xgPmgs7O0eQtq/9YhHJTH7PYRj7RxJQsAr+KUTt60KCS0
rm18XiT6XQILzviNgZPC+dkbOKewOFAZHbZhZ6zcAQ5ztdcTKb6kNmIDD21k
K2uWcx6qSssFQysfOUMe2XyR/uCOWVIK7hEJ6kB1YKec68aHv5IdwM7PWFuv
EG1OGkREXFTOsD25syevzPpNc1tAFK/uAtkqF9mrIoqwniz18aZFBb1NwG2d
Fy5oCdO9evxCSvwsRzXoHb3yNUc6bl4oatsWVBtCuwFpjTg9OsvQoHNI+08a
OhIK+byZgnw+lAHSRqaQsgpSB90zxK5f8GW2k+Ls/9WSdLaxIBGqiiQOHQVB
UjDnVn0NcuR0d/e0Z9QzGMXWcaH1iiFP2LmR2sdQt0WdWguUofUos3Y7Wnq4
UbVZZHjGY4IxKblTtv5VjhBIEQgKBIL+OKnLgDUJoZnh0k2vVv+m8qBW+Vmg
C0d2jxgkY2O7BXNfyiGrlDssBFfBt6/0QJORNO81scTbDVyDIEKpvgIhaOcF
RjxB42RbjnsfD+j6siMU2bMxqvBtCbe8Z/4rrvdA6701/Pm+ioKw5oK1l3Ai
reve4oGOIljKOJBIQxRtA9L73pGCwsbE3mXUUnBJxzW5xt9hwQegl5oHKmUD
7nCsiqflIeiKBeMiTzRZOIHjgEn2DLvOBV+8PbUJ3x/Zux3Q2maBjlUmqDPG
330N9qkgSvOKk1ZdR16iTlw7KW6GCsQFo4FhxKcI968l2iBnySXAzgJp/c+n
RMVdkqyW2Wa6xVdwCdc03o2aiJGrPXDIQlL0SM7m+m0U/PPvKGLVxbM612sU
26zSMd6UjqxNcwU5I4FrTY93yUXhOySRzXsAXNmaNcOsHN4rrbug4xtpGr33
2LEvQcPeA1UH/Jxbqqygi1Rw8xkwOebsmm8oTgmmTVKVK6Zd99e8HJPu7ST7
pjyHll7C4uDzYWhMj+/oHEKmdeXzeZKOX7gngZg2gIQ3/dyQdRoXRFYy9mXJ
bLrU7+iI0h7H8n31lMEK2lRt4Ww9mzKij7Mh73uPmCIWof2qVFa5jRS/jjCG
ot1AOzYca7NFGL9441VEnt1he65mIWN2OyZmBTzoFJhW0g43IEVt9gD3A82f
9amgW2fQdz4ABiOGOJ8rcH4TzsTqzcLXNsEgkFPdkUw/zLLWAcbGfAqUgGA7
WdUwsmFeUWWkJqDBM3ZiLEPpqxjIx4pdtd+YuwM+pwPp8LrFHhFbZoAlixmJ
bEc+akB1l4Wnp+B8Gk6Tn5WSgFLqK9y5agm5ZfhZ71S7iU7pNq8Ci7oWIrb+
JTUI4MBKZ/p0jLxTz8mUW3dcQo38G8lMRFORUcUrnZh2QDcCadF4F/2LXIf5
HkMP5bXAfve98HHRR4YBU4zLIPAbNABRDZHLEemO0PMvmlrkVSznii/GrawA
xy1aYtjuZYv/2QKYYdQtfQcabzALy+JOnHbDne0FQKUdDBBAuP3TABCOvYHc
XbyjVqHDUQjNwycyD7Uu6XT/jFO5vYdV6sMCQ1Ww4Piuh7aFQgyolumxTYNl
e47Pod1a7ARY5aJldQVtJ+NwEX3RU4NlW7UgS+LpftNI9iq3QALXsTU5iTZT
feU0LSonbFV1U7k2Y0D2jVLngVdOToa0zFuwZEnRZEV9z2XBQY0K2Tx+ZyXj
v9wWAwATBdvC56O1dGCXaVop7PnBicZsPF4ra2HBxDHbrU1BRMT0gEcDpW37
Un9rqyNy21kD1eIJp4L8/O2VqOnvKFLX+sGFz2MNjKW3Kra7ks1FCkJPS1+C
N7MPOmKtdxB/3WhDsIUowPqoJWXXG3Iz5d+Z4PziuMaaWUyy4obi2zdcNO4n
16Hm6fmyZ9lp4k2wc2e1x7TH6FKAux9Fde9ePtY9EZbDFVL5Qx+IMgL26mVr
YakM5YWb0RIk7DrWfu2SGSPckWUUiVjNzJFXq9XAlNe5d0CdBUxi988HBryn
+39/e/+AhFXSeQrcMy4ra4DbTbsp87GJ7mhiYeDvHQ7QCkuR7u+BeoKZ5KTd
KzKfJA6pTwEXmx2Azg90+di3mIMsK/DphKWrjObOFAl1itOKByKxbxtubCCE
EMJUuo693v0kMfCNhJHWDX3J06hl/gvkinAT6+HlwgYb5O4sk7DqRrWBG6uT
wkVAelYq3uKgsG9rA0r9ykwnPRoYAuL7p4mRyTPK0tUPARBZsAmAmyppXgln
U3AQDHlMteD50oM+SZiVrLpVyB+U8KmTZKuSW+0pqwoz0OtalHvWvNmAZzeq
7+5RCP9WBWQbLMRkqDUA4nAPawyaKvfzN1Ugoki/9znBARpdkHpoKZmeF3FY
xTmOQwMZ5kVoJUJ1YHCs7WS8IAchSF8LLW8XElDsbu8W0rQ3bhOJ1ANQc6M5
YWWTDcuSWyyrWWHjmDuf7X1GQuEAbMQwYlpZhzgNsvfFPI0DvwHdnzGw+cYl
suIy2m+BWdH4xdZRRGb2zOeux4zydHXsQU2hBagvMYTSaAUifN9KN06k4ALu
VrIThF/XzIzp+fxD3S621GuGdGPSMqAVuQpDBj1CTmeVJWBPi3SZoNjsnUST
GXAtrREUDUK2dUBD0VC9cuKmGs1UqXMGat6uE+F+oDJAD6v5oeMMrIzxmEz/
KCtmUmQkJZH6bo5Z0bGzoyukY+Spcr68mwFv3wK1zdz3sLRAKrDwrEfIwCC8
D/cPgK+uiYNVxopTSJRosypILBak2f5me4MimRwtGnvZb0OoK9Q6d5eBwc3Z
1lBwIMBai2v5j11ZVcRJsr84Q3mAuPNc/rrIq6qsEs48r6Q+cecDfC7I/JO/
A5KMDlAeUZ05kfwiP8g0Tzm7RJ6SFWw9BD6JSGihg3Gwyr+oSmdAdQpHUJsp
cbVifrDtp//R3xLezWRcJq+I7GbjN9ZHzC8nNuCmPiAe6ljkrrx41zb9oVBg
XZSSKt9kO7JctI7U9Okg6U2IcwfQaLSRZs5xAIWNVRgfVb29HPr5s+Ww4j1h
NfRv9chFATLdL1P7kML5+abnCr21sqesyDzlPyWfDQ/k4uAMNWjRrfWr2+IW
YqpOc3bVm7NKY5T6re9khFRVE+IobWBTgvU6zmFatkc2c9YrXGK/y0alniGp
U4OdF5fuwDYyr3Rh5sLsXH96UlAOsw0c9kYn/om/Pl1bleXZ6RGxMLoMQ95U
FnGhIdyxIT7zmquNlFk8+o9f53HZxkVdj5O6WmLbnzyiZCF+OIg4zlpAP6sm
ZMuaU+6BEK2bFb1ZXOPiyjPQchI+ayDRb5lL/VgWbw2F0rAP0O5NNT8El72G
G0Oz4Yq+8S9hKuSxb12d/DcTiz1Xao7allWFAJlrdCfWtLsm4vJt6bF62tz6
uIwhMJnXeUcIqmR94ZHXTdiHLynYXcBYo42MbIvw2i6nq/9/nUcdh2nbkTf2
9J64hIoNnqLcgAX+42r4tBqGJMZMEflh4PxESAiuE01FDtuLSQULY3FuWc7t
dw5A9AW6994T2ay0gvuOLZAu/eX+rtfpayMlRogQzWCrlUqVaWovN2jgm+V9
OOwFMYAHO5k339uxF2v97PGhpr3BoKNf0BgWag1qWHw0+x9sas7uMxz450zr
17bbghsmJ412OQZacF6L6dNxUZAzZDI4YLB6T6Lq1nhAysEkUXaLzxruu29N
yTWTO6CDOgLo5LzWw3WkOeZB2giDdLr+pf4OdXatALXolz0fY2hHqaKxVYYa
b1djrpVODP79BqPvqre9HXD+fGkv7Kk9Il1KwCdUQ5WMiU/X6so7P2VUBgsq
uNVKKk/DGG6TlF4w4NaX4noNT8b5+Ky3ibVR2qhUbBfg0cnQFNI6BOtfx5EC
a7hkkxbAlvTDEBVX67xAsif76uM6vXsYmIY1S7+ToQ+pRhpPNUbKYKvYMinG
YaGlg2XRbEDhnlBCwwZzwlTFacGEpCFlhkFPZRdMESa2S+pNG2WwRny+ksSg
7h1QhMpJT0Ny77NiNMM0tS5OHF5mrC+zhm7+aJW8nJbLWux1MdLp4zGvBB50
7AvrWYvgnovC7aEXN9MTLaHFgaG88DU51niOmP8xo8awLeWYGfLgouBNvsMf
8iICmU/sDPq7X59kqTlwPU1WI20xZ4d5RDSTawdCa4qgTq9GErPYya2ym4iC
Vt8w42ME+BAMGsybBaZqqvT2eu9g/2ivnsPloP9J6JukTtNpkpdNEk6VC3Ij
v7upX4jvarxqtvbKbGKxa+gnyK3NpdeescF7j9riXKVSKayyqJUA2cJXdZ95
4wzwdPtoPRKfSXaL47AbziV9hz1ENHGNltjEH6t8TAzc/6Nj2sFmr29DxHD2
vF7/AJrGu48vuQGlQkb+Ssvhl3+b0svBBBqrkxP/caROW8MRGXH/RxyUGLUg
j/k8n+L9SqoSk9HkvjkDh7bEkXXYbLtzOr8CpOjEe7FuFD9BEixybZ7kXUzS
nTBCEQ9LYIqRsOuM8grVCHQwWfpdft5B7zP7dYen3an5DcyV2DfQGTAiiC9O
ZUU9OLDIyrZatan5QvfBbYoQkTFnBnzRm25aREQ8bsZRZAYd12zptGpHJFo+
Oc4ORegnBbbQNPOV8Adxx4H1P7ZgsLk2ISA4RRRgYcPVJ/+5knzioLIm6p6e
kkpKYq+FGMuMup1FvFVk6r38SGNiLwN3LmE8DjeNoNK17bwE33+t8qbhJG4N
rNZSg82kCD1tzRHoLl29ZJ01iZwhKNpViDSsL/kWKk5maGPQVsZeU0YM8s2B
0xckDWgSkT7sko1cHDivvwurWAVRjSrLixdxZVtTEDrHbL4XtPCyLPUxrIGh
OvTDObvSqyoTEYKMuyjUOjgyaRnLLYFI1HDvy+D8yRkImNtkDaA733njs258
Hh0fVsSH1RLaLuIu+P0ch9G4s3uB0d1GBDAivU7AbLmAiNio9bCRiLntgyKA
h7yoNVlPR3Wk/FM768lVkNQDl6+YS00X6f0p4+l5fDZD4TT8kQ2yaEERxV0y
fen2AMX77967WKhObbZ4k92gUXM6bikOTqmnOy4X3rL0GG43TlTVg5pkrIIJ
JgpTNIeZ1WT7XBWzJOHbSIPC8u2EKoZoUoB7IUZrmc77YBXGUEa847G1CyyZ
+eEZWBiIUUMsTAbtLuXOyS+5Hq73zkBQ05/WJPurMn6kocoqqLsXHU57Q5sb
isP9khQ5R0+UPc0ogyvd9VTkyht5aip8JuhnK68r2BYcakahBBXqoAHQpryX
V87QrqF7sr93uv/7X7H0l5UkdQi8Jof3vRf0vALhGQcHnhAGXzVJOUlkKOv+
CveBdPdVxZdP3OUMD1eVtKbXyaJJFgsMHhPBStIImLrSBUoCc9OV/Oag4igr
gi+iaWlzwZZIkzPD0uaiF9TucAxcMc3BkSYbvuYuRDBUut6QLLjvNCARvW/+
LhfadX7XUiLcQ2sOVRL7lrCKmdWpleZxs0kUno4jS8uCK4+VqTeIpo2ZLx5v
gO9qxmQA4uLJwJhAtLllPtHMk1I/xtrR3tiaMmPzNUPWeSukh20ksRKkXGd1
LolAfiQ4LoTCQ//BF+J88B883n/pWYZ2XnGHowjOA66/nhtgkOASCA4xIg3/
oo5ktwNSVOUaUEbAwNdYL9iCpkg+XV1eX7regzxjFXpyH4Le8puNKdtJ7x3p
KQU+YGE8bsMbi+3hazFf8tpKM80q9RCzIbsMtMp+jOs6KWvVFM2/JGhPSxk+
FweFnu5SqMPno9HOwoApSKjkUIZ7QZ9PrYVzNT3zslwy6rosNF9koW6nVqCv
1dILxBmXVmvHO212V1+Gh3mcTp3koYMW71IIGsmYVTB15iUJtA1SjaQqANIg
UKVC6bwBHNKK2wvvyH4sOeGHGy1xy2N2QYT+f/ZwV1xCwELMNXNw/nvudrpg
DRfYccO1ZAzKLT7a/y9x14C/SO3hKlq8cwZI3JphOLhrTd0kPD42GBhi4nay
A/aKlTBMdnxgjbM8yBwJ+2GTyixwQ0D46ZIQYr4lNdGtzZc/OY6fTSaC8BnP
uURTcoWIFFII2T3ZMba/0QdVVG7/ZGuP8YjPUzFbgHtm8FGHWaxBmn14QJ7S
fPlYOHmDBXY9MVDWCSaWjkYrtlt30o6DYqszPnot4eJMEUZws0ZB3qqx8hhp
ULt7VN/QTzqlQ/x3DNiVO6E6b7OlVxzDOfj8+HJspfAnF3A5RZriVfqKPWit
Nu7NTfz4/OjNd5cg7UpjNWbmgvV54wv7Ik3e4763oYtFjwq2xVQAijS91gXa
JemADvqmcYXqGkXnm78io9lC1TRyLvBZiBhnL66plJzNKIAjutc8HN4jNt1e
6FZ1759vb3pxhoAplwVzogdf+4N4UWcj4vxZ2/b8+fPT5dPj7dXdw9W/O2y0
zieSdLP4cgGUQfqxCk2VmQKDCorHUeDXdBShm8dxyXauW9RqQdbO3WjzXS83
LC6DdpjaOIfOkAEU1I778nQJuD/EzBbabVkxhePudXnDkDxx9070gN4Ob8+k
pTtCr4S1fc9dAdGAipFCEoaL4zirOjVJcarSeTJcvE7bGTpWG2Q+SO6zwD5m
Qx9VP5Bgokn7QTG2t9Nogoab1twl2qhYCh1kxl7YN2s4SD9/3txfktURO1I3
Q9FhiQWTiDz32J4OyyX5ydP1A1eOss2E7Tlsbc+fGbfrqs3Pu6Tx6d9vbk8/
iA0F+8PZ+i6Gou5GLQgXx0nykgoAqLr3XBSiRV8uR4N/QkJgYpm+DlPSEKaw
BUwdDFKRL5lINrxSvDPimrsRtNL452+8y2EbYSmNzA33DhHfCRnU97fvrW5H
TdQg6u5Ek3fV9SNt+SfavjHuFmw1+5m2aJuuACbFEDiy60GLkIP9WFqEnBjK
RcYijVHN+5GrFDCXjSR8pbtBVGhNKhEFzcC76GUzPfzPnkcZsq3328xaom/c
ZHZsZL5lZbICHlGPOJ/KpQYHzk3bUDbL2yCBfF5uOd26nGco4kptJaC2vW14
9qiLY5N8dRdkcYnMMSrkCzpbEzB73EoJT1XyeN4YHlbc4bIb3h8yS7S40Wtk
fadBQcvVmVYGKGjuypL7gGvaFCcp7R/9/XdvYDGK0TzN60w5k9+ZJK1GM65j
0kTISBK7GNhaaBlPEK8UXF/uigWlmxMsSVPjgIYS3EhwcQo3I/MofP3ICReg
2SoL/HEyfv0GtcYfEMTGkRkm7dEh5250Pm+AJG5z8Y5kIml1loH1nV4AY52b
Bbdc3G7sftxhX6Dckom93wI4bMLN1jUrs74nuvAihEa26ER9T1vfi6ezlsAP
3UFZQBQs/lprkmpPitZXkQGDSJWJb+D8an0LDQT9q+gmSGmXxnkEIAJoNowF
5twpfWcYZT/Q2k/noa9wqqfkG20552XszZTuvgTNIkactj6EfToMIrux/jG+
tAkqIWsuJE3h0pXczdd9Jkd/DnL3Wsp7vW23mW66sV8dSX+CpJgCIorbWRpy
JNd+u7Rm5xz2vsyAK1nGpTSVRO0BTzPgNzSa2uScPGS6XsdB2zHlu3X1AyEb
7jBzSdMTvZ/O2GBQ9J8DPf8mjhyohUik+H1W55LgZ2hI0BmrlyxHhhsyjWgK
la5DGoz7hfrckV2J6SyVNdEV7zYgaxLTuSZgM/ESG4ysjdFmkF6biu8CqA+S
UF3WaeSgh8y25nKJkg5jjzTmcfna7vTQtjH1N1bKTGYchtxueRJLa2YyZuZc
goXFGXDL7WOIMBVGmLZEiTNQAnmMKwjZCEH86fn2+T8S+ochxF0cMaC5A6SM
JEqhEkVasgKVkhFm4i9fbq9VSzSOxFc8ty7Vmt7mS40iARoQc9F3JLBf9QPH
GZYsqlLBCrstWRx4zOok+YDzvjY8yKl7DkOYCXEvPMRIXGHrWVHAInyFrGnr
/w+jqp/u/8/A7krd8ws/nP85c5ywfdZWgTtfZRTyPYcBhnbNCW8TczbRbFk/
sygbX153dBLx1H8/3Xx6eviMrxUG55ix+LlLpEA8sukSpQt19rKljv1Qc64l
JoDLndGW395cmT7jlhxt+YuM3TirUojs8eHrzefk5vn3m8+fbp4DYjs6PUQO
M17CXAsn7iNSW+1f3LZ/KZg1Vqsl57bbvgvXqePul8enHv+vvEtyUQ5OBRXT
GbYbQLzi63QQOOzpUyLW2dWzVYMe4XXEyGnC/gDipV2PVYdM8zk7kMwV84Wh
wdrJ+lr3YYTrWn7tsRLJN2EQPZF5SHLA2p7wxSaj0tA3WcNVm8BEJdb0Xt/l
ad00l5OzM6S7sT5CwkZ/E7iRbZoBXedFbIaHy+rY1dissMyfPvzwrtuYGSKi
Q3MyUiGBBpD802qojiLrRXZ4dtACL+oEZ51vnPVaTzrQV5xjJkm4e0uKnCxp
gidBV8ZQfd5JXcYZ5f62+OPT8+XzTUC4x4foIeSZW2S2FMcoLUqeGpISm3rK
FX2U00lhd5FNiUG02uU6b9u7LCWDl7TUDobAeocucPMxNyQbrpEmMCsb96+4
w1HXDnHU0YCMB8uVdNgZSJQTbNIfGjR0iVvYl8g7iza5YKA3BDfCpcK6cKFe
K0Y3jtrV4HUL3truVirpBlNFB7cZOPgjrYyPRCvykVUfp7aMBadYKCHItWrr
r1eiigoRaGeNU4+0IImFN59uPn/8j+Th/b/dXD0nVw+fnm/+G3M33oXby0+X
iT7y+ebu8vn24ZMwa8agdhDI0qqPSKhjlpiyBUNTMxVZ1eOQPXteGSbSmUoa
mQaqu95h5LMNg4OXNeBeti2M8XbOeUG6KrxrmcrkzWIe54d1ktnVmSPnQPCu
g9iKP2J2gnbuIOzuuNred2p0ELboIH392IucC8bq21gmgrrQgME18KNnEz6J
m2s+DTUf4Jra7CS1w9xTq+uNtjWd0K6NfFVa0copYZLSdC96bbUnt5UmGrV6
b2nLFfxMkFAdLqfirXhQTohtWFXGqQP9Ev5f/BVB1j0sFqpDxP0Bgj5FIb8L
TsVgumrf+sX7/LwtoYh2rpVzuz2Ry4DCBeuzBS6keX0VFgQ/O1wbBZ0SOJn/
uPz0kW/lSzrnHKwSNUeaPGj/0si+hZejYRvTj2ir9PKG6cIFnpWnWXm5sSfX
JCXS1ba6V2TFlC96K3tFoCFWS4RbGgYn4NL9qvyLaF84T7KzmwS7eyWV/dL6
eIC7ffA4UiykNnsesC9PTVV23HvIlsdL0qXQgZ0//K1F+wdHKM861p5GvgJH
vLqglCAt0GAJ+lELfEGyNZBGYslXm1Xe9Prbp8eekFw8XhfpQn5LKuFUet28
JbucVsQ5R6JAjq3kH7YgN0iIXN6khevFLzqJwz6e+A6ELMBmga0WdTXrVgsG
EYQagch7mpdWsOuPQ2aciqmPs1moeegcGkq4G3YkiLrWq9sC1n0LIlqrCodI
VLoMFGCPEE8IpsYYwcjk0Yv81j5IjChlHN3a9+IETuougugYRfQjge/QwBHd
L9c5huWo4CBsHwwgrGwallxlBvMgDrrTdAI63qLHd9sta60M5y9se7JMiaB2
1apF2oy72OjnbkgtS8UsoavMrkudBi/OXRw88KyncMM3mKnkXasHch/MXfsZ
y5i3XGbmOtPITKcVSTQBNnXl5JyJs844QVs35Njq6EgkFWlSNdPXaZKloyUq
En5kQP1ko1FzRxgITH2mau2hsjao9A4rZaw9i2VcwKc7TcGTLJzGxfx4jLg4
RwScv4KToVupLi7NjzaWWHYlnnWA+EJod9HZR2PAPTOutcjA4rMSYbdKMN+o
Q1/qLKSYHSKvRcJXjCWOCqxIV4aErQCn05rEqxuka4AFPTJP4SpAWYPfGlcI
DxkbmRD3RULe0/WrxGH5qa8v+mY/JYI0zDsjfAkk+UoVuYZhoYqEm99/fNSC
G8kZkWI6ePA7Vke5+LOuUpRdynVgbTZJa3WMyy987cGYh3TO1FrrC4iZB72b
Iqdu+24Z3bJqWblM0j1t4aR+SMZeF7TkccVYRq4sLIC0MT+gS4vSZDCPWJ1y
wgGcU8UYKXvariRfbFWE9knNyWtLiWC8BUvSClm/48SNA2DbWdDvmjgz20La
heWXW9DNUr8EVdZFwrR8uXG4q87fGsRm5NYYHLWrdBZ4I77U5ofV7HJ10rdw
TvGaIKlYY4yyZGdE02wF0dCDSIZZTYqA2Kc7iGSzDe/FOF3XTpeLH68iF+pX
eDAU5mc/ZjlwF0lna1zeoVzAWrUad38nocyyewc5mrAgxQX3VqBABhlKHXem
fbr+FO95J32luHGu2lfJiu2Vl4xLwSLRGSylNch+NaWGrZ1WOisHolXJm2vV
JV7tXwzTivPGfNZaF+hNySzjFiU91w7oJezu4BF+XI+lI9j8e0G/JU1hrhUb
1eAO+wHKueO33DmX1+kSgixBN8wmCzAmIBYEaKH2V5KlrFxM8blYeXWrcIh2
wOH0aQMMr2kC4GDEyrfJu2G5GqXjNK+SvGomST0uEtrpxJpnJKrfCEOCAjjW
UK960qJJllpcLgARAg2FngnJCxdjrGS/rxQcL8WkS30VBHhZALFqCte7KFJ+
7VmcX9e7OL4swr413LeS794iHRs4c7RU6BMHTRGYz7sdtT5DMfqdrswLtwzl
NkahwcC5r+PM6/8CtxHgIHNaRVpws8NfvV3Zp7RzayNkCzUPxbDnyOIgbmfI
LTjuKyWAIM++w4ITJTgSvqDwNQxcMfoOwGUkTmxdWRc1sbQia72UeQxxpnQw
qMijzRngsy21dgn8SAnfveNpBNlE62HTL3VjNIy41wLAZ33KsItLwIhK1Xuk
xZDSAUqYFa4P6XRjFmGdmvSXOus4db2bD7IBkMrQK6mKFAbYdl0kjz7b6zs+
vnncnA8i+PPWi/V0/++/6RfwssVSEkJkn4CJ+nvpNFfbZRgHEafQ5ZbXp2BA
WMqeAwfo5ON51lG0yO+CxIjQQHCd5NV917ue8/jZ8DF4TPZ2MehbHN+TJoDT
sXhb0Z6Ty6XmPu4CVElCI2nKRJD0pTP5WqCUcpbLAuEQy7M6YfGIdj2ei9XD
oxDqxRIL0/GfJFggBtjDT2NMJCF1XBb/ZxNv9N9UBkW/CsuDpe9ZfE+KdoZ2
u3APstYOm9ESfJA7yjbPVipV+T1dkBmejEZ0rZJFTkI+T6ZE/HXCDRfhtUY/
hLpVQa7d70Ij38xDaU/yp+Hes4qoxkoUGCtxt0EFzhz5iy27XDUK8wMSfX60
klSUnAEcvfsR/yEbUJzABhd6d9gWmw4m1ZkHS0HXnuTDEMMNaSU+EIjkjYVq
79z5wF1950cPg88aXXAYEx7sALVJP5bs69yuALQkGc1CMhfnijWYFk4gB2yi
gJGMBJFeGwgIu3i8uvGNEnh3NjxSITWogbuV2OFSIwIgAssHfeJAkdPs69Vf
q+95Qty53SwjrCROWZGUBmmBmHGxIU1dj66v2t0ine+EM4zDVKWtXWznmYVM
IfQxOF9Y1yjij3vigtNKEZFxttdXcYJ3McNANDmNuvQdpqACwvhoFtDwRieE
IMQkXVxlgN6bR+DwHwLXHHoouSr2ZzJlanMtOHNKrO9lvhBLSly01ieX3tt9
vL2Xbey1IQLtjopHyxAo5+VINW/+26yEG90ytywy0bkBmDPZgbUi4j2SCEPo
6Or+sQdiwqZlMb4NtBVuQ/+hF6JU123nmDOJnYo7dJAsrjpNrALv/GZ3AJRI
vL2FKqKVUbVr171pLJqTLOZIMWPv6zCycGhSkXWbgh/E/cBMeh8VAuQqRzek
RkoxSsWD69sZ8OTHAtbpfQ0sxjVGoUpgMIxlDtTIrRX2L1DeHG+Xj97dx37X
j+nSNT4P/VjPWiGy63ab69Mo7FVM9GxD/RTLXdwFrnSwbqWj8VYpaixj3dYb
hYvdoDo0tHnEByPYg2FnJAF98BdGjOqB64YYdOHhrhZchcI28TRdaugNuZv1
agqgjtqbqTg1TLQs3sWdO1xwLisE9ThMoyC5rW+el0Add/HXazY7tSB54zGS
6prIzH9+MrO1hW9wH9b/I2jLCdCWmxqAL4SrU7NSHVTwZadoPs52Rjv92Nv3
0ZBVI1ou4PuXoiKFzRf9W4iXQ/Epl1kh/Ze5yscFbZxbygAe8IK928/wAHBb
WCLGyxFq4WlKUxYLoMcU7QywoA/QQ96j1FI0VnbJsieUHZ9yXrl2RoqvuMUh
7U8U/Q9kqXAD47J6J+RVqxauN011K5r8hLtQG/UN/qfciIX0hHB2ZlhWOytr
rSEQb9q7vb0p6S6r4WBULvaaMqsY6V7uBmDAHjlnly7EcEF0Js5V85U/rubz
RDHeNXHInFzSs5FdC3+WekRNli7YMFA/uNTY0qhrIkeY8bQV+/vvNPvf1WPQ
lwfvkMOXIccnkV/Hcfe+nHHrl/dm8fZIuLXg5Zr1kthO/oOBanhDMWwIuMnq
7LDmSpq+S43ygXk+eVrLEu6agU7CjgMKvWt35YtYx2GPq6H1uOorj27hYvCN
cfZ9YCWbuQ7q2D98R3pvwcVipCpiIWhYSWKvD15iXQSYiD1rEe1XH5N5j9zm
kd0MYdiluZF+Ge0f2f7+G13r+Bk7s6q47sv9hp46fhf/oUqo69qZ/1iBD6X8
a6QnG6wNA/1oe78A1UO8quUQSdEgRHoEAWQ1PSWabt3VOaku5Yosbg5joyDy
u39iU9bl15JYJpJB8/FAsfWoFHBldwtonxj48PAQoZD903fxhxWj0rrbqZ5r
mFm2oxIz9OAkPsWVC7Q22uo6yFTxGHJtPpqFBFRIR1Cj//yr3+JB9P8C1/Nc
uC0HAQA=

-->

</rfc>