<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.16 (Ruby 2.7.0) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bryant-arch-fwd-layer-uc-04" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.13.1 -->
  <front>
    <title abbrev="FWD PS">Forwarding Layer Use Cases</title>
    <seriesInfo name="Internet-Draft" value="draft-bryant-arch-fwd-layer-uc-04"/>
    <author initials="S." surname="Bryant" fullname="Stewart Bryant">
      <organization>University of Surrey 5/6GIC</organization>
      <address>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author initials="U." surname="Chunduri" fullname="Uma Chunduri">
      <organization>Intel</organization>
      <address>
        <email>umac.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="T." surname="Eckert" fullname="Toerless Eckert">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <email>tte@cs.fau.de</email>
      </address>
    </author>
    <author initials="A." surname="Clemm" fullname="Alexander Clemm">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <email>ludwig@clemm.org</email>
      </address>
    </author>
    <date year="2022" month="August" day="06"/>
    <workgroup>INTAREA Working Group</workgroup>
    <abstract>
      <t>This document considers the new and emerging use cases for IP. These use cases are difficult
to address with IP in its current format and demonstrate the need to
evolve the protocol.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>There is an emerging set of new requirements that exceed the 
network and transport services of the current Internet, which currently only
delivers "best effort" service. While many controlled or private networks 
include further services, such as other DiffServ QoS in addition to best effort and
traffic engineering with bandwidth guarantees, the solutions used
today only support walled gardens and are thus they are not available to
application service providers and consumers across the Internet.</t>
      <t>The purpose of this document is to look at current, evolving and 
future use cases that need to addressed by the Internet forwarding layer. In parallel with this
use case study, a study of the gaps between the capability of the existing
IP forwarding layer and the requirements described in this use case study
is provided in <xref target="I-D.bryant-arch-fwd-layer-ps"/>. It is thus the purpose
of this text to provide the wider context for the forwarding layer problem statement.</t>
      <t>The purpose of this text is thus to stimulate discussion on the emerging contexts in which the 
forwarding layer will need to operate in the future.</t>
      <section anchor="forwarding-layer">
        <name>Forwarding Layer</name>
        <t>The term "forwarding layer" is used in this document to indicate that
that development work will likely need to reach down to layer 2.5 in order
to ensure that packets are handled correctly down to the physical layer,
and that it is equally it is possible that development work will need
to reach into the transport layer. This is described in more detail
in <xref target="I-D.bryant-arch-fwd-layer-ps"/>.</t>
      </section>
    </section>
    <section anchor="NUCIP">
      <name>New Use Cases for packet networks</name>
      <t>This section summarizes the use case areas that have been observed by the authors,
and are considered relevant to any analysis of the gaps in forwarding layer capabilities.</t>
      <t>This section is structured into sub-sections discussing either group of use cases
directly or the work of specific groups that are identifying use cases and
that may also work on identifying issues and or proposed architectures
or solutions for them.</t>
      <t>Subsections are ordered from what might be considered to be
the most near-term use cases to the potentially most far reaching ones.</t>
      <section anchor="role-of-fixed-networks-in-5g-and-beyond-5g">
        <name>Role of Fixed Networks in 5G and Beyond 5G</name>
        <t>The 5G and beyond 5G (B5G) services are not meant to be limited to the
5G-NR (new-radio). In fact for those services relating to uRLLC, and mMTC 
packet networks have evolve along with the radio technologies. While 5G-NR
protocol stack has evolved to provide per-frame reliability and latency guarantees,
the IP/MPLS transport network by-and-large remains best-effort. It is no longer
possible to solve network problems simply by increasing the capacity <xref target="SysArch5G"/>.
The expectations 5G devices have of 5G networks, can not be met without
improving IP/MPLS based back-haul networks. For example, the 5G based systems
involve machine to machine communications, generally using command-based
smaller payloads. In this case the overheads of packet headers and overlays become
apparent when computing latency budget of such packets.</t>
        <t>The IETF has produced a large body of work on the deterministic needs of network applications
<xref target="RFC8578"/>. These range from refinements and expansions of above summarized
Audio/Video and AR/VR use cases over gaming into many more "industrial" use cases.
Industrial use cases generally involve industrial controllers for high-precision machinery and equipment,
such as robotic arms, centrifuges, or manufacturing equipment for the assembly of electronic components.<br/>
These use cases have in common that they require delivery of packets with 
very precise and "deterministic" performance characteristics, as the controlled equipment and the control 
loops involved have very exact timing requirements and are not tolerant of any latency variations, 
as otherwise control loop issues and other undesired effects may occur.<br/>
Specifically, the use cases involve curtailing maximum latency that could be incurred.
However, deterministic networking, by itself, does not appear to be
sufficient to meet all of the emerging needs.</t>
      </section>
      <section anchor="convergence-of-industrial-control-networks">
        <name>Convergence of Industrial Control Networks</name>
        <t>Industrial control networks exist to serve specialist applications and are deployed
in well controlled networks subject to tight timing and reliability constrains
and tight security constraints. They mostly use bespoke, application specific proprietary protocols.
There is a desire to achieve economy of scale by using a single protocol,
and to integrate the production network with the back-office network. The
obvious protocol to use would be IP, but to be deployed in this mixed
application environment IP needs to satisfy the non-negotiable needs of the
industrial control network such as timing, reliability and security.</t>
      </section>
      <section anchor="cloud-based-industrial-automation">
        <name>Cloud Based Industrial Automation</name>
        <t>Future industrial networks are significantly different from best effort networks
in terms of performance and reliability requirements.
This is discussed in <xref target="NET2030SubG1"/>.
These networks need more than basic
connectivity between the back office and the  factory floors, instead they require
integration from devices all the way through to the business systems. This permits
many new types of UI and full automatic operation and control of industrial processes
without significant human intervention. These networks need to deliver better than
best effort performance, and require real-time, secure, and reliable factory-wide
connectivity, as well as inter-factory connectivity at large scale.</t>
        <t>Such systems typically require low end-to-end latency to meet closed loop control
requirements. Such system also need low jitter connectivity.
IIoT systems, as an example contain many control sub-systems that run at cycle times
ranging from sub-ms to 10 ms. In such systems, end-to-end control requires
in-time signaling delay at the same cycle time level, without malfunctions.
These low latency requirements of IIoT applications are increasingly not only
relevant to internal system communications, but also becoming essential for
the interconnection of remote systems.</t>
        <t>As another example, it is a fundamental requirement for multiple-axis applications
to have time synchronization in order to permit cooperation between various devices,
sometimes remotely. In order to recover the clock signal and reach precise
time synchronization, the machine control, especially the motion control sub-system,
requires very small jitter at sub- microsecond level, and such small jitter is
expected to have bounded limits under some critical situations.</t>
        <t>In some IIOT systems a service availability of 99.999999% is needed, as any break in
communications may be reflected as a million-dollar loss.
At the same time, as part of the Industry 4.0 evolution,
operational technologies (OT) and information technology (IT) are converging.
In this model control functions traditionally carried out by customized hardware platforms,
such as Programmable Logic Controllers (PLC), have been slowly virtualized and
moved onto the edge or into the cloud in order to reduce the CAPEX and OPEX,
and to provide increased system flexibility and capability and to allow 'big data'
approaches. This move of industrial system to the cloud places higher requirements on the
underlying networks, as the latency, jitter, security and reliability
requirements previously needed locally have to be  implemented at larger scales.</t>
      </section>
      <section anchor="volumetric-data-transmission">
        <name>Volumetric Data Transmission</name>
        <t>Volumetric Data refers to cases where very large data sets need to be transferred
continuously in real time. One example is Immersive AR/VR media transmission
<xref target="VidandAR"/>. Another example is V2X with many sensors continuously generating
data which needs to made available for, amongst other reasons, technical analysis
by the manufacturer as part of product development, and insurance purposes.</t>
      </section>
      <section anchor="itu-t-focus-group-network-2030">
        <name>ITU-T Focus Group Network-2030</name>
        <t>The ITU-T has been running a Focus Group (FG) Network-2030 <xref target="FGNETWORK2030"/>
to analyze the needs of networks in the period post 2030. This work started
in July 2018 and submitted it report to ITU-T Study Group 13 in June 2020.
It has been an open process with contribution by a cross-section of
the networking industry. Because this is non-IETF work, this section summarizes
the currently finalized key findings of the ITU-T Focus Group Network-2030
to make it easier for the reader to better understand the work. Note that
this work is still ongoing and additional findings may be published.</t>
        <t>The Focus Group Network 2030 considered a number of use cases that it was postulated would need
to be addressed in the 2030 time-frame and the technology gaps that need to be
bridged in order to address these needs. It then considered a number of new
network services that would be needed to support these services.</t>
        <t>An ongoing piece of work on the architecture of the network post 2030 has
not yet been completed at the time of writing and is only partially discussed
in this document.</t>
        <t>The reader is referred to <xref target="WP"/>, <xref target="NET2030SubG2"/>, <xref target="UC"/> for information  beyond that
provided in this summary.</t>
        <t>ITU-T FG NET2030 Sub-group Sub-G1 (Sub-G1) considered a number of use
cases that it considered to be representative of the network needs post 2030.
These needs are legitimate needs in their own right, but as is always the case
act as poster-children for new applications that will inevitable conceived
in the light of the new network capabilities that we postulate to be necessary.</t>
        <ul spacing="normal">
          <li>Holographic-type communications (HCT)</li>
          <li>Tactile Internet for Remote Operations (TIRO)</li>
          <li>Network and Computing Convergence (NCC)</li>
          <li>Digital Twin (DT)</li>
          <li>Space-Terrestrial Integrated Networks (STIN)</li>
          <li>ManyNets</li>
          <li>Industrial IoT (IIoT) with cloudification.</li>
        </ul>
        <t>Further information on these use cases is provided in <xref target="ExpandSG1"/>, and in the
ITU documents <xref target="UC"/> and <xref target="WP"/>.</t>
        <t>Note to the reader: Unlike ITU-T Study Groups which are restricted to
members, ITU-T Focus Groups are open to anyone without payment. At the time of writing,
ITU-T Focus Group Network-2030 material that is not available
for anonymous download, is accessible for free by joining the Study Group.</t>
      </section>
      <section anchor="VidandAR">
        <name>Emerging and New Media Applications</name>
        <t>Audio/Video streaming for production, entertainment, remote observation,
and interactive audio/video are the most ubiquitous applications on the
Internet and private IP networks after web-services. They have grown primarily
through an evolution of the applications to work with the constraints of
todays Internet and adopting pre-existing infrastructure such as content
caches: best-effort streaming with adaptive video, no service guarantees
for most services, and co-location of caches with large user communities.
In environments where more than best-effort services for these applications
are required and deployment of current technologies to support them is
feasible, it is done. Examples include DiffServ or even on or off-path
bandwidth reservations in controlled networks.</t>
        <t>Networked AR/VR is a very near term set of use cases, where solution models are
very much attempting to use and expand existing solution approaches for video
network streaming but where the limits of above current best practices are
also amplified by the larger bandwidth requirements and stricter latency
and jitter requirements of AR/VR.</t>
        <t>To ensure a good user experience, for live Virtual Reality (VR), a much higher
resolution than 8K video is required. In addition to the high bandwidth requirements
of VR, there needs to be a supporting transmission network to provide a
communications path with bounded low latency as well.  This stringent VR latency
requirement is a challenge to existing networks.</t>
        <t>In cellular networks, even though the the air interface link latency needed is
significantly reduced e.g. with New Radio (5GNR), the end-to-end (E2E) requirements
for live VR is harder to meet. This is because of the fixed L2/IP/MPLS networks in
front/mid/backhaul components, and because of the best effort nature of the
packet delivery systems in these networks.</t>
      </section>
    </section>
    <section anchor="deployment-models">
      <name>Deployment Models</name>
      <t>In this section we look at a number of network  deployment models. We group these
deployment models into three types:</t>
      <ul spacing="normal">
        <li>The traditional deployment models</li>
        <li>Emerging deployment model models</li>
        <li>Envisioned new deployment models</li>
      </ul>
      <t>The service requirements demanded from the networks and security
implications vastly differ in these different deployment models.</t>
      <t>A few general observations are useful in providing context to this section:</t>
      <ul spacing="normal">
        <li>End to End traffic over the Internet backbone is becoming minority traffic.</li>
        <li>Commercial deployments do not operate the way they used to when many of the original Internet protocols and invariants were established.</li>
        <li>The application trajectory is for the applications to be hosted on (protected) servers a few hops from the user.</li>
        <li>Applications are becoming self-contained and use their own stack which is tunneled over UDP/IP to the server.</li>
      </ul>
      <section anchor="traditional-deployment-models">
        <name>Traditional Deployment Models</name>
        <t>In this section we look at the traditional deployment models that have been in
existence for many year and formed the foundation of Internet.</t>
        <section anchor="best-effort-internet">
          <name>Best-effort Internet</name>
          <t>In this model connectivity is edge-to-edge, and in the general case
the edge connectivity is provided by a service provider who peers with
a transit provider that provides connectivity to other service
providers possibly via other transit providers. This
is shown in <xref target="MP-Classic"/>.</t>
          <figure anchor="MP-Classic">
            <name>An Edge-2-Edge Classical Internet</name>
            <artwork><![CDATA[
+---+                                                 +---+                  
| H |                                                 |Svr|                  
+-+-+                                                 +-+-+                                  
  |      SP1            Internet              SP2       |
  |    ..........  .....................   .........    |
+-+--+ .+----+  .  .+---+  +---+  +---+'   . +----+.  +-+-+
| CE +--+ PE +------+AS1+--+AS2+--+AS3+------+ PE +---+ CE|
+----+ .+----+  .  .+---+  +---+  +---+.   . +----+.  +---+
       ..........  .....................   .........
]]></artwork>
          </figure>
          <t>This service is generally known as "best-effort" in that each
element of the service path undertakes to do no more that
try its best to provide equitable service to all traffic.
These are traditional E2E
deployments where communication endpoints of the data traffic on
different provider networks with regional, transit network providers
through Internet Exchange Providers (IXPs) providing the global inter connection.
The
term lower-common-denominator might be a better term in that
the service quality is the service of the worst element of the
path on a packet by packet basis.</t>
          <t>This model is in the process of being replaced by a model in
which the most popular and important service are provided at the
edge with Internet transit traffic being used where there is
no alternative.</t>
          <t>In this case the provider controls only the path to the CE and can
certify the correct operation of the service according to contract from that
point but the user is responsible for providing the required service
characteristics into their own network.</t>
          <t>In this network environment it is difficult to support
any form of enhanced service since it is unlikely that
the whole path is know to support extended capabilities in the forwarding
plane. It is not infeasible, and it would be possible to set up
such paths in principle given suitable enhancements to the routing
system. However such a scenario must be considered infeasible for
the foreseeable future.</t>
        </section>
        <section anchor="enhanced-service">
          <name>Enhanced Service</name>
          <t>This is the traditional service provider
deployment where various network services (VPN, security, Bandwidth..)
are offered to the endpoints of the communication and other providers.
Such capabilities are purchased through contract with the
service provider and are typically expensive.</t>
          <t>These networks predominantly use MPLS technology though native
IP (IPv4/IPv6) with GRE and IPv6 with routing extension headers
with SRv6 are being deployed recently.</t>
          <figure anchor="Edge-2-Edge">
            <name>An Edge-2-Edge Network</name>
            <artwork><![CDATA[
             ..................................
      +---+ . +---+        Single        +---+ . +---+
      |CE1|---|PE1|---..  Provider  ..---|PE2|---|CE2|
      +---+ . +---+       Network        +---+ . +---+
             ..................................
]]></artwork>
          </figure>
          <t>In this case there is a single
provider network in which E2E offerings and host session are
initiated and terminated with in the single provider network.</t>
        </section>
        <section anchor="over-the-top-ott-providers">
          <name>Over-the-top (OTT) Providers</name>
          <t>In this model the endpoints of the communication (virtual
or physical hosts)  consuming services through with in the OTT
provider network servers (Cloud and Data Center (DC) networks); where the other
endpoint can be in the same server form or on 
the DC Gateway or on the other end of the DC Server Farm
connected through Data Center Interconnect (DCI).</t>
          <t>The local provider is thus just a connectivity provider to
opaque traffic with no ability to enhance the service.
However the corollary to this is that whilst the the OTT provider
has full control of what happens whilst the user data is within
their network they have no control over how the user traffic
transits to them across the "public" network.</t>
        </section>
        <section anchor="cooperating-providers">
          <name>Cooperating Providers</name>
          <t>Where two providers interconnect with no Internet Transit Network: Another variant of the
E2E connectivity can be seen as evolving comprises only  endpoints
provider (access) network and receiver access provider network with
global transit provided by one ISP.
This case is more tractable provided there is co-operation between
the providers.</t>
        </section>
      </section>
      <section anchor="emerging-deployment-models">
        <name>Emerging Deployment Models</name>
        <t>The emerging model is to provide the service close to the user
by embedding that service with the service provider network. This
has three advantages, firstly that the service latency is lower,
secondly that that there is less transit traffic that the
network provider needs to manage or pay for, and thirdly that
the service availability and reliability is in the hands of the
network provider that the customer is contracted to.</t>
        <section anchor="ES">
          <name>Embedded Service</name>
          <t>The industry move is towards content and application service providers
embedding themselves within the edge network. This is currently done
to save bandwidth and improve response time. As the need for
high precision low latency networking develops the need for edge computing
rises since the closer the client and the server the less the scope
for network induced performance degradation.</t>
          <figure anchor="Edge-2-Edge-EP">
            <name>An Edge-2-Provider</name>
            <artwork><![CDATA[
+---+ 
| H | 
+-+-+ 
  |   
  |    .....................................
+-+--+ .+----+        +---+                .
| CE +--+ PE |--------+Svr|                .
+----+ .+----+        +---+   Provider 1   .
       .....................................
]]></artwork>
          </figure>
          <t>In this network the server S (owned by the content and applications
provider) has a contractual relationship with provider 1 and
is thus able to negotiate the network characteristics needed
to meet its service requirement. This model in which the
server brokers the user to network interface (UNI) requirements
removes many of the objections to the classical UNI model
in which the client requests the service requirements.
In this model the host authenticates itself
with the server, having formed a previous business relationship
(for example by purchasing a holographic conferencing service).
The server has a relationship with Provider1, and thus is a trusted
party able to request that the service be set up between itself
and and its client, paying as necessary. As this is a requested
paid service traversing a limited distance over a defined network,
a bespoke packet protocol can, if necessary, be used with in
a contained and constrained way.</t>
          <t>How the server communicates with any other part of the application
domain is out of scope for this document and possibly out of scope
for Provider 1.</t>
          <t>This takes us to consider the embedded global service described in {#EGS}.</t>
        </section>
        <section anchor="EGS">
          <name>Embedded Global Service</name>
          <figure anchor="Edge-2-Edge-VS">
            <name>Edge-2-Edge via Provider</name>
            <artwork><![CDATA[
+---+ 
| H1| 
+-+-+ 
  |   
  |    ......................................
+-+--+ . +----+        +---+                .
| CE +---+ PE |--------+ S1|                .
+----+ . +----+        +-+-+   Provider 1   .
       ..................|...................
                         |
                         |Private Peering
                         |
       ..................|...................
+----+ . +----+        +-+-+                .
| CE +---+ PE |--------+ S2|                .
+----+ . +----+        +---+   Provider 2   .
  |    ......................................
  |    
+-+-+ 
| H | 
+-+-+ 
]]></artwork>
          </figure>
          <t>In this network model, the server S1 (owned by the content and applications
provider) has a contractual relationship with provider 1 and
is thus able to negotiate the network characteristics needed
to meet its service requirement. It is servicing the needs of host H1.</t>
          <t>Similarly that same provider has a contractual relationship with
provider 2 where it is servicing the needs of host H2.</t>
          <t>By a method outside the scope of this document and outside the scope
of the global Internet the contents and applications provider has a
private path between S1 and S2.</t>
          <t>This scenario shown in <xref target="Edge-2-Edge-VS"/> is important because it
removes the overwhelming issues associated with providing enhanced
service across the global Internet. Furthermore it describes a model
where there is commercial incentive, at scale, for the edge providers
(Provider 1 and 2 above) to invest in providing and enhanced access
service.</t>
        </section>
        <section anchor="changing-fixed-access-models-1-or-2-providers">
          <name>Changing Fixed Access Models (1 or 2 Providers)</name>
          <t>The preceding sections are the basis for a change in the network
fixed access model.</t>
          <t>The access network either connects to a data center gateway or
one is embedded in the access network. This gateway either passes
the traffic to a locally connected data center that provides the
required service or passes it over a private global data center
interconnect to a partner data center for service provision.
Such a connection provides service model in which the required
service level cane be more readily addressed.</t>
          <figure anchor="CH-FAM">
            <name>Changing Fixed Access Model</name>
            <artwork><![CDATA[
   H  H
   |  |
   |  |
Access NW
         \
          \
         DC-GW==Private Global==DC-GW
         //         DCI              \\
 DC Fabric                            DC Fabric
 | | | | |                            | | | | |
 S S S S S                            S S S S S
]]></artwork>
          </figure>
        </section>
        <section anchor="single-underlay-provider-e2e-for-5gb5g-network-cellularaccess-networks">
          <name>Single "Underlay" provider E2E for 5G/B5G network (Cellular/Access Networks)</name>
          <t>The preceding sections are the basis for the emerging change in the
structure of the 5B and Beyond 5G (B5G) network design.</t>
          <t>Endpoints (UE's) connecting to
the provider wireless or wired networks, where service is terminated
inside the provider network end points. Based on the service offerings
connection termination can happen close to the Radio/access nodes
with multi-access edge computing (MEC) clouds or in the provider
core network (core-cloud) before going to the Internet eventually.
Example of these deployments include BNG, 4G and 5G wireless
access/RAN/backhaul networks.</t>
          <t>Thus in <xref target="x5GNW"/> user equipment connects to the customer site provider edge via the radio network.
This in turn is connected to the aggregation PE which in turn determines if the
traffic should be routed to a local data center for processing, or passed to
a core data center. At the core DC the traffic may be processed locally, passed out to the Internet,
passed to a peer DC via a private DCI, or processed locally with the help of resources
access via that external interconnects.</t>
          <figure anchor="x5GNW">
            <name>4G and 5G underlay provider network</name>
            <artwork><![CDATA[
User Equipment(UE)
Phone/eMBB
/                     Compute       Compute
\ Vehicle             Storage       Storage 
/ /                      |             |      / Internet
\ \ Drone/UAV            |             |     /
/ / /                  DC Fabric   DC Fabric{
\ \ \ IIOT               |             |     \
/ / / /                  |             |      \ Private Global
\ \ \ \                  |             |             DCI
 Radio --------CS PE----Aggr PE-----Core PE
]]></artwork>
          </figure>
        </section>
      </section>
      <section anchor="envisioned-new-deployment-models">
        <name>Envisioned New Deployment Models</name>
        <t>The emerging network deployment models are a potential vector for
fundamental change in the way the network operates.</t>
        <section anchor="network-slicing">
          <name>Network Slicing</name>
          <t>Network slicing is a method of creating a private subset of a public network.
Unlike VPNs it is not a simple over the top approach, instead it is more integrated
with the base network in terms of the way the base network provides services
and allocates resources. A network slice provides significant isolation between
one slice and another and between the slice and best effort users of the
network. In an ideal slice, the users of one slice have no way of knowing
anything about the traffic in any other slice. Such a service could be offered
through statistical multiplexing techniques with real bandwidth permanently allocated
to each slice, but this would not easily offer the statistical multiplexing that
make packet networking so economic and so flexible. In particular it would not
be easy to transparently "borrow" unused committed bandwidth in a way that was
undetectable. It seems likely that to create a high fidelity slice will require
new properties in the packet layer, either through extension of the existing packet
protocols, or through the introduction of an alternative design. A useful discussion
of network slicing relevant to this context can be found in <xref target="I-D.ietf-teas-enhanced-vpn"/>.</t>
          <t>Largely popularized as part of 5G the concept of network slicing has wider
applicability.</t>
        </section>
        <section anchor="private-5g-networks">
          <name>Private 5G Networks</name>
          <t>A use case is emerging for 5G technology in private networks. The interest is
in the protection and security that comes with the use of licensed spectrum.
Unlicensed spectrum offers no protection against other users of that spectrum
and thus another aspect of best effort comes into play, not only is the network
best effort with respect to traffic within the network (an addressable problem)
but the radio is best effort with respect to radio traffic from adjacent networks.
Without extensive radio shielding of the facility a user cannot know if the
spectrum is available for their use at any time, and they have to suffer interference
from adjacent users, who may be benignly using the spectrum for legitimate
purposes, as is their equal right, or may be using it to cause service disruption
to a commercial enterprise.</t>
          <t>5G runs on licensed and hence protected spectrum. In return for the paying the
license fee the spectrum owner has a statutory protection against interference.</t>
          <t>Thus it is interesting to note that a major UK car plant just announced the
use of 5G to provide connectivity for equipment at their manufacturing facility.</t>
          <t>Such applications of 5G are not as architecturally constrained as public 5G
deployments and thus have the ability to make different fundamental choices
regarding their packet protocols.</t>
        </section>
      </section>
      <section anchor="limited-domains">
        <name>Limited Domains</name>
        <t><xref target="RFC8799"/> provides a useful insight into the
emergence of limited domains in which fewer (or different) constraints on
protocol design and operation apply. Limited domains offer an opportunity
to deploy specialist forwarding layer protocols, designed to meet
specific objectives, which are not readily addressed by general purpose
protocols such as IPv4|6 without the need to worry about inter-working and
inter-operation across the big I Internet.</t>
        <t>Such domains can be considered sandboxes in which new proposals can
be deployed without the wider concerns of full-scale Internet deployment.</t>
      </section>
    </section>
    <section anchor="NNCS">
      <name>New Network  Services and Capabilities</name>
      <t>In order to support the use cases presented in <xref target="NUCIP"/>, a number of new network services 
will be needed.  Likewise, a number of additional more general network capabilities 
will becoming increasingly important.  Neither services nor capabilities are sufficiently 
supported to the degree that will be required by Internet technology in use today.</t>
      <t>This section describes these services and capabilities at a high level.  It builds on a corresponding 
analysis that was conducted at ITU-T FG-NET2030; readers are referred <xref target="ExpandSG2"/> for further
detail and, of course, to output produced by that group <xref target="NET2030SubG2"/> for a more complete explanation of
their considerations.</t>
      <section anchor="NS">
        <name>New Services</name>
        <t><xref target="NET2030SubG2"/> identifies a number of network services that will be needed to support many 
of the new use cases.  These network services are divided into two categories:</t>
        <ul spacing="normal">
          <li>Foundational Services (FS) require which dedicated support on some or all network
system nodes which are delivering the service between two or more application
system nodes.</li>
          <li>Compound Services (CS) are composed of one or more foundational services, and
are used to make network services easier to consume by certain applications or
categories of use cases. An example of a CS would be a Tactile Internet Service
which consisted of tactile control channel and a haptic feedback channel.</li>
        </ul>
        <t>The following are a set of Foundational Services :</t>
        <ul spacing="normal">
          <li>
            <t>High-Precision Communications Services: services with  precisely defined
service level objectives related to end-to-end latency. Three high-precision
communications services that have so far been proposed:
            </t>
            <ul spacing="normal">
              <li>In-time Services: services that require end-to-end latency within
a quantifiable limit. This service is similar to the service provided
by DetNet <xref target="RFC8655"/> but with more demanding applications which
need to be satisfied over IP.</li>
              <li>On-time Services: services require end-to-end-latency to be of an
exact duration.</li>
              <li>Coordinated Services: Coordinated services require multiple interdependent
flows to be delivered with the same end-to-end latency, regardless of
any (potential additional) service level objective.</li>
            </ul>
          </li>
          <li>Qualitative Communication Services: services that are able to suppress retransmission of
less relevant portions of the payload in order to meet requirements on latency by applications
that are tolerant to this.</li>
        </ul>
        <t>These are described in more detain in <xref target="NSAppen"/>.</t>
      </section>
      <section anchor="NC">
        <name>New Capabilities</name>
        <t><xref target="NET2030SubG2"/> identifies also a number of network capabilities that will become increasingly 
important going forward, in addition to the support for any particular services.<br/>
A number of those need to be taken into consideration from the very beginning when thinking about 
how future data-planes need to evolve. These capabilities are described in more detail in <xref target="NCAPPEN"/>.</t>
        <ul spacing="normal">
          <li>Manageability: Many of the services that need to be supported in the future will require advances in 
measurements and telemetry will be required in order to monitor and validate that promised service 
levels are indeed being delivered. These will requires advanced instrumentation that is ideally built.</li>
          <li>High Programmability and Agile Life-cycle: Methods to provide operators need to be able to rapidly
nd easily introduce new network services and adapt to new contexts and application needs.</li>
          <li>Security and Trustworthiness: New  mechanisms are needed to authorize packets to enter the
network from a host or from another network, and for them to then receive the required premium
service that can operate. This must operate without impacting the latency and MTU requirements.
This security mechanism has to protect both the network, the user data and the user privacy, but still
expose sufficient information to the network that the correct premium service can be delivered.</li>
          <li>Resilience: Ultra-low-latency requirements and the huge increase of bandwidth demands of new services such as 
holographic type communication services make retransmission as a mechanism to recover data that was 
lost in transit increasingly less feasible. 
Therefore, network resilience and avoidance of loss becomes more importance that it is for best effort networks.</li>
          <li>
            <t>Privacy-Sensitive: There is a growing awareness of the lack of privacy in the Internet and its implications.<br/>
New network services have to be sensitive to and comply with heightened user privacy expectations.<br/>
At the same time, the need for privacy needs to be balanced with legitimate needs of network 
providers to operate and maintain their networks, which requires some visibility into what is 
happening on the network and how it is being used.  There are a variety of privacy-related requirements that ensue, such as:  </t>
            <ul spacing="normal">
              <li>Anonymization</li>
              <li>Opaque User data</li>
              <li>Secured Storage</li>
              <li>Flow anonymization</li>
            </ul>
          </li>
          <li>Accountability and Verifiability: Provision of the methods to account for an verify delivery of
premium services.</li>
        </ul>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document does not request any allocations from IANA.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Security is likely to be more significant with the applications being considered
in this work. With interest in tightly controlled access and latency, and
contractual terms of business it is going to be necessary to have provable
right of access to network resources. However heavyweight security is a
contra-requirement to the light-weight process needed for power efficiency,
fast forwarding and low latency. Addressing this will require new
insights into network security.</t>
      <t>Further information on the issue of providing security in latency sensitive
environments can be found in <xref target="RFC9055"/> which are a sub-set
of the considerations applicable to the new use cases considered in this text.</t>
    </section>
    <section anchor="ExpandSG1">
      <name>Appendix 1: Expanded Summary of Sub-G1 Use Cases</name>
      <section anchor="holographic-type-communications">
        <name>Holographic-type communications</name>
        <t>This work projects that we will move towards a holographic society
where users remotely interact with the physical world over the network.
In industry the digital twin model will enable the control of real objects
through digital replicas. Tele-presence will move to a new level with
multi-site collaborations becoming much closer to physical meetings that
can take place without the time and environmental cost of physical
travel. 3D medical scans will become full 3D views rather than the body/
organ slices that too many of us are regrettably familiar with. It is easy
to imagine that this technology will take message delivery to a completely
new level.</t>
        <t>Analysis of these concepts results in the conclusion that the following
key  network requirements are necessary:</t>
        <ul spacing="normal">
          <li>Ultra-high bandwidth (BPS class)</li>
          <li>Ultra-low latency (sub-ms)</li>
          <li>Multi-stream synchronization</li>
          <li>Enhanced network security</li>
          <li>Enhanced network reliability</li>
          <li>Edge computation</li>
        </ul>
      </section>
      <section anchor="tactile-internet-for-remote-operations">
        <name>Tactile Internet for Remote Operations</name>
        <t>Two cases were proposed as examples of this class of application. The
first is remote industrial management which involves the real-time
monitoring and control of industrial infrastructure operations. The second
involves remote robotic surgery. Remote robotic surgery within an
operating suite complex is a standard practice today, however there
are cases where it would be desirable to extend the range of this
facility.</t>
        <t>Analysis of these concepts results in the conclusion that the following
key network requirements are necessary:</t>
        <ul spacing="normal">
          <li>Ultra-high bandwidth (Tbps class)</li>
          <li>Ultra-low latency (sub-ms)</li>
          <li>Sensory input synchronization</li>
          <li>Enhanced network security</li>
          <li>Enhanced network reliability</li>
          <li>Differentiated prioritization levels</li>
        </ul>
      </section>
      <section anchor="space-terrestrial-integrated-networks">
        <name>Space-Terrestrial Integrated Networks</name>
        <t>The game-changer in the area of space-terrestrial networking is the active
deployment of huge clusters of cheap Low Earth Orbit (LEO) satellite constellations.
These LEOs have a
number of properties that make them attractive, but arguably the most important
is that they combine global coverage with low latency. Studies <xref target="Handley"/> show that
for distances over 3000Km latency via a LEO cluster is lower than the latency
of terrestrial networks. The up-link to a LEO cluster has to constantly change the point
of attachment to the cluster as the satellites that form the cluster rapidly move
across the sky relative to both the ground and relative to the satellites in other orbits.
In this scenario a number of access and connection models need to be considered.</t>
        <t>Analysis of these concepts results in the conclusion that the following
key network requirements are necessary:</t>
        <ul spacing="normal">
          <li>A suitable addressing and routing mechanism to deal with a network that is constantly in flux.</li>
          <li>Sufficient bandwidth capacity on the satellite side to support the new application needs</li>
          <li>A suitable satellite admission system</li>
          <li>Edge computation and storage</li>
        </ul>
      </section>
      <section anchor="manynets">
        <name>ManyNets</name>
        <t>There is evidence that there is a change in direction from the Internet as a single hetrogenious
network back to a true Internet, that is an interconnection of a number of networks each optimized
for its local use but capable of inter-working.</t>
        <t>For example, satellite and the terrestrial networks adopt different protocol architecture,
which causes the difficulty to internetwork between them, yet the common goal is to
provide access to the Internet. Secondly, there will be a massive number of IoT-type
devices connecting to the networks but the current interconnection schemes are too complex for
these services. There are further trends in 5G/B5G back-haul infrastructure, requiring
diverse set of resource guarantees in networks to support different industry verticals.
The collection of such special purpose networks, existing together and requiring
interconnection among themselves are called ManyNets.</t>
        <t>Much closer the traditional Internet model is the move to edge computing services
in which the client traffic is terminated at a compute node very close to access edge. <xref target="DOT"/>
Any resultant application traffic is a private matter between the application on the
edge server and the servers it communicates with in the fulfillment of those needs.
Furthermore the application on the client may be using a tunnel to the edge compute server.
In such a network the protocol used inside the tunnel and the protocol used between
the servers executing the service is a private matter.</t>
        <t>The ManyNets concept  aims to support flexible methods to support the communication
among such heterogeneous devices and their networks.</t>
      </section>
    </section>
    <section anchor="ExpandSG2">
      <name>Appendix 2: Expanded Summary of Sub-G2 New Network Capabilities and Services</name>
      <t>This appendix expands on the ITU-T Sub-G2 new network capabilities and services introduced in <xref target="NNCS"/>
It builds upon the analysis that was conducted at ITU-T FG-NET2030; readers are also
referred to output produced by that group <xref target="NET2030SubG2"/> for more detail.</t>
      <section anchor="NSAppen">
        <name>New Services</name>
        <t><xref target="NET2030SubG2"/> identifies a number of network services that will be needed to support many 
of the new use cases.  These network services are divided into two categories:</t>
        <ul spacing="normal">
          <li>Foundational Services (FS) require which dedicated support on some or all network
system nodes which are delivering the service between two or more application
system nodes. FS  cannot be decomposed into other services. For example, IP
packet routing and forwarding are is a (pre-existing) foundational network services.</li>
          <li>Compound Services (CS) are composed of one or more foundational services. CS
are "convenience services" that make network services easier to consume by
certain applications or categories of use cases, but do not by themselves
introduce new network services or requirements into network system nodes.
One example would be a Tactile Internet Service which consists of two
communications channels, one for tactile control and the other for haptic feedback.</li>
        </ul>
        <t>The following sections focus on Foundational Services only, as these are the ones
that provide the basic building blocks with which the needs of all other services
can be addressed, and which are the ones that potentially introduce new foundational
requirements on network system nodes.</t>
        <section anchor="high-precision-communications-services">
          <name>High-Precision Communications Services</name>
          <t>High-Precision Communications Services refers to services that have precisely defined
service level objectives related to end-to-end latency, in many cases coupled with
stringent requirements regarding to packet loss and to bandwidth needs.  These requirements are in
stark contrast to the best effort nature with related to existing network services.<br/>
Of course, existing services often go to great lengths in order to optimize service
levels and minimize latency, and QoS techniques aim to mitigate adverse effects of
e.g. congestion by applying various forms of prioritization and admission control.
However, fundamentally all of these techniques still constitute patches that,
while alleviating the symptoms of the underlying best-effort nature, do not address
the underlying cause and fall short of providing service level guarantees that will
not be just of a statistical nature but that will be met by design.</t>
          <t>The high-precision communications services that have been identified are described
in the following three sub-sections.</t>
        </section>
        <section anchor="in-time-services">
          <name>In-time Services</name>
          <t>In-time services require end-to-end latency within a quantifiable limit.
They specific a service level objective that is not to be exceeded, such as a
maximum acceptable latency (putting a hard boundary on the worst case).  In-time
services are required by applications and use cases that have clear bounds on acceptable
latency, beyond which the Quality of Experience would deteriorate rapidly,
rendering the application unusable.  An example concerns use cases that involve
providing tactile feedback to users.  Creating an illusion of touch requires a control
loop with a hard-bounded round-trip time that is determined by human / biological factors,
beyond which the sense of touch is lost and with it the ability to e.g. operate a piece of
machinery from remote.  Because many such use cases are mission-critical (such as tele-driving
or remote surgery), in addition any loss or need for retransmission is unacceptable.</t>
          <t>This service is similar to the service provided by DetNet <xref target="RFC8655"/> but with more demanding
applications which need to be satisfied over IP.</t>
        </section>
        <section anchor="on-time-services">
          <name>On-time Services</name>
          <t>On-time services require end-to-end-latency to be of an exact duration, with the
possibility of a small quantifiable variance as can be specified either by an acceptable
window around the targeted latency or by a lower bound in addition to an upper bound.
Examples of use cases include applications that require synchronization between multiple
flows that have the same in-time latency target, or applications requiring fairness
between multiple participants regardless of path lengths, such as gaming or market
exchanges when required by regulatory authorities. The concept of a lowest acceptable
latency imposes new requirements on networks to potentially slow down packets by
buffering or other means, which introduces challenges due to high data rates
and the cost e.g. of associated memory.</t>
        </section>
        <section anchor="coordinated-services">
          <name>Coordinated Services</name>
          <t>Coordinated services require multiple interdependent flows to be delivered with
the same end-to-end latency, regardless of any (potential additional) service level
objective.  Use cases and applications include applications that require
synchronization between multiple flows, such as use cases involving data
streams from multiple cameras and telemetry sources.  In the special case
where an on-time service is required, no additional service is needed
(as synchronization occurs by virtue of the fact that each flow adheres to
the same SLO), but coordination may also be required in cases where no
specific end-to-end latency is required, as long as all flows are serviced
with service levels that are identical.</t>
        </section>
        <section anchor="qualitative-communication-services">
          <name>Qualitative Communication Services</name>
          <t>Qualitative communication services (QCS) are able to suppress retransmission of
portions of the payload that are deemed less relevant when necessary in order
to meet requirements on latency by applications that are tolerant of
certain quality degradation.  They may involve the application of network coding schemes.</t>
          <t>QCS is a new service type that is needed to support AR/VR, holographic-type communications
Industrial Internet and services such as autonomous driving. This needs the
support of a new network capability that is as yet to be developed.</t>
        </section>
      </section>
      <section anchor="NCAPPEN">
        <name>New Capabilities</name>
        <t><xref target="NET2030SubG2"/> identifies also a number of network capabilities that will become increasingly 
important going forward, in addition to the support for any particular services. These were introduced in <xref target="NC"/>.
A number of these capabilities need to be taken into consideration from the very beginning when thinking about 
how future data-planes need to evolve.<br/>
While many of those capabilities are well known, the past has shown that retrofitting data-planes 
with such capabilities after the fact and in a way that is adequate to the problem at hand is very 
hard.</t>
        <section anchor="manage-ability">
          <name>Manage ability</name>
          <t>Many of the services that need to be supported in the future have in common that they place very 
high demands on latency and precision that need to be supported at very high scales, coupled with 
expectations of zero packet loss and much higher availability than today.</t>
          <t>In order to assure in-time and on-time services with high levels of accuracy, advances in 
measurements and telemetry will be required in order to monitor and validate that promised service 
levels are indeed being delivered. This requires advanced instrumentation that is ideally built-in 
all the way to the protocol level.</t>
          <t>For example, the ability to identify and automatically eliminate potential sources of service-level 
degradations and fluctuations will become of increasing importance.  This requires the ability to 
generate corresponding telemetry data and the ability to observe the performance of packets as they 
traverse the network. Some of the challenges that need to be addressed include the very high volume 
of data that gets generated and needs to be assessed, and the effects of the collection itself on 
performance. In general, greater emphasis will need to be placed on the ability to monitor, observe, 
and validate packet performance and behavior than is the case today.  For seamless support, these 
capabilities will be inherently integrated with the forwarding function itself, for example 
delivered together with the packets. Today's solution approach, IOAM, is a promising technology 
currently that points in the right direction, and that also highlights some of the challenges - from 
MTU considerations due to extending packet sizes to the ability to customize and obtain the "right" 
data.  It will therefore be not sufficient by itself.  Data to be generated from the network will 
need to be "smarter", i.e. more insightful and action-able.  This will require additional abilities 
to process data "on-device". In additional, the need for new management functions may arise, such as 
functions that allow to validate adherence with agreed-upon service levels for a flow as a whole, 
and to prevent data or privacy leakage as well as provide evidence for the possibility or absence of 
such leakage.</t>
        </section>
        <section anchor="high-programmability-and-agile-life-cycle">
          <name>High Programmability and Agile Life-cycle</name>
          <t>Operators need to be able to rapidly introduce new network services and adapt to new contexts and 
application needs. This will require advances in network programmability.  Today's model of 
vendor-defined (supporting service features via new firmware or hardware-based networking features) 
or operator-defined (supporting service features via programmable software-defined networking (SDN) 
controllers, virtualized network functions (VNF) and Network Function Virtualization (NFV), and 
service function chaining (SFC) will no longer be sufficient.</t>
          <t>Software Defined Networking and Network Function Virtualization (NFV) have opened up the possibility 
to accelerate development life-cycles and enable network providers to develop new networking features 
on their own if needed.  Segment Routing is being evolved for that purpose as well.  Furthermore, 
network slicing promises more agility in the introduction of new network services. However, the 
complexity of the associated controller software results in its own challenges with software 
development cycles that, while more agile than life-cycles before, are still prohibitive and that can 
only be undertaken by network providers, not by their customers.  Rapid customization of networking 
services for specific needs or adaptation to unique deployments are out of reach for network 
provider customers. What is lacking is the ability for applications to rapidly introduce and 
customize novel behavior at the network flow level, without need to introduce application-level 
over-the-top (OTT) overlays.  Such a capability would be analogous to server-less computing that is 
revolutionizing cloud services today.  In addition, it should be noted that softwarized networks are 
built on relatively stable (and slowly evolving) underlying physical commodity hardware network 
infrastructure. This is insufficient to deliver on new high-precision network services, which 
require hardware advances at many levels to provide programmable flow and QoS behavior at line 
rate, affecting everything from queuing and scheduling to packet processing pipelines.</t>
          <t>The evolution of forwarding planes should allow development life-cycles that are much more agile than 
today and move from "Dev Ops" to "Flow Ops" 
(i.e. dynamic programmability of networks at the flow level).<br/>
This requires support of novel network and data-plane programming models which can possibly 
be delivered and effected via the forwarding plane itself.</t>
        </section>
        <section anchor="security">
          <name>Security</name>
          <t>The possibility of security threats increases with complexity of networks, the potential 
ramifications of attacks are growing more serious with increasing mission-criticality 
of networking services and applications.<br/>
The forwarding plane plays a large role in the ability to thwart attacks.<br/>
For example, the fact that source addresses are not authenticated in existing IP is 
at the root of a wide range security problems from phishing and fraudulent impersonation 
designed to compromise and steal user assets 
to amplification attacks designed to bring down services.<br/>
Going forward, it is absolutely critical, then, 
to minimize the attack surface of the forwarding plane as it evolves.</t>
          <t>A key security aspects needed from the network point of view includes to verify 
if the packet is authorized to enter into the network and if it is sufficiently integrity protected. 
However, when packets are emitted from the host for these new communication services, 
the network portion of the packet (e.g., an extension header or an overlay header) 
should not be encrypted because network nodes may need to interpret the header 
and provide the desired service.<br/>
Lack of encryption and integrity validation, of course, 
would at the same time increase the threat surface and open up the possibility for attacks.<br/>
Mechanisms for authorization and integrity protection must be developed 
to meet the line rate performance as services delivered can be time sensitive. 
At the same time, the size of packets should not be significantly increased 
to avoid negative impact on utilization and overhead tax.<br/>
This limits the options for additional security collateral that can be included with packets.</t>
          <t>Homomorphic forms of encryption may need to be devised in which network operations 
can be performed in privacy-preserving manner on encrypted packet headers and tunneled packets 
without exposing any of their contents.</t>
          <t>Another dimension to security arises when the end to end service that needs to be delivered 
crosses the administrative boundary of the originating host. 
For those cases, additional mechanisms need to be specified to sufficiently 
ensure the privacy and confidentiality of the network layer information. 
While there are lot of avenues to tackle these issues and some aspects are being looked into 
by various Standards Development Organizations, e.g. IRTF PANRG on Path-Aware Networking, 
comprehensive solutions are yet to be worked out.</t>
          <t>Any mechanisms specified for authorization, integrity protection, 
and network header confidentiality should be orthogonal to 
the transport layer and above transport layer security mechanisms set in place by the end host/user. 
Regardless of whether or not the latest security advances in transport and layers above 
(e.g. TLS1.3, QUIC or HTTPSx) are applied on the payload, 
network nodes should not have to act on this information to deliver 
new services to avoid layer violations.</t>
        </section>
        <section anchor="trustworthiness">
          <name>Trustworthiness</name>
          <t>As future network services are deployed, deployment scenarios will include cases in which packets 
need to traverse trust boundaries which are under different administrative domains. 
As the forwarding plane evolves, it should do so in such a way that trustworthiness of packets 
is maintained - i.e. integrity of data is protected, tampering with packet meta-data 
(such as source authentication or service level telemetry) would be evident, 
and privacy of users is guarded.</t>
        </section>
        <section anchor="resilience">
          <name>Resilience</name>
          <t>Ultra-low-latency requirements and the huge increase of bandwidth demands of new services such as 
holographic type communication services make retransmission as a mechanism to recover data that was 
lost in transit increasingly less feasible. 
Therefore, network resilience and avoidance of loss becomes of paramount importance.</t>
          <t>There are many methods for providing network resilience. This includes providing redundancy and 
diversity of both physical (e.g. ports, routers, line cards) and logical 
(e.g. shapers, policers, classifiers) entities. 
It also includes the use of protocols that provide quick re-convergence and maintain high 
availability of existing connections after a failure event occurs in the network. 
Other techniques include packet replication or network coding and error correction techniques 
to overcome packet loss.<br/>
As the forwarding plane evolves, mechanisms to provide network resilience 
should be inherently supported.</t>
        </section>
        <section anchor="privacy-sensitive">
          <name>Privacy-Sensitive</name>
          <t>Today, there is a growing awareness of the lack of privacy in the Internet and its implications.<br/>
New network services have to be sensitive to and comply with heightened user privacy expectations.<br/>
At the same time, the need for privacy needs to be balanced with legitimate needs of network 
providers to operate and maintain their networks, which requires some visibility into what is 
happening on the network and how it is being used.<br/>
Likewise, mechanisms to provide privacy must be provided in such a way to not compromise security, 
such as allowing anonymous attackers to prey on other users.</t>
          <t>An evolved forwarding plane must provide mechanisms that ensure users privacy by design 
and prevent illegitimate exposing of personally-identifiable information (PII), 
while preventing abuse of those mechanisms by attack exploits and while 
affording network providers with legitimate visibility into use of their network and services.</t>
          <t>There are a variety of privacy-related requirements that ensue, such as:</t>
          <ul spacing="normal">
            <li>Anonymization: To prevent tracking by eavesdropper by packet capture, 
visible information in packets such as source and destination addresses should be difficult 
(ideally: impossible) to directly correlate to PII.</li>
            <li>Opaque User data: Networks must not rely on the user data to provide or improve the service. 
However, network providers may use specific service-visible data in packets.</li>
            <li>Secured Storage: Some services may require the network to slow down the delivery of the packets, 
implying the possibility that packets are temporarily buffered on the router. 
The storage of those packets must be secured and prevented from extraction 
for deep inspection or analysis.</li>
            <li>Flow anonymization: Flows of information should be randomized in a dynamic manner 
so that it is difficult through traffic analysis 
to deduce patterns and identify the type of traffic.</li>
          </ul>
          <t>Potential mechanisms to consider include (but are not limited to) avoiding the need for long-lived 
addresses (to prevent trackablity) and the use of homomorphic encryption for packet headers and 
tunneled packets (in addition to traditional payload encryption) that allow to perform network 
operations in privacy-preserving manner without exposing meta-data carried in headers.</t>
        </section>
        <section anchor="accountability-and-verifiability">
          <name>Accountability and Verifiability</name>
          <t>Many new services demand guarantees instead of being accepting of "best effort".<br/>
As a result, today's "best effort" accounting may no longer be sufficient.</t>
          <t>Today's accounting technology largely relies on interface statistics and flow records.<br/>
Those statistics and records may not be entirely accurate.<br/>
For example, in many cases their generation involves sampling and is thus 
subject to sampling inaccuracies.<br/>
In addition, this data largely accounts for volume but not so much for actual service levels 
(e.g. latencies, let alone coordination across flows) that are delivered.<br/>
Service level measurements can be used to complement other statistics 
but come with significant overhead and also have various limitations, 
from sampling to the consumption of network and edge node processing bandwidth.<br/>
Techniques that rely on passive measurements are infeasible in many network deployments 
and hampered by encryption as well as issues relating to privacy.</t>
          <t>Guarantees demand their price. This makes it increasingly important both for providers
and users of services to be able to
validate that promised service levels were delivered on.<br/>
For example, proof of service delivery (including proof of service level delivery) 
may need to be provided to account and charge for network services.<br/>
This will require advances in accounting technology that should be considered as forwarding 
technology evolves, possibly providing accounting as a function that is intrinsically 
coupled with forwarding itself.</t>
        </section>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Informative References</name>
      <reference anchor="RFC8578" target="https://www.rfc-editor.org/info/rfc8578">
        <front>
          <title>Deterministic Networking Use Cases</title>
          <author fullname="E. Grossman" initials="E." role="editor" surname="Grossman">
            <organization/>
          </author>
          <date month="May" year="2019"/>
          <abstract>
            <t>This document presents use cases for diverse industries that have in common a need for "deterministic flows".  "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data.  These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet).  For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8578"/>
        <seriesInfo name="DOI" value="10.17487/RFC8578"/>
      </reference>
      <reference anchor="RFC8655" target="https://www.rfc-editor.org/info/rfc8655">
        <front>
          <title>Deterministic Networking Architecture</title>
          <author fullname="N. Finn" initials="N." surname="Finn">
            <organization/>
          </author>
          <author fullname="P. Thubert" initials="P." surname="Thubert">
            <organization/>
          </author>
          <author fullname="B. Varga" initials="B." surname="Varga">
            <organization/>
          </author>
          <author fullname="J. Farkas" initials="J." surname="Farkas">
            <organization/>
          </author>
          <date month="October" year="2019"/>
          <abstract>
            <t>This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain.  Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path.  DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8655"/>
        <seriesInfo name="DOI" value="10.17487/RFC8655"/>
      </reference>
      <reference anchor="RFC9055" target="https://www.rfc-editor.org/info/rfc9055">
        <front>
          <title>Deterministic Networking (DetNet) Security Considerations</title>
          <author fullname="E. Grossman" initials="E." role="editor" surname="Grossman">
            <organization/>
          </author>
          <author fullname="T. Mizrahi" initials="T." surname="Mizrahi">
            <organization/>
          </author>
          <author fullname="A. Hacker" initials="A." surname="Hacker">
            <organization/>
          </author>
          <date month="June" year="2021"/>
          <abstract>
            <t>A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.</t>
            <t>This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.</t>
            <t>This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9055"/>
        <seriesInfo name="DOI" value="10.17487/RFC9055"/>
      </reference>
      <reference anchor="I-D.bryant-arch-fwd-layer-ps" target="https://www.ietf.org/archive/id/draft-bryant-arch-fwd-layer-ps-05.txt">
        <front>
          <title>Forwarding Layer Problem Statement</title>
          <author fullname="Stewart Bryant">
            <organization>University of Surrey 5/6GIC</organization>
          </author>
          <author fullname="Uma Chunduri">
            <organization>Intel</organization>
          </author>
          <author fullname="Toerless Eckert">
            <organization>Futurewei Technologies Inc.</organization>
          </author>
          <author fullname="Alexander Clemm">
            <organization>Futurewei Technologies Inc.</organization>
          </author>
          <date day="5" month="August" year="2022"/>
          <abstract>
            <t>   This document considers the problems that need to addressed in IP in
   order to address the use cases and new network services described in
   draft-bryant-arch-fwd-layer-uc-00.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-bryant-arch-fwd-layer-ps-05"/>
      </reference>
      <reference anchor="RFC8799" target="https://www.rfc-editor.org/info/rfc8799">
        <front>
          <title>Limited Domains and Internet Protocols</title>
          <author fullname="B. Carpenter" initials="B." surname="Carpenter">
            <organization/>
          </author>
          <author fullname="B. Liu" initials="B." surname="Liu">
            <organization/>
          </author>
          <date month="July" year="2020"/>
          <abstract>
            <t>There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. </t>
            <t>This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8799"/>
        <seriesInfo name="DOI" value="10.17487/RFC8799"/>
      </reference>
      <reference anchor="I-D.ietf-teas-enhanced-vpn" target="https://www.ietf.org/archive/id/draft-ietf-teas-enhanced-vpn-10.txt">
        <front>
          <title>A Framework for Enhanced Virtual Private Network (VPN+) Services</title>
          <author fullname="Jie Dong">
            <organization>Huawei</organization>
          </author>
          <author fullname="Stewart Bryant">
            <organization>University of Surrey</organization>
          </author>
          <author fullname="Zhenqiang Li">
            <organization>China Mobile</organization>
          </author>
          <author fullname="Takuya Miyasaka">
            <organization>KDDI Corporation</organization>
          </author>
          <author fullname="Young Lee">
            <organization>Samsung</organization>
          </author>
          <date day="6" month="March" year="2022"/>
          <abstract>
            <t>   This document describes the framework for Enhanced Virtual Private
   Network (VPN+) services.  The purpose of enhanced VPNs is to support
   the needs of new applications, particularly applications that are
   associated with 5G services, by utilizing an approach that is based
   on the VPN and Traffic Engineering (TE) technologies and adds
   characteristics that specific services require over those provided by
   traditional VPNs.

   Typically, VPN+ will be used to underpin network slicing, but could
   also be of use in its own right providing enhanced connectivity
   services between customer sites.

   It is envisaged that enhanced VPNs will be delivered using a
   combination of existing, modified, and new networking technologies.
   This document provides an overview of relevant technologies and
   identifies some areas for potential new work.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-teas-enhanced-vpn-10"/>
      </reference>
      <reference anchor="FGNETWORK2030" target="https://www.itu.int/en/ITU-T/focusgroups/net2030/Pages/default.aspx">
        <front>
          <title>Focus Group on Technologies for Network 2030</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="WP" target="https://www.itu.int/en/ITU-T/focusgroups/net2030/Documents/White_Paper.pdf">
        <front>
          <title>Network 2030 - A Blueprint of Technology, Applications, and Market Drivers towards the Year 2030 and Beyond, a White Paper on Network 2030, ITU-T</title>
          <author>
            <organization/>
          </author>
          <date year="2019" month="May"/>
        </front>
      </reference>
      <reference anchor="NET2030SubG2" target="https://www.itu.int/en/ITU-T/focusgroups/net2030/Documents/Deliverable_NET2030.pdf">
        <front>
          <title>New Services and Capabilities for Network 2030: Description, Technical Gap and Performance Target Analysis</title>
          <author>
            <organization>ITU-T FGNET2030</organization>
          </author>
          <date year="2019" month="October"/>
        </front>
      </reference>
      <reference anchor="UC" target="https://www.itu.int/en/ITU-T/focusgroups/net2030/Documents/Technical_Report.pdf">
        <front>
          <title>Use Cases and Requirements for Network 2030 Summary report "Representative use cases and key network requirements for Network 2030"</title>
          <author>
            <organization>ITU-T FGNET2030</organization>
          </author>
          <date year="2020" month="January"/>
        </front>
      </reference>
      <reference anchor="DOT" target="https://hknog.net/wp-content/uploads/2018/03/01_GeoffHuston_TheDeath_of_Transit_and_Beyond.pdf">
        <front>
          <title>The Death of Transit and Beyond</title>
          <author initials="G." surname="Huston" fullname="Geoff Huston">
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="Handley" target="http://nrg.cs.ucl.ac.uk/mjh/starlink-draft.pdf">
        <front>
          <title>Delay is Not an Option: Low Latency Routing in Space</title>
          <author initials="M." surname="Handley" fullname="Mark Handley">
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="NET2030SubG1" target="http://handle.itu.int/11.1002/pub/815125f5-en">
        <front>
          <title>FG NET-2030 Sub-G1 Representative use cases and key network requirements for Network 2030</title>
          <author>
            <organization>ITU-T FGNet2030</organization>
          </author>
          <date year="2021" month="January"/>
        </front>
      </reference>
      <reference anchor="SysArch5G" target="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144">
        <front>
          <title>System architecture for the 5G System (5GS)</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+19+XMb2ZHm7++vqGDHhsloAJTUlsetCccORR3NsQ5apKTZ
GG90FIACUK1CFaaqQApW63/fzC8z31GALrs3Zmdj2OMRCdTxjnx5fpk5Ho/d
rJmX9fJBtu0X4z8615d9VTzInjTtbd7yN9mzfFe02euuyM7zruhcPp22xQ1d
8vZRdnnl5s2sztd0y7zNF/142u7yuh/n7Ww1XtzOxxXfPd7Oxnd+727pNRcv
rs9ePT7L3jbtO37607bZbpyb5X2xbNrdg6ysF43r+rye/5xXTU0P3tFLN+WD
7N/7ZjbKuqbt22LR0W+7tfwya9brou67/+0cjesH122n67Lryqbudxt6wMXj
6yfO5dt+1bQPXJaN6X/4KevuQXY1yR5i0PapTOeqL2gF+sF3TUtzeF2XN0Xb
lf0uaxbZ1bZti112//QPTy/O7bpinZfVg6yb/ksnz5F1mdBQ9wbwepKdr7b1
fNuW6RBer/O9bzCAi7ovqsGrtut8NimLfvEvS/7g4JuuJ9nj2buiHUz1uina
qui6wZd41ZNtv22L26LMrovZqm6qZlkWHY1gNhkMoO+Lf5l1k0W+ncyLvVef
0SSrYr1O33xWFe9pp4m+ki+/8c3Vdn5bLv9lxo+Y0L3OMRG167ynfeINf/Xk
/I/3/+mP9usf7t/XX3+8I79ejB9NDlPuprO7/unHH+1SXuZxX+TduKhXeT0r
5uObTf0gy+j7J09fPL5++/LVn+/d+eHOA4y0z9tl0T/IVn1Pjzs9vb29nZT9
dlLW/WlRn15cvx5fny6a2bZb8mnoTuui57tPL/Nl0Z3OC1rTqp/k3ea9PM/O
KN0hByhr6nSVaPrZi6K/pVOW8aPovreX/+BoHtFnOGenb1dlX/x8mW+KdrKZ
L+JBZUfxa7NxdpY9rLbFpqXH82nxo9yNsrPNpirp5NNBpVNMdJA9z9t3RZ89
anHAsr5hJkT/rorsfxV5K8/kCx8Wu6ae000ZxpJhLLwK8dtHGSZzhPHNicM8
oBfs6Ku7P9JHtE180dV2+vTeb7Yyj4qKh55Pq+JnfcFwhWiBbrOror0pZ7RR
PJnzfJNPy6rsD+3cg+xR0c3acsPLNJL1o0Wrsqf5BndfFi2Incgwu8YMsrM6
r3Zd2cnMA+MLDISnIqSq1GEL9HLW2wK9Pv/NlsWP+udXxYYY+HBNvHTBjF4V
/7Et2wK37q0H8dv1Om93WYsnZUf0xLbo6Foc92xLj5r5R70jzlzr3e3nHvt3
LNW9O/fujO/cpU8evbw+vFSrd3WznNAATm834xnJI3r36XZTNfm8O6Vl/uPp
nR9O79z9+WnRLBY/bbu+qX++XhWPirxf/dwsfr5u85rkzM8sDYXkhytHV2e4
HIdLLo9OyIFZCefFGzN5JX3xE91SFbv9WdAk6nY5Ica+nVUTEjHbd6frX1an
JKHbqqzfjSH292iczgGdtLLLXjQ8nOwlyPdB9qy5JYWClmG2y141255VgLLO
rjb5rDi0BTJYZgs2xPTk3tULB0Ne4VpPpXfvTu7euXPvdLOdnv7x7v279+4v
7hPr1luVmz7l546VxKbjp3ez34ay5C3ptAakJedFvhPa+ldaM6IvJq6rXXdG
Mun+0wNTZRrjU5BXkx+Wmw0LPxIX3bu+2ayb+ZaE+unVppiVC2Oz6Z+Pip4E
aAfJ8j+7+JuL+Z9+uPv73ycrRAPpi3XGApJY7oylMybL3Pn+U/v6+P7TqxOS
hG48Hmf5tOvbfNY7d70iYpgrQyCNjeh0DhZPN9fEEHlJaQHbJVNEWGl+/sXl
hMm8S3aA3j0vFzRckoyub7J8Pm9Zhbkt6ShcXDJRlbQZM1bO6IWiDuAt82JN
b6dhkdiQtxdzkjSuuGmqG/lo0zakazbVRGaxLudETc59x4pXS+s64yXKPnxX
8p8feXIFjadkwgiT6AoIPJ5cQh/9igZSvJ/htfQyZ1TEg+v5BIOvdSYh6Bl8
mc2Edb+Wbhllt6tytrLPK9JF62rn5iKAuuxoWnT0ngXNvD+yp01YXFZFRtJi
x5tAw68qGgetMknoG14SHU2XkRI1I82K9njb0gBaPyLSvLf04pyGhs8f0T6w
PMv+0lzxutNWlFgg2pZoEDw/R/PjTcuKmtaoKFpeKGzZlL69Lef023Kb0yL0
Bb+IJ9411Ra0y9tPT2jmucyVhrHBUt3mmMSSdIWiltPJ9NGvtqCvHf6qmRHd
ELmzbOb9zoP2YVPjjb8RuuSHMJUSvfJfs7bphFht/SfY9myzbTcNkSV2KSbx
ktWXrGoa2tjedmmUgcp41vwCt4COG9E1iEMp0mia/pjuknczOZt5BjV1Ql9l
G1o3WohKFpRH4+zBWddv5ztWl/CL0dQy33S0Rf1tUdRCZKaJ+EuK92XHXNrR
mRq+VSiWLkroew51ZUqjLmtZk3QUjj7RdcYl//455ft/08xkLXUzbcGdLXhf
vO95sfSRuOaW9xD0zV8aj9obPt1CtLCmYRHh8+A/sad4ih9DQ9eX623Fh2Ve
dqT2sKXJuifWy46/vr3jKcpJxWHfG8RtWVV+xxvSYvm5pTxMyING9d13exa5
DJXoYZ0dDR96lMmqhy3wZEkvKes5030BYnOguHlxU1QkM/gK8CKMqirfFdXO
D64tcprFvLnFyZbR35vc53c0dPJaZsN0/ratPJnokczJXni1CGQ+UnQOZsyt
7DnY0xVpq6zT4qEjJ3RFjyix7kRdRNg7/Yu2pitxhj89ch6y80MmNi3vCdxV
Tw2kUjmg2XXDwgWi0X2ZPh3LBVbpgw7LBCeTD9z0w3cvXp9fXH5USdgVIkM6
KLPl3wohbn9SaM1y5QarnKTSlE9oM2U+FdiB6BSdrBevsolVuqQtquImlw1n
Zp+rSZAcfZrdHj3OImNkMhgt/9q3W4j+uSxrR6qSft3540APK0rIhqVYp4vA
4ty8VArQY4ldoytM/5B7dPI8K5pR3ZeLXaoZQJrwJWsSB3nVNfqgOrm+7Lqt
KmyQcQ0f7Hmiw3SOvglCRrnFmuZOaqCfGg8EVE53L9pmTWea310uVz1tTrzy
kHqOZ7ZuOqaAvB3jmEZcXsm+YXugBG3j2gWZuCBZHnpTYwPo6L9qKjCjJ+V7
ev4LIynaPVK7gq5PfwlT0E+n9ml2/PD+05OgUZg4XBdKIDSBqlzTgsx1aO7+
0/GLV9kxKS/jNp+XzQkkzIJUOV0g5o/+gURsOVR5unv76tmzc7Hm18+vzzM3
PAmgZ1W22MO3NHlFcoRfRTwtODJMYcF4nOllzLFn7+hJnT5oHksA4qHjRUuG
A4+rNHnGA6rU8ohUDGzUxeXp88tnVxF/MJ1suhvTjXTcSeemx63zsu6g1IxF
qTHxVLOor5fEBAN7apiqbrxGZeKGzlC53tCW0ykmFYsPOpZOxe+MB/vhg9f6
P36cYFOL93Q+etHieU+J8WHtsZxEHPSRLfGIHlRjh2lj17T2vMBkbDl6L68R
vc1mPM2hXtBqjlf5tvKPmLC8oXfmNNJiZCq+XN1B0e+IN8omrkGwmLD9yh7Z
bR18O8uiLlrQ+bYT4Uhsj9YVD3TdmvUW5pk7WMagNYgt8EJ+eUM67aqg73iq
SlH8t6lq/D3xL94benbByl0Odfl2RYyTPtqIrWkUMN3Ol6KfQ5dVUaXyn/3F
IK4NlH3mF5lQwLQR5clYDQ+NJAWd7rJmPWkGydOJ3q9afeTkch8+qCuSdlVt
GiI5ejBYSlssaPFEi4I99H7D9jxvOD0wn9Ikg8CYu7MtnZbTN0TyDS4/e3X6
5lXEZXhNiM+vxcbG7tQ7kW5HpAOQ6d8S7zkKd0zchf84ek7YPNvxcHcwIlph
nSviiGMym2cltCIliFbOH6uJENUjZyYEnYmG1y1v10y39F1bLrZLVv7paTTi
LTOdLQwFf7tX6XLSjtfTCntCAm9GQyGqw34T+6R1nJAlOrQdcWJKUMUae0iM
HGaCqrGZ2lC7QGtqVzp8KrMrMKOjZPePmPd4Z9xslbPtS0YOf8ceThHykd0V
ZmSqtH6ZObIcIKGVv2HQeD0dSuLCpILykiSat6kBfPJ7khnM40A5tO1G+DdE
PHYqnZlwtzwdezO/OJGbEOTbmnSkkuUbMT5a6A5yt5mRYcNr7N0KRCajRJXx
c2AbiHUqHvY6f08q9NqPCnswa7YVSy3mimwuzSfup+aW9Lt2tHfIcLboSSNw
0b4rqgVd1BSd2HmbDXuLRRJ3W7Y4S1V+1wUdexqlt29MX8fBFXl73tT0UiL7
GThrdCjOdY1MBrv4xNgCekkH2wlygNU2UXDyij+LmYLftnmxqZodHWy2GIqq
ignFP5P0rV+KGZ7aQ/lQQuCHxOJuJj4OEleiTeNa0mboJMXf8gm5Ztpn/QPs
mXVNkoHviOsnFrJpZ6xDtSVpxzgJIo+7SeQCyYRQoHjS4S9Y2tP7mjXOU0ck
UvCmiSAgg5T+qYLLRZV/tlL6YumdNJvgdjHG6rUGSK+GN9nLWkzKNdObstl2
/tlQTzrWOJXQLi6JframAtn6e6NpzfpW4ico6puSWAxOLBnEwux5g+nrbiFa
ed3U47pYEleDp8ELBFar9hmnn44xRNnP0Z7uYns3yZwQadVsSfODRI6I8Gzb
N2sM1jmJoMXc2pMR01tXLmucWXiP2JtWiK+MZVHsuLG7mDD5GIoQjjjdkPhi
rjRx3sgS60AW+MOH2IurSk4XuZ9gdUJYEXOoWfUoZ44WrWaN/IbfEjsumAYy
pQFjpVBXGyLTBbE0MpM4ENmTzpAwe2d0xtuLmZtixUwC9knO+0o2yXJlivuU
iZe9jaoKqSG5YRbVdw5ylv1+HH7GYr2+wKgWW3pmrjs0U2ufX6zeJhAEXR7t
GNHujH1AnVMlLt62bLWld+GoEIOp+VGmVqTrSONWocarRldjUV28ydF+jnRD
RRqSglqNiSrpY9Cg/7oSAtdVHrPTJdkgCDwwsryTMY5tR5J9zHvVrsAbYHfR
UdCl5TUUseIHVDW3dBDn474ZF5FSb8x9VsHEgxjTNXUJQWbR88VyxBrxY38p
sTjx8EgpumiubTiYE3t5RTPGC3L2GUQOVbGJbfgs2dptDSfgbsZ2AS1l51jt
YwYIkuMb1mAkd+9ka9F/u2gRRvF87S06Jz6V2B4QRg7xOkf0RdQa4k30XXh1
VrHHZGQ2AY28WmxrsXLtEPJS2LImGgZLQ16NVH6Bx5ghww4jEsFwRsdOCBAA
jc8WfmgiMB/GZkCDh7rXdWIes7oHOw3PsM1hn9uCbTKyov1BdO6M90d0Fm++
iOMop/NXz3OeSV7F84I6ud5WfUlXj0k16VKtnUYP9UtWeVfPVqxm/k2Ornm/
YIGCAdDUwsk2JsV6F8si5S6kAJOZAlLQKVQ7bLt/FimZUOChFFYNsTfZXz18
7NdSRdQdGpcoYcEeA80QHakSUomsohfzIPcJd2RHphOlEyaaHQ8iLL6S5CO7
xVm4z42qIKlAufENZefEfBVWJB6thlXKuTgeOuiX7IZhWiUxB29gV/bbXAnT
8ZHgby8uXvrTyOqDeu7Vte991z/+OPkRP/8D5jkd8GKuh5ckB63fO9o5lxIh
VNopc7xFJYPl62maVUVfj+ekipFWSeyFxnMWHS5hjmwvMmBIFUuVybvs95M7
8FLAvzRynjRogrGnIzt+eX2C9fPgFTZOPFwiO77g78XLdyNKKxtsqqo0dOb9
PvoDzR4NCcZgy2d5S6obqfR01kgFm3H0d822JG1JO7/lh2/o3PPru2CiXbYN
CUgyO5nbP6PBzkwPhtV3fPns/GQUuSk7Yh/0MtKUaPsqPJ6ddeuG7ZjGfLEF
GeBs4nnn7AwKTZkcAba+8eX52eXjf8PqvKRfvJJoLh9lP945QSKflO9Ie4oC
G3orLQhxud9NyyWHXPPfsZ7XNnReChPnPOCBNNanJyOmFYMfhjTsoh2wSygn
DrRd7cTKMBeNGoPKZkd6VEZBRx8oVYkM46MP3Vbd8xBfIiWFU0GhzdjPhBt4
C1TKtiJmu4mokW+IMIkRtbSpj2gZBEKg6Dnnht/SyRBcjpp2t9D6wSFEhPNS
cuQz6B1TdbvTjbSfrCD0Zb2VodNms3aBAzTJXtaFl6u0/BdrDr1x4F0cG+ti
XubyLBvfhw9vyjmt09kr9qecpWyfn/Hm3r+JnQD5TOKkI0UwS8Yg3g2EuDB4
idV4zX6dz4sobkhHg7Zu3dRL0pzkdUx4kGC9h+aYs92poz64MZh7Bj6hVk0c
xBgpC+i2LVRrjUWpZaqIgQj4pZYocAvqvcI17L7CaSTdoxZLK77t+MnTk+Re
UsgT5NrHj4iq80T+FuLksWersygVMbSymXNcpgfgQY+PWDVkJ/Zi0v7rtgL2
6o8qJKZrpvg5C2eF8tALZfBXCFLKSO/+kOFmIg4G3BDL68PkSBMjflqblix7
DS5YTrcif+kgZYjeWpiCpuBkPuZEsBNOEvhhMcu38DmKzcLGHNyBfOlIPt6P
3bgoQE+TXJS18j0GiSw43kb04gXD5/cQNPeu4GVhhYoIxpxdLfydcqYgVsFX
AJX1gZQJA258ZM92AXEbjosR3TbmLbAwPetXNkQVgJvttCq7FXtgQFIHBitY
rCjskWf1dj1lEN5iGM8uOUSPwF2PsOlcLXCL0tEbQ6hbiQqPZ76grnybZCQQ
EcJKAubTwk3bkgRLKkcMG9KrZVTAxQwBXn9qCmS+eWCGj3PgZd57oIwXQTAB
IsgL7HJWRmu/5JuyEHdS7DtOsDRKHz5cYOeJyd2xTr0reiF79m9WhXJ1rApr
gPxsVp10fznWxygJZjai8XkD3A3DwrrPSmFlJ4xeo1kfPry9/PhxlJrs9+ST
1+cfP4JAY6XFIk+gwjjUL8dH8Hus0in+yQBdwF1JxFARWMfy78lnCM2lhDYM
xDFviUFcg0UWphZYl/dC8MesD1XFkpZ0LcgY/lDos6TX3xJzZbea2i7gF3l1
y1EICebQ4NhVq6RP5i9tdkWkiKiroJ5iO0qoi48pqexkekLg0HxmBQ1c94wD
dezJ89O49VOJA7f6rCKcOV0NspzoJMjyf5/9xAepzTck8sbsqxgYZdnxT+fX
J3TdNU2Do3Ax/iR7JZbXS9Nn6fLri1cv+XrjEQC3+thL7FY9fnF+zlc+Kml5
iQNd39L0jh/hbQADjq+Z/lTtujBfYBT9PL66vnjBlz8n0U6fdvRr5AdjK/WY
bdUTFQqsq3l424SdY4JqiglXTmUSLBiAVT58eMxBmfkV+6xMVkPJI2L2x6mz
k8Hfy/GhNwpnbiJezqkEDLLYF3ud6iE5HDA8JzWe3Lpg4u9G+3JEg9QsDyXo
39SFN/M3+Q4HPTs7yDFG7vNiKeMTgIWVg9aleCqGtbDZXe/WMHLpbHAkb4Qj
MWOSK1V7yhZtAf/vL8QVLe4ZTVz0nMfmlecFZHDFcyh/MWA8+/CdV/5cEguj
1Sok6rWQmL96jtmLQpNgf41oWuo7EFiFWM1OdpQuY5LnCDUefCNBtrbIfFx/
Oy1JH+95uskpVp3fHxV+oGHr4DI2D+yCRfhtwfAJlRfiiYcCT1zwltWakjWM
aufMAcmuJ7MljQmkTKTJUu945OqH5sPwuS5LhpfPmw1OKHHKsQG++GC0uYd7
eP+0opiJ7bKp9CAOhkcrj9fn83yDRcTyjThIbuZ6iMCDdLCiAV8o7tAxmzQ2
UXmdPFdMDTqjrTEsAatcJA56s04iH3I8VJPpql116To6OXiwuOYKG+XoANxF
PBxFYyYWfKoJrNntsWAdbhp8UHM6k5PssVgoLEwEYukhlBx0vynAiRqWcIvx
Ju9XLqAjWZYpsXYSxNyLEXGEQM9uYVFhuL9gp9WIjDEeRQGqnteNdMEMCyNO
BXAVCXyuQQKkeq43Hu2hcVCEquceLRieEaxqrDQoIShWnl5YgsrbRcbBJ+SD
3rba8FdvcDQVx+LgMuTVJN4ekFFq6cbLNoiTKkttzQDHwVd31dDliSVkFcnj
2/Js2ZDJAxJkz1ZbFvCb8xTZzZ69EecHCckcTofjN69OGH6JJRRXARn0fpVA
nn/8syyP6F9CevAJxoBanh3f/4m5MSzyzSs4/9oiWLGsYRttYuciK9orEJE/
JR96xpgKFahrfrvIR6x+/kkmlh+vbb3kDSPKs/WN/a2gxtmKUR8MfmDcoBFO
TMQ09Rk9dstet+A4wflgobYUBgcWWLbCtcnKZvKp3/mxqZZOZzGNd4lziUh2
spzIzFjOvAIC6fj+0xe8X/BTBc/78eN7j0/S5Q4bjjPGbjSxOTgUEfCFUzUr
lWMvAOR6du/UYDiRSe0WxL/603U5P+WgFlA5Ac8wUmRX8rgkVpdHtoRhrzyg
wfympSk6frkZxfgosLjnOPrO+xfN5r0tPKQ5tZaEhGIuKdxjkr0tFAWIN7q9
K8wDyHoBAmYPWDW9FrimN1H3bqNrvJYw/DK6hOQBEznY4+2Bp8DuMak0wDEz
RMngfpHR0CXxWAZVBfF7k3chmBqWOQRX9xeIlJdsQWNTmE2sjohGRzu92LJR
oMczQhcLRwj7g6V7LA7Ox5JOALi9jyR4uc+0NWUFsexCxIX+XwPfo943oaed
c3JtyzGDaOwsyCTMo4DlECgtdoI8ZkWE7Wt43pRQ6eFL9o2EYXgEgarSgKdA
djP/IrrOvSdCaCKOxtMoGQvBAcWyC5iggTpEvG/F5hf7nrNjfiF8+4KHBH4M
y79iuI3faubs/MqzYaDLrxVDTsYa/lMVQRxHZhsKRlHUeAaPb+u6QK4F78Xr
R5d0+I2hy0hE9b2OiP7bDmT/pSMzxBMTswHfhUW2ELjVLtuxgoBoNdlFmqOy
YKbvdbEoBeI7GvHDSK2yr9x+ZCIEfBnSPV8WYKv0b2xG+VMA69nHCYa3e5MM
7r1h9gYtOsfieG+ZsTv1Gpd9uEIA6vJXlz6eYfh9lO9iHozWQ885tpHrRcMn
a/CAkxy6FZMBjMbnl+PzKqebZ7AEOanq+/F4/H32rT+fuAtP/DX7if73rT+/
Xt20B+7SMX7/d43xq+7SVDh999Xl3fhLzyCSn6vLe/rbr/HdE/8T/z6JP87i
3/VuHicNdMJrygPmu3V9439+x3dnctFEZ6frff44wyMuH8v39PvZ1d3v8c89
+ecH+8IuIo76+FdPAV/x/snw/WN9v/580+zdhwfZd4EaJbXvT0dndfaYT+S9
Mf+T6bcRoz4KiQty1soYF/quZkrPNelsbElnpYIrOVjtColEmSjwZ5YVSziy
+/yd2FAQLd5s6x0HUdkcgJoTKaksrMVJZg+TsF6QXuLMg9ke8UXS4lwsysTu
SBRe1vo2jdrMgvLl2JAXp7ULEt3zFK8eQJtsiyVeN/IsIsKBC6vwVr2n9sfv
SStmlfjS85zji3+77E4i0Q8uWTXTvBKVNwuACMzYwbgj9ZwdjoC4judFzUIr
75nHW8pC7qFAfL3ulYv3htNulOHGH+uK0FxY7Uy21WE72ewzkPZ0538jS9hn
lIhUKEMMSQM49JhpIcBWxFWVw+vltQuZVHAZbJoNrAMIkDUyYes+YALaIkgK
EZAO4kSSRG3RbX9sd2UAUGK8SQpso6uZvgBjYbfGJAg5j1P3xKB2ufrg8RUv
jQp8YhwSla7djCi/VOigZkdFwLDBaclndMlcbW+8AhkZorWws51pViCNqsSI
Mdlt2C1uLriUlryXw+TdALfsI/Sq1xjEMszeCDtGR6q7w1J0I9+IYyWDdQuA
trV+hp9hV7IyIndva81A85RJgr3SlaTvme3EThdSiAto7Ikr3HLpfKKTI8pi
L8yF92OWdfDTgJSiKE+Sz0HUst04TRnoV50o5TRkRg5ly5JN0864ks5Ns37V
7ys5704MsUmmAGf1rmXdrKgZKJStt90wrygM0uOh6F9icIVEpi1XEDrZY1tX
LTThPApzqCUOlafYQNPwvkKX9sJhx28uXwTAwih7aC6JyeQEDrQGPNKSivaZ
aspzA9g8KFOCBUz2E6d62xKVwsxQFuoPgzk+3Z5W6POCPaKQXTc1QwzY2zDA
TW5o4GCateGiJUUoxB/VByHMgPNjjy8ub35Pav3NHzTo8PSVnHP+SKWC1jwA
qcL7olksgHdmV6/oQjEzgl2LbL4ZQsuqOyY/B2V+8hPdI4rFJNUjrwSCfeiS
6NZfzx/f/ZU++/VS/mXFwsQUj0K+uodLzunfL7zVYkRfeOvXT5I1m1iJOaza
6GtZnxkyb8OvCyLdDeV6SOQlBUJIGzFz3uCV+K/Fn5YDVUzEioAVAtfIXZDI
N2+zsqQAfU9epGbVS+ILY7qMzKQNg8OuT4JWMDSvvuJ0HSsei7Mdfb4tj5uU
C810F7PWx7rlYMUDpkHsL4uZ0ceCSOf5Ait0jmhLdvzo/MSfqpN/jry8OOvO
ho2ctalPfQawTh6twgLlfcD2Hp1nT3Muq7XTT/3TeBFs+nTVldz/JG/XhkyO
WEY8yosIWcpDvjhRliC4qrBHlgb+CzPoPLUcg3XZuGaT/8e28DoFVpHVBwWh
IVUaLDqW7z7hxbQBIA533stTWmB3VVZd772ftC2BfTM2BjjzCE9+K3b/hrld
fDMUBGi2pWitpGGJoPc+YR+RqpvwRB7himWvPUOn6VSVMnG3jgsnHAFVMjsa
kPm5gWWJ+CL6fitkctsEYZDAf/2KejXOit/oCX/g8WDqUzIVlU9vsm1KeB0A
RV2o0MBeV9KBCtXhwgELZ+BYgpuewBW0h4h9q5HPvfMtTglV4Qf+A+i77Ja7
uLrUzAmwJ5x0sWNmol34GzznmjXjPdyxi5VSw/x5v+kB/9J1nBPltfRBfQUT
rYDam3RnQmDAG8en56pd5kEZ9wHJPbkc5eyQjr0CMJKdwfmcseM5cgEXZQvH
qiXr+aeYm58GCZNn5ASQHK6VG2SJUOVuqO/bJW5ooMUowDoXuOom3ykIEACX
sp3H+ulBNPIwOyZYPVwVwecG7b3dz1VwusJ8TM+BVuW1PSx50PayD989vpK6
NB7bJnDWMhRV00CuqEWfq4Xi4h0t1l1R3RTGLjLvokt2ESP1eDgOejpkSbHn
0cet1GhreVxqohQKBT2zwkAF3JAOEa+QVRrHniIYn8Io03vNgagoFCcnWsyM
fqU0bDD7Mk7FVOmDeKLCx0hBpyPmBL5jWoHEkeJ8qDmjVeaGNIncfZGfLnKw
Rb6sw26tL+l2Q09WrFINFal919WvY/35/pArcHLQV5W+wauBd/0NX623HVDd
xo8v97U3e0esuUVSynbrKjsmIzVEgj9B5YGHnwBNmvuDtUVuSCVXrcqNMK5N
mCFj2U0L0FpCmeb7+YpSisgaGNISinSWqMRy8kDkyaPPxeURisc4neK0bd5Z
6SyRvk1EjRYEPX794mIQrGS8Cx/dJCSDdFKLlcgpMOcfPUGG4ZIaNnpM+NFF
16e+oTTzb19JhaLMdUs4s4eL0HSavesS+cBAeNI6FMOzBurPIO8h+y7eJne8
CAUL4HUSE1Ggz6sAdOONhuduFqm7JxMfB2TVBgSxTwRGgneN+28F80eSZMsB
JsdQy50nCl2gfZkFZYM9CT47SNcARAr/Q6erPGKBgzl0EXZP+GOpb9f34P1l
8KQQNaNKLRbAynvMS8YLz6SgAnJ1F2UdsCMjl1v6r7ntfPIsqUmjrFyEYYx4
IuImExvB5VkaEPPYI74mZ+v1J9UadaWDiWLYHpCmOAGiZJro5DqyyjnjjuGt
W6ngwDxZw39xqSMgryxiE18L/h14lvkkxQEtJZ7M7yLyzcSr6my2wknVIBK5
T68+7knkp3JLJJifsmTeFwl3fzORkMqE7JuFwlAqZFd3vyAV9t7x/TeLhV8/
NY9P/vz6ha8vFXR3KWXmvuFh3zC6L6xA8vOlVb73ras8EL73srDK30oteseQ
AvdVlaGofnNlojr2snB89HMCGwJhlMjtu/8fCG7xKMtX5l73aTMQfT8xt7ki
Zkx2vZkocHX4cX7FpIL9eU/dKeWXX3yPXvwQsZSiXzXIAey8PQcOulfCEA7Z
4WXOCogJYwtRlLBn3d6mDabnDBALT74JwStsEZ0DX3bMvOFRJD2lvY8fYU35
yI8Bo8reKztQcojCaKGqdVwSrOuaWRl8ciEoYjEJ70GOnBiDWU8yhZHDOC97
LxI6C1q5NIQkteoFTsMmSM2+4xEyajkrb+RRLLBaggl2fJnQMW08kJEnkll9
w2pGgg8CGNNiAOKHcN7JpI6XlaagS1mxM3FWiB8gO77Lxu694JE50dKI7NyY
i+YUVUbjESO+h/ED28dRTLUP9Vg5gb2pVwSro3kn+pGPI0ntOHXSQB7n4qaa
ibdu6b1/TiFMXkTrK9Mnqkptt+nzNznqKmhARFwB/CbLpAwew/jdKXKE1fJh
AE3cBB2yB3pTtIzilYCiJ7rErYURsOpTm2tO38sLm5jmHazLKwkcRUnxfmx2
9b4l4WN+nsSRvs0qHrRTUDOnKJS0DD41KwQffqL/s99/jYSn/12J6cXbVOr+
dSCEB38/Oh8/ffunP5ngFtXpT3/Cx+mVp6fRTReDh+pTH51nT/Ipp65+5sdf
5HQC9t9nfvxFcs+V/+8zP/4iCNDzn8ZPzp6b4PzMQWTZyWdVIzRHr5FJnO+O
AkNldybTxv2npw9DDbjs+FyRs6e2F+aC/4aD3MfOwORMu5AYoPLg/sO0FKEW
HbTxcFGgJXtDHvswxfHrx7/rTjzpIqid+CuJMXMFCYYFyO8B4+6x6gGOEoIs
dKK8zNpzvhawCqTykVTP0QBCgDdoZMdFh8oejmoJea3O9NQBCuzwqXEe2j4N
6qGyxFg/T71R2fHzx+cnkpzUSTZ8MmoaQhvUkmP+a4yLT+iYcvQ3k+RCHYEX
xoyR7lE0deI02UD3qSsSGKclIDx88XSU/V7qRtLe2cI7GfXpq7MXAY0cYYav
YQKzXH5//+mLtySOBRLvy5rFPDxxZXbctcFvTmFKI5gTMNg+SiD+RFqXbVur
B7T2pSTA65fLtljK3pBKrYhLvcEKhzEzFj+r8XpSKjTEz0FZrbis4Z4h41V4
CgozGXdHNhZz3raIr/cZVviC+EssXyy/Vov6+Kz9kT2y2fbDzRw5/zoWDQVX
3D7HYgWpQkxwlIVxRuUAvFuF1J+NFEzpmm07K2xvddlzgU+gQksskDrh+mB1
r3lvH9ve0vE9wceXKxLCp8Xzhw/x5+lBBihpgEX6F67/a/amoC0LAWhhmH3T
sss9/UtfcPgVA66tf50GTKq87a/Zo5YH/PrszZduPvXvO/DGWL743z/4l/xV
KpV8eYR/jV5y4DUHJ/XXLBWS0Vv/+pWP8LO4EDEmmQ9mjp5f0VHiX87ocOmv
43Om6MvHEGE47ybBAuPYqoDa47siyWI8PqdbfCkAFaTHEMqcIwvHV9DNbgAE
R7AgrvKTKqKKUPePVfQ6kk1YzBom4aqCGeXTqLJOPhB/mxlQi4yLjki+tT+J
HdcMlqqLkkY/C5xMkz3fXL7o1GJDEqXUgy0CSJ8D/pY3FaqWyR1iaPh82OA2
5VKqMVTBF2qLJ55cNFQUpVIg10URf5znFMTSQrS/imJDXVKMrOyaKg0+snIu
N4hnUxx7ksESareFK+JEFhYkw9iYZEOhwjO74fg+X2xSLg5vtKA17IQFsGK8
pXm961FemeynbZ8wZ25d4L2PeIiWCgsIc1+iUpFNHsHJJeThLKBxWSWp95DM
KArCDlqDhdIVIQbGFaPyWsJktvJwNKDAk85Q8Hwo5oCyCY2UhkDZ04XSzKcH
wLFJVJRICzFLlp6WZuQCrJzT0mjhnKqwjgI9w/fyNkDi6O2OFoAGILgElEzO
NdJ3NG3atrk9Ij4AxzBbu1LlI0yZl1kJMkdhCNTH4aSMXN7LMWNOUorAf3DJ
8mHjQ49g4KLkpKZ+p7uNtHkr6ceZPlymkpGVAQCo05cS82YD2v4FPNag74He
5ktPS11aXw8QAdaoJwiqrcYgUVN86QhpHk/oGeCizCnjMHHJNEEnaaaPohSQ
iSEq16c7kSHJ4BnnQHL9B8HISh2mUHuGmLW6bGbFps8ODIVdNeikYCUwJX6t
uA0TQPScUA31LFSwh1GubFzskxg7J7jJpOEI0p9F94A7o3NBGe5VDY8TrzIt
Gru2o6WMgKfCNFGjHBRXHWu3a2G+gw/l+KB4d/yOJVdNteo+ERtiJ43e6Xz8
xzM1fCX45cDEZHQA0G6I8Ea+NJ4hMc01Et+kfEIeKEfMY4hSj0p2nNdmnxso
hEuMnziDAIsuXXbZ516gZdf1NUAT5/NfctZnI2X/rVYS0KNyYw/vVmVRwZK0
7MZ8psAHzdHOa5420Lqqg/sdYIEaF1fKBH6EtOIe7FiLq9VattPKW3FV38KS
PhHOK1w6cuzcCLlAqnZPi5qOoi9CDrZpA0Eip6/14azs0kjresiw0IjCin4g
X2onMTDoBsKl4H/0EaKya7dofYVqSrH3D8YC8EV0oOhwtFspHuCpFLhCpGb5
nLVAzsyd2wIWjhnqGijk5dVnZIuiSGfJHnZzMbPE2CJ57gDxx+vq7bxeoCty
QNXsrK3cECtG+S80ltd/5jpzTO+0CQKTo/3fwhPJg9MjyvwgoIoSQBYiuaEy
dq+rnxYDNyqzeqFpEQY837f96eJCO+bb85FJZoqiqd1/miSG+EMuRMemZoDv
QaRGRXMTpbOBOsVWaWu4mbIdRlS1ptczDc0+QlyTmKgUif+nH38kc9orWnlI
A+2QwWGofAcua7WqfZxXHha8fovilvFqtLJ+zCdpbYg6tFcQmSX+/1CjlhZ4
N/HDtTeICoJCXOyF52IMO4d6s7yQcdHrQ/13TKbKG8XI5RiL8/WmFaBwI/UJ
rCYKb+ueg5JDR5Y/aG2CQoKpFbBgkPavf/CFUTxWSCpncKV6aIZSsNY0JcSO
8Em0ICEswFUEL+K8SJCkLZGK7gjL39Hzps37ItogU1qaLq9wi4tLUsej9d2N
ZvQ20DrjPcdSWdu7gAIhhxY1HnP96faTH7578eL8SkJ2voBWVNUiKo2jdZV8
PWf0t+GiOGkZrf28AQdtzVfQmmREVO8KLkKf3hxVKIPZY3t7sOKRPVTTc5OC
tD5ANGHcuWh+fjR10+4nGISi8XS70/kHlxMDvArlezYZHwYgKgxRsUTlQYIw
F2Dhkvlpa50QOOqTImJp9UoMrzcdGE57etQFp/yU1byTzCtkETGcDkfN+c4/
pm8z6bC+KklRVoRrrEW4/llrE3Vae0jrgIXCR/e04pe2hXPSKYnHOYJNTDYj
bySn0W77zbYPXTSmqrNJOYBhOTENHWGnrcAZZ2iQHLFcKAUn20HytWG/E/L2
VE1EzCS89wbtDIRVPFC9YFDnLSHS+BgAP2VxUKbw0EEjS8tvpz135qXVkWIy
umVlAV2vS66jwxTxffbEJ1oH0EiXHT+58lAuZRf0HMBm5n5UjRbI5VWs/CHR
TCPxR0cMVEtCeD3IQ5PULqfRoS5Pm4Jv4qehhBh78mCShMGeX1md2rV0W1K7
3J63iOeYFP1xWu5g7gXs3jpqTUSF6GzXwHrNpKrTQAdoXVjfpNANlwr1UDF4
as6vQsJXvl/uzJKotOMik58UFCAS0GsNG88Op7qQKs05hwm40DvpYXNUqNdv
9fjzUnAVWggY+LPUdXSYCh44N85+4v4qlx4Je56WabFrH4QFg7JvpaIZjCuI
r0HkL0hZgRvIFuxXWWcjjTlf2uZlWC0mPUjQnti1kLdSd8DacElD0zGtsxQw
PzB6KZ+ulH+g6LsmLYgvM+eMVRxwmBPQhTT0G8WJOkFfxLUXIpfWXJ9FVPWo
6ElgZqKO/eH+fWIgKFOEmI70iOMKIdi9mPBAJda/NlTBlR4RpVWAuLic6PRf
fnr6+zMfR+Xup0K9Nn1pDDPftgo8lqefN8gYxZaGN8Sf7r3N/EeiA5EiwVmV
tfWFXxDFWmEN5SKGoegtcWd/p7jaGmvDEs5b2I4RIz0OTtwg8H23siF9sqt2
nP0FmcniYEmOwCdpCOfL0jiJY7YCIE0KIdGwKsWVig8G5ZLUnlATi8vaJcVF
gQgaVn32baZ2g0ryNhTfnkfdPBMXJat/ohuhImBeXJ1x7BE+HhV8Qw3u/EvC
D0WzDkjAAzUkvVY1KPLvAupGYpCq3o+ycr9ilckoKRO4ix2Lofpd5s6iIUmL
ubiKNMmDWmRnogCEoi0ocTQlI14qHqP8DLOHd8Hf6zhtSbuuctBujFzgUK1a
2slZE409tfBTfSJ1Z87PLi8fv+Ba1Eykz5E0oibjA9SpHORz75WvzYKmmbQA
TfybkhgzE+PBrWlHtnFlsx4p+ZzxsaeZJnTbkKXWiDf+hk7T3DqCMiekExHh
WRzOoDV6mPNoLT9Vj78tWDzMzsaJctbsfpAirNZyi30J7MfnTnikvfYQiiLg
opLzIYXmbMly9lm5KMboZkErikBMkp0k1hkX+Y4W1QOy8005r3aOsVHiPzff
bXHYUJHiiCTDBSp4G5q6DpNmrHvUmBhQVL/9moHh9EymQuIsD3BaiWWwHlB2
a23F6BVMaehZ/q3wbccghAV2FDKExM8luD5U1OQ/1Q9pQG6r4MM3WsH62lLT
EgwQ6wbrcrv2GoH4VaW0NgeZLCGBXTlW78nsUWICuWI3ViEZi9/9/Pr1oT5A
3nvrFwHuqN67YLNpo5LET8UiPBJmt/QcfAInMksXlsyocc2dJtCcMrT9Shoq
NIkDNeRYaekFXYwQ8RHbPVA67/GrgqgHJf8eZK8rkiFjkoleMu/VGkT4fbsM
bQrgJvYBEVEjOjOXPfWZw8LF2Qv7ZXrDDdCYBzJNOlj4tY4ai0hFE7MJXdUI
htCy4xJmD7Fo5QcmmXT7YvzJyK9k69dEDsdNw9VZ1SvFfhIRIhbBVOFh5Ca+
RabXQ42nsOiXstXjK/Y+s+R/kF2HpG0umAo2z10sai0lIjSJzlBGKcZXkwKo
DOiNy7gxK3pxiCFEzRU6G4YU252LzaqACzJTlyuihmKekGnSxBMCb6+LiHdH
LZpwW1zHcZpXwlSlFOqwPHUkzKPCVX1oLc1DZbcUFIo+Tvb1DjbPwGFPcsDe
MhdrVHUT5u0EAyWtapNDJRnxt7qpoZyKWMdtocYO5+UW0q1FJzo22yM5QgJO
IWOv8J3nH2RO1dszFB3WpjemUEvu9WtjGfoxODNrwTGYZJw94WzCPHkMUdvZ
bEZGWB8LoDdkLi9KL88vDYRplLYO4iiXu1XfYcWES7xEfSXdgM9Iam52cfbi
jOtkR+4N9RN5ULZvcmjpRejuXFmtXK1hxw9CTUcvjoZP9V+UIdLaePBnHNf3
qn1i5ci2Bp+mrykvgfq3khJkwbxaOhBWvklWFZDAeWwlsBcgBr97GIPP+hKq
8ri3uKi5by7ElI+61K1VS9d3RalyEbzBsu5XRX6zuy3SXonMXnRI47iIqUoS
1GMf601WxkhFOs4wZyUzQ4Mwoim6RZ46wzH/kNE6yc7EoS1SFZn5kfLHjQk0
BqCRxcCltEPg54qbC/xdm48oWDxMNVgunr25pKTyfhSajOMf78A4Ds6lXNuC
9+YkSz12Rkiqlu150dKqN7IGrHaBoGH8zMv32d0Hmbgk+UhLTwGelnYOCN3Y
P3wXSrbDYvpC1Xs9cAaR+UXgi1pPH1uBTGpLo06TCzmngHiaov4leGz9vXxd
8XCifCEOels1DwggDxm6qEMCNxzPWi+/vy21PrMMqahlNVfBEwWsX26mcyg2
Zo/gClv0bo67k8UwFm/+LJ0iG4m0M2KDI/VEwKxAb864OsW0aT1DsCqiKNmj
adVNmCNbyqiYAkgKU1IPWArX+UoCHPCGSAaDJz10zOyka44+0CHDsZpkPzxC
cyC0DKPHdonRiloYdMVNWdzSXuQK+8i1b2Qz3526pl3mtSBJOsObND5Ndmuu
8CXpVgxS2WWLfE1SIG8xbMv7YUgMR75IHC/RD1t0SxCvjwJgaJj3mnnWMuo2
bBFieL7ZTLGVRyMRdeJ7FK8CNwDToj3xMBf+vNp23szqYzej44Y0EQeMFdU2
YqSoIyua7aDY9PHDyytJET7xl8Tp+MfSyxCNGYRUUON72J4OZWo1PWXIvw59
FzfC+h4p4QqiVoHNhVO/qkkFne5b372qkAJx4qXm0h9Wl91SoTBRiI8g+qS3
LApSSHE1vCFqEibFIrSAlmCR4VXo1OzSdppOLXATAYf7fw6q8Pvoo8JlpNiF
82/Q0VhX7W7LddBJpLw6+LlBSvLahSIsXL/MIjDvtSIS9xgibudrr0sUa8Ra
npWr4VrsrTFwn5XmvepoCmwcXwq1KUCF8Zm63i4K6v+WFP8PEfz1dNN9JcVf
ocEYM3qOe/2mJP/IovaSskYKM1dqtiaU4qDBMfiq7ikSfViS2TEWhKzPPKBV
yZEojcf00WMi3KCCl6RFhks7I8DQ5f3oFTg1I61qkz2jFXuck1aSvWynRBjH
zx6/PGGfeFFVQm8Mc60qi+mJP4kuUqMrd8E1GGH7sOGwe+HnyPteG3doU552
uQXDhn4OC9e8ls4iooAVEblPmWdrehYs5NwqRSbKGfcqgZv1w09EI1WxI82n
k2JIJNUWAFhIjn0n8vyHO3fu/Dm0OhfgPk3MFsmXrglSyWrmM+nv74Ae/e1m
jEL3EBvx89SfghWV6nWKgobGwakv/GBaqny2ijVZu187E/q90XVCFa74OnWn
QVdwERiie7fTnFU1ls2hw3FfrXAQfz94GTspIaQbJpSoioRPB00wAsGGiNJ1
FCQe+QCDSvmfw1vOQl3IPKj3WAotCZg4aQBwloIIqa9KEKG2sTTKRbV9z5XK
r4K/KzAvdmDP0BG1Tpc5kwSpFNox6EglHoV07OEB+dxcTBITPiCWtdEGrG3w
Jt+qKbSLL9hD4d1AfXDoBOT+vGx1W72nP3hvQsE+st5Ifi6LmouEeF8pwq44
IiRDo6Qav5rWPzttK3wgONIJJptb5aBnKs46e44kZYitF2Y5iBlU2jg0ghCx
VdZEPYmjlfSt7faPuvTmyZJqw4LRilvHjSwyzeDDTg0Frby6kxRhmbYsScDe
r0doKieUzqWCya7OteKXuY8i0zle+gm7FlBoy7qNWLiBgYAdAKJhDS+aa9ha
zrqrJ1l/sc3T+fK11vVluD0dSZS1BmRYTzdVRauixh34In+TwlWIDIpa2rhp
xiRTyBiJbamuNdIjjc6grKF3hcXnzXUQtTHiB/oZROcq7Jy3425YdhHJiJSD
GRUIT5onC2jOQGyRg87D0nui9N6yKcJAh2uFVqXYaS3bJToa3C92Gokyn8cm
2yotEOvPWqgGB2EqzHuQz+hTSQ5VDPKJFnGypuCZZpoexsASieP51MoocXJC
UvfRy+uPH4mD75RVs4dq0BTCXhKyctY5Kl3HWSfxPdqzC3PRehRpEbBOWgsO
i9X4GF21INoPdbAtcklLG9cHOPxaW50ETJxrvwhfOjcsc2gXYV3iYxFRBA6x
lXaaPhVWn2gzS6+L6wXanIv3pJ764E4EoRgurNXKNIryWQVZXq6T42DpJbGz
NBZBiSvGCfVijivO42TuXkRd1G0ukQ879RHd+4yP6F4CiUxC6HmMZwr+o3tW
BD+350vbK2v6Zm385Omf7M0oSQz6dB+BNBQloy8/ugDp226sV+g/guPjiL+L
m3r+Hdi8KN79CcydABP+G3j3fxt4lz25yiytAra1h9phhkn7Er461jsuLq0r
lCmeGin27mjTwI7jdoAnKWxvuMyT7LcEA06y8yt4E47Q676WsKJ9exRZfV+F
D3SfwAdmn8AHiu2oHY6kHJGKT/cFwEAzaB6X+ucT7GTc7fwrsIdZgj0Uy+W2
GQLvFF/ISWq15tMM8InG/YVG+IoBRvEANtFXiFigOyjR++HTwolN1tje+m7w
q+pCkU9xDVmuMjETJocGgKRFW+uMoDj4mCYfrJSsnYYiPPpfIA/hoNmrhVo8
yGwP9RFToBsCuQ7uXabpwl+HxXTu664TrLVIxH385G8F4AQ8C3zUQi3bTaXR
ZBca9yXrEOWxND6NslGrm81rb29qb23lxXsmcUl8rM9ZHiKc1nnXw4EOdpqk
FqYy6BCYAMdeBtx5aEHpyXJBMyfDhp+y5CTSjNsOavcGj4cyu863wTDQE8fL
y1q+i8OU2V+aqzi9l1Qd4KpIyC8RaJ+LzUDTQgipWTj0GqS5Lzl/SpvTc1YN
D9e6LLCbpdOYeOziEyyS2dx6nH3B8FGcgCS5xMG5EQ1S2sDDg1D2W6nAheac
TGkwI9lBQebBTZkHzW+33vRNyCaXJH+MOm6pKhs3MsapB9MN7pAEOcgcHmS3
aiQfNQ5HxoQdmVheO3Aq+JBdBms9Tn9WAhIzMtIn1tKOxhJyjc+lUOZhC+wD
R1F6p5lGM0+BgZa0GrinFLOWgOjMMhbAP4a4Z066kU8+AwAeQJ8Pg555Ypp7
xbZQnn2CWXgvCC+oOMqK9zPoXR5rkeVunb8v19s1TLGNOIK895u0SC2BwM0v
pT0o1GwtuYAuQcxrTjhTRebnEu0sTpxJJLT11Is6vGMDZhW3qMObJOXFD8v5
A6ot6IMo+Ys2MyJyeew7tqrkRZGYsgE+Rr2aI8d+gqCnxXYbJ7dLrnqcSOAT
sgZD1tiMi7ruqEz2aQF9I6FieuC5LylBNFap65HPXbONkTm5cQBXNc3GPIW8
A2Nr0Apn65g4+kYCqrbVviIOFny1JWGQnWbTEl2M+fxwjiXt2sjtrWGHrFI/
GjiuO4FQiT0sRlzc5IA5noceZZuyACKMKGrGkEiiE/j0JGxF03+oBfwgoUCA
YTWZVpT/jWfMGXmwx0alDHsdz8ksZTcI9DBEvDTSdZLCkvnpkGBNG9BWA+Qc
GhAF0prsN0D7QibBt+UQuP0cgi9kD0iXkD0e8vLLPORQEsEgfWAUGulIDd3S
Tg8xkzVz7oTtSI8Fxv55jIhyHxqxZtzx8U4OK7HHOWOvJCwAFwXXLGCBbwNs
5DYNkEwNdhLjy+mZZIjZt77eVarS+0JXaXfQOLtkEK7zFpllQzhNfPBsyCP3
Sl1xv6qYBTLEk9d5Nx0dsbJlMJMbvkSR8eUmD4qXpkxIsUxVXQJ3XkoDbWSj
t1ypotAecp0A4GPuSs/bVjlyvhVqjMbp2XVaCEKWmw/2HmNF/KwDYP52L+sh
9n/G+nbHAbQ5GtorrJlssulW66yhhwsIZF3Q8Rv5oLkq6V3oFE3MawufIGK0
ALCifo8zqwYQEeE5i7jC55qYQbvzivuhnBjn/p6cmM9kwzhPH1/MhvnqPBgX
5cEA4qSccVhu9YvU7r5E7TKxQGbxSbIGKcBWCr5DYYf+7hnNu82HCQkecJdd
aDxKHd3o9iqgAcadpxws7oc+QhOd+V73stIX6T2mtw4n18xmZBzwCUATpNCH
mzmeb1GJKdPDeRid1SLEBl49e3kiToGZ0QiijPlOUmkGORYxBqJuQir7ASUu
mVrO8lRqvTODFdLKQ5VDrfaUUESU3iQqKQlFT+dfTpNyLr7mE7jy47+YF+cr
Mqg+lTPlhzkvCi7on2ZagVUFHKcZZr7k8lcmWIW3+AQrGpK5f6yfZdyeA7bq
Dlupitq+mz7Kj2rEQpEIFIlgWhlxlkXIfcHoe816z4t59ur0zatRDBs8CEO8
CCCgBKy+lx9ArJxrOMEvLvqPZmwobJzrrZircqFD3XNM70JAtJOYoLI0tFRB
1PxTyWaS9PRfMeNM3BSAge354c85wS5NSNtLCfvPyk7L3FsY6qGRR3MoW+22
oJVEb96RHsWuBzpE6mmrPKB5L0qx4eJ3Kq/Zb7+40HQk4Z7aujuq6MUkNOdK
Ob1Hd2hZogyaE9/QyWo4NljQkVn4lWTMmf3g3D+UMgcdrawtsB2wPgI41QFA
kbAEnDrJYAo+gU+/kj7Hg/AcVOAgmRn71DIX53zwZP5WtPteNGBm+SEceoyb
RwkmyNeMiKtykH6zbYP2iWotQ91fslF8sYhOITOk5MOL9f9kImGQid+aQjjm
eaAD9EprHnr6k1CnVcwYYDEGRqvyLaEC5q6MoNeOoexfqVG63mtrqtUgei8T
HYubxUWCRpZ0UTG2wGy8iNEBLWK8LsqOgnyKF2QwVCc1UfpiUPUj7F2SMxfd
2UwR5pX1iXpXwdAQLV08+XRKtJVM0iRhkl3pwKF4BxV9eFhCeR7TSj03BGES
T+MwDYf1Qkrakt9vcxPIWJwEherq3uePALn3sqoh4EEV0lsHzSOjeaKClhaU
GYlbmNM01psVql9jb6JJaDNqC8VGZaCE+ke2nqPMJQfBaj5FKyyVLrm9UaOY
P8VUSCNSPetPUO89X0NPUoYzUiHkEo5sp7OsV4XWYQwFQkOuQRTiW2zreG2k
64D5sVwwYzzIJCQsCGnQMeVh/o5TxKqtlYfSgqUXL8+ejwwmwBzA18EUCLwL
neE0NFPWAXEnGTse82U7zGod6xBMMpUkv3SH6W8sItdxAuog70StR4Efh+KO
WVf+rfAAp2hzpVo1O/7BXKeWM5cdYZRHtFZEsVKBR4D9lheJ+HXTx1mo050u
N12P1qNCWYHIvaYQ+kTSI11EhUcd2fhEp0e0vBMiYS0Gi2Qgrg0GfoVlG6t/
8novfygynqLiSZJ/C6ANDuERusYzLzuSoqv+rkGKIiuTEeDdKKsT46hFTSef
yBq+1Q2tpIG3Py1ifNXWLjLnKkvzMSAQA6tHigWJxcaUhs7gevgwGZRAl8lE
mZRVkb+DitGJdpT71iQBiegL6sV+L3rbtLMqa9IBXJ+VhAO/KnPduZdfkab+
jyWnu/3s9IPEEBSAqCxwPAMmIj3rAgDj+dPazpt2bN3DjpU/xdGbRYEwjNQX
R5y1bNe36ArewlHNv4+nqMAfQcvttpOMnbiWzv/1bwqjZ7Rqs+jxmkGbM1Te
v3r0gl7i0xG5VqS2SEapVJ9s72n2+M2LJydYXAMNPTE++sZu1F7LL568ORHO
5cO0nucSqyprGcGT8xOVNA0sf0DUIp4B0rrSSWSPdBIvwiS+ejCiDdNyIiV5
s0ffToF2lSgTavbhSFeebjtNysLaDtuVdgJbxn0xwcabSntqOcdo6LMIFeCu
iiXe9kpBKT5xWGweq2XA4kJBkXqEWVQGjN0o88hfK2OrWqgmnudLS2XGGgyL
9x46aT4/VFifU7ypusMhMoKnMdCTp74YU854YZ56JK/EzrJrXbz0uuqIzWYS
m/WTKER1iHdnqin5cBkh0EtzX9EWw7nj5Sj75x2K0E41MivG63S3v6mjCAPD
lde0fQO78F4xm/IicugqQek5z6vQvMbcYArqaIV7+bIMW4Sok+4U4BZbhdzC
Qxc1Xg1dsKJRvVWzgLP+40wVJfPF0CV/kN3i3AbZXzeszHuNLe8TIQ0RBKE0
8kmMxtSjR4aXmnHQ7Pd354+qfMera319gn8mgIRICjfLZuuhIvQcaIkBhmvW
kWv5+EBBK/+G6Dt6tAdbWpXNSMKPOIoXemNwfVelG6XRmDvKFjkYX6wcW1oH
O/0lTnwMlxWtERtP6jg+ifEAPj0UdvqcZ2rSIWx1iswOPYZJ9wkKFvgPVFcJ
RtwOQ/vDg22hBkP9hBd7uZgr6NB8raHSTCJoRA9RTEhMKRUnFTnmqXQsYaII
TyPrR8rQQ+kjut8aO2ff4nxbpWib0H8k25Sbgp/aGejW7zAqgQYlX/04upWi
a32Kr3u3KfwQQx7jQCbip2DYN8Z89Ki4yV5uGI3XZEcoooC/3DFU0/muzrms
/ECbSPIpLJ/GnyCGCLjU3o08l3IO4yITwV/l31Na23KLoTK3811AXRKlgTTD
ptAf1n1muIJBac8UtmGVE7SRUhodjaqTs03Z+ZovyuhT4RGA/SKQzaVAFLNG
+QXvNUK6lp43q3UilRoKwQ0pIN37EIaRckj5lD+nquQmrX9yfWgtuIg5a9sV
RzgzknO+tUZkNfWrW64xryPmZ+05W0LgRRMpzEnQhaLNUZNgOJw8sOviEqxN
qadtGvVrc11czSf1u6CeRw1PbYi0Vh7y2uZbOmhIzViTntk1GtZxcTFi3i9R
IDSbqZBcnxY+iF5MJ56Z3y6/VfFjpoh0IgYa49aeDvzY4j2dwqhmJmqbh1Uj
1ox4iIHRsOx4F6Mc0PTZ4lrDfcuRwCCqlOAXzzJOXvPrJOXrQ+GKoSkKG50f
z2n05sgBP9TaJq60cA8YVtmFYlbzUMXKilYnp5ju1P6VcdFdcWHoHkr5c+J4
XhOD+9w7qhjdoI0m/NBRHkttua5QC+lQfIuXNZlqa9w0mtAxR5VHgpOwVhEr
AOwzqfGisls/JMtCGa9C1ch0bHcbdMJQiIu9TwDibC5HagOXhtfELH2LE5d0
ANAiozo4V3lXn2mtI32ZwQbDUqqhDTEf1ep1olvkg2pEoV4VsBlgaJ7UtDh4
fciagJoVjv/zUO8M3yhh5AcGGJWiR72xOASV+Wggvw+SFcZK4luLEHuB0Ssi
RV3jWthk8qnyS+wNit2g6UZGlXFApbJCMjgUvaJtXEo4VYqjsTJC8rmKJ8zE
wvua9fl7L/MA3dOGpRsDXLdptFuPK0pv9CiG7VV6eABxLq2jqfnqMu67vab/
WtQo8QjTiExi8pM1L8Vj65FIccckjM0A2Lr8crUVckI1kRYogTVD0qGShTOg
h2plGSpsmiA7yX+nAShpOEG0JVzbLC4pAo1es8LNtPrdnDZRziZUY2NubdkZ
HAa+4trA0SFka07rfSyHQ2azud7nzH65aD52OKAdhVkQWS+BDuD2KcR/JiL7
LD4nDSWiqubhYMTRJQ+c6ptBIXKugtVaY0PxaGnm80KCFh7jGHM0qbYf1QKa
WACx9+mRlUrRm6Leqi+U9kEu6QrfNBdNgjjYpPIih6sTJf2b5p0loDhGWiie
+UprR3TZo0j5fMkVV/REcFojQ3YuXl0/yS7PXrx6ysRymfer8Rm08eDwGIn1
3RYrbUFi7mcZSYhb8/UF2ukpfezixQ4rvMePRgeZkToWbUGVJQ+XPVhNXPGR
TDTeY16OXlIq6w6qrGwHdK4psigH3+yXSOyQeMrHC6FL7ZBdoMxa15+yOkJb
+iqBFBG195JFL+DeleDTuqiyVez9C4OQclw7nEuMz0H2ZdfPru5Ofhhlf3l9
cc5P/en6+vLqveJCWHkM8RHFfETOGBFyESe1SnrKIHtp8pjUaTRjziVVET2b
lcUiQ8vXjIB2Pii5SXvfWUT4cG6YtlgYxU3mrNSAukstcGUAKGWKnlPZ4Q1x
shbCS7hDmeR/wfSN0oIHHEV7RrBw6g7rcqrFxXb6vOH62qVPB/Wx+D5djFiq
cf0LqwNIox9LRCEQv4Xjyi4oYCQfc1aVgV8IIoaR9fkYVzuPxzXFPqjxUKra
1JEfApUnwcEhnvh+ZDqPMDqBc7aw+zkpAH5D2fNQj9O5/67H+Y31OEETZG+i
YGEUebYiDXAL5GCgkrKrDVEVzL7/PnPPmJEQriVxyifCABaaVq/UhjIh3hsk
PIcHQ5SOBq3sjITSN2NpcqJl8wSyriyqW+UbXLdpuJYX/4bCPczrW7qFCVEQ
r5xgi3hiMGVWvntY6BmTZK0RFc14nmMkJWrPnaScJuLZLsFvsJplhmvIyzcY
Tc5I4Ip5k4SrFKiYdvmi0b4EK4/yeIwjWSpnEcHVgotU4Wrwc7QtJzxKlVsw
2PAwVl2ZBIFEiJApqFD6JS4UCanIO3aACl0Qj1Gk2kNpfBhtr84rEaJUm+r/
u9zrf7Fyry409jlMJzZlM/Z87sRAmElKWeSMMSVmpMFYwcwqUaCYKyufYoTq
kpDaiLSkqLGfKodxkCklc4zLBhtPwWrS+iqPNhOfYWbSS042qRFh77xFw4Qq
nqeq2o0NLwmXcqwMHV9eXJywmQ6lXR8psEFlWWJhRANkYKz4hriFTlOq6JMn
uJwz9hL2HYhnSGhDgvBvjGgpAaZaBvFvVeh3UOT3QXYd4vtc7gu+TJpvQae1
m7eNJIPsjJPN8o3kJTrMZLC0ZfAiDTUXdjCj0Z3a7d5FGRiZr7LDbm9Boj2Q
FAm86QRqLKAsqHzbyrT5U9rRidsvVfzAl2gT0pNCv5VPpwtl0KNDxHWI+GBY
Too5hIK3bH+X2eBHp0KLyhl0zRZJlL86eBHcXgXlBwIBi/Qdr2wlDILNWJ8C
Iq4rXwg5RhWNAPGtrI1h4lISSRz5+/qCVRWiLID/pB2vrZLoC6IXWQGqcErs
KcZzOp1VdFzNj1i8l3py7BVGabei2HDQaWMFe1pflgMLtF9L+gE+6wTgF8gu
aj5Pr0WcUXG0FjhRt4nrmiyqkB4Izreg1Xo3vjyINN9D1HGD6iyKPfSoRlij
rLbyisjdrEhf+uhDyqoNQ+V1jmOprCduems42DcnomPa5nmpxsCGMe83g1L8
GTruB4eYmB7t80lc3h/lBCPHVeSvgrjcdyK5PS/S8RAbHlU2stSE8NyTATBJ
fVtBxkb+r896u/Z8V8FEIvW1LWW3dehmxnyp5rgCohOjRIyVtBCV9AtnlRqy
WLK4VNwcRan2R6rg5YpQGEk8+HddepVVM5fp7T4JVlE9jW6Pbohwf5U2JObC
lqgWIY5ueJN9/rbhZJtbGEbtXINRaOmQXqTf65jUy96XYJeCcUZKaRp9Sqsf
iBBTCJ6IAy2k2iGmo8ozUASkTpCqgfwrcDS7oKwVUF2K6Eti6fBrYNtt9ro2
YkYp9pUPFNCCjQRg4ZWS+ucD2JsaOmLalqx/V6zUVlzuI8lN0nqMyCEyqm7j
PhY00qvEEk/w3+rbtV5sErWUAlfQnqKtcJIXtVbMXlw53ru5YYECvskatbkG
wTvMBSjde/2qapxIirhshnk4sGi4JBbqhUXRcW/Fg2qCiaO5DiJIN1qeLkW8
A0ppNrWnE3tjDEuBYreCJ0TyKuN4SwAWqs9UMBEazheGAQ3paTiyeoiFGuka
b0OzB0Eq3h9sZyk2c7DHiZc4TZpvYzy6h00LwtB9AaavtIa8mOAHR7JUepjo
Ti7n498TBPuxCAvFX6UXCbnZpSeZGwQfvA3Qh0YKsLhWiDrHGKBY5fw8uvEw
S5IQtJfFUd35vIuNARfd4y1fjyoIDo7oLXD0eNCfT1eoucRKp9kELskUid6n
mAP3fwARntu8oe0AAA==

-->

</rfc>
