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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>

<rfc docName="draft-eckert-detnet-bounded-latency-problems-00" category="info">

  <front>
    <title abbrev="bounded-latency-problems">Problems with existing DetNet bounded latency queuing mechanisms</title>

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

    <date year="2021" month="July" day="12"/>

    
    <workgroup>DETNET</workgroup>
    

    <abstract>


<t>The purpose of this memo is to explain the challenges and limitations of
existing (standardized) bounded latency queuing mechanisms for desirable (large scale) 
MPLS and/or IP based networks to allow them to support DetNet services. These
challenges relate to low-cost, high-speed hardware implementations,
desirable network design approaches, system complexity, reliability, scalability,
cost of signaling, performance and jitter experience for the DetNet applications.
Many of these problems are rooted in the use of per-hop, per-flow (DetNet) forwarding and
queuing state, but highly accurate network wide time synchronization can be another
challenge for some networks.</t>

<t>This memo does not intend to propose a specific queuing solution, but in the
same way in which it describes the challenges of mechanisms, it reviews how
those problem are addressed by currently proposed new queuing mechanisms.</t>



    </abstract>


  </front>

  <middle>


<section anchor="summary" title="Summary">

<t>The architectural evolution of IP/MPLS networks (<xref target="evolution"></xref>)  in service provider
and other “larger-than-building” (<xref target="network-types"></xref>), shared-infrastructure service networks (<xref target="shared-infra"></xref>)
has led to a range of requirements against per-hop forwarding mechanisms
which are currently not supported by the current DetNet MPLS forwarding plane <xref target="RFC8964"/>
and per-hop, per-flow queueing model<xref target="RFC8655"/>, Section 3.2, especially with respect to the
QoS support of per-hop bounded latency. The authors of this memo think that solutions for
these requirements are relatively easily added to the existing DetNet architecture by 
adding support for already existing and/or proposed, but not standardized per-hop forwarding and queuing options.</t>

<t>The following sub-sections summarize the problem, solution goals and requirements as perceived
by the authors. The reasoning for these is explained in the following sections.</t>

<t>Note that requirements are somewhat overlapping in so far as solving one of them also solves
others, but each addresses the problems from a different perspective, and are therefore easier
understood for different stakeholders. For example: Operators that do want to see support of
DetNet for example for Segment Routing (SR) would not think that this is “naturally” the same as DetNet
supporting the DiffServ architecture, even though solutions would have a hard time to support only
one of the two.</t>

<section anchor="problem-high-speed-forwarding-high-scale-fan-infan-out" title="Problem: High speed forwarding, high scale fan-in/fan-out">

<t>Forwarders with bounded latency need to support interface speeds of 100 Gbps up to
Tbps, likely over a period of 10 years from initial deployment of possible DetNet solutions.
Hundreds of interfaces may need to be supported in a single forwarder (fan-in/fan-out).</t>

<t>Supporting bounded latency at these speeds and fan-in/fan-out raises cost and feasibility
challenges beyond those that had led to past IETF IntServ (GS) standards (<xref target="RFC2210"/>, <xref target="RFC2212"/>)
or more recent TSN bounded latency solutions.</t>

<t>Note that these high speed and scale requirements even cause challenges when DetNet bounded
latency traffic is intended to be used for only a small percentage of the interfaces traffic.</t>

</section>
<section anchor="solution-goal-lightweight-per-hop-per-flow-stateless-transit-hop-forwarding" title="Solution goal: Lightweight, per-hop, per-flow stateless transit hop forwarding">

<t>Both high-speed hardware and network architecture design (for reasons of simplicity and minimization
of shared risk functions) do favor architectures that support a lightweight transit hop
forwarding plane design that requires no forwarding plane or control plane operations whose
scale support depends on the number of services/service-instances (e.g.: DetNet flows) offered,
but at best only on the size of the network (e.g.: no per-flow, per-hop state).</t>

</section>
<section anchor="requirement-support-for-existing-stateless-steering-solutions" title="Requirement: Support for existing stateless / steering solutions">

<t>There should be DetNet bounded latency options that work in conjunction with per-transit-hop
stateless traffic forwarding such as through Shortest Path First (SPF) routing with IP/MPLS),
engineered steering (e.g.: SR) and stateless replication, such as Bit Indexed Explicit Replication with/without Tree Engineering (BIER, BIER-TE).</t>

</section>
<section anchor="requirement-pce-to-ingressegress-lsr-only-flow-signaling" title="Requirement: PCE to ingress/egress LSR only flow signaling">

<t>There should be DetNet bounded latency options that for the purpose of traffic engineering
(including assurance of bounded latency across the network) only require per-flow 
Path Computation Engine (PCE) signaling to network ingress/egress router, but not to transit hop routers.</t>

</section>
<section anchor="requirement-support-for-diffserv-qos-model-on-transit-hops" title="Requirement: Support for DiffServ QoS model on transit hops.">

<t>There should be DetNet bounded latency options that support the DiffServ QoS model instead
of only the IntServ model.</t>

</section>
<section anchor="requirement-low-jitter-bounded-latency-solutions" title="Requirement: Low jitter bounded latency solutions.">

<t>There should be DetNet bounded latency options that together with the other requirements also
provide a better than worst-case jitter for DetNet traffic.</t>

</section>
<section anchor="requirement-dynamic-application-signalled-detnet-flows" title="Requirement: Dynamic, application signalled DetNet flows">

<t>The DetNet architecture should support signaling and forwarding that would make support for
automatically application instantiated DetNet flows scalable and lightweight to operate.</t>


</section>
</section>
<section anchor="evolution" title="Evolution of IP/MPLS network technologies and designs">

<t>To help readers understand especially the per-hop stateless requirement from above,
the following sections summarizes the historical evolution of technologies and operational
principles that the authors think are relevant to understand the requirements outlined
above and asks to see supported in DetNet.</t>

<section anchor="GS" title="Guaranteed Service with RSVP">

<t>The original (first and only) IETF standardized packet forwarding layer standardized
queuing option for bounded latency in the IETF is “Guaranteed Service”, <xref target="RFC2212"/> (GS),
see the DetNet bounded latency document, <xref target="DNBL"/> section 6.5. At the time the RFC was
published (1997), the standardized signaling was proposed to be RSVP <xref target="RFC2205"/>,
and the use of RSVP with GS was standardized in <xref target="RFC2210"/>.</t>

<t>The function to support GS bounded latency in the forwarding plane
is the per-flow reshaping on every forwarder hop along the path where GS packets
of one flow  may get delayed in the egress interface queue due to packets from
other GS flows. In typical networks, this is every hop along the path.</t>

<t>Early (1990/2000) forwarders for which RSVP was implemented where using
so-called “software” forwarding. This meant that the forwarding plane was
implemented through a general purpose CPU without additional hardware support
for QoS functions such as shaping or queuing.  While these forwarders did
support traffic flow shaping, GS was never implemented on them
and their RSVP implementations did also not support (but ignored) the RSVP
TSPEC/RSPEC signaling parameters used for bounded latency. Instead, RSVP
implementations only supported the parameters for bandwidth reservation,
which was henceforth called Call Admission Control (CAC).</t>

<t>In one instance, a software forwarder implementation with RSVP supported
the Controlled Load (CL) service <xref target="RFC2211"/>, which does not provide for
bounded but instead for controlled latency. This service is achieved by creating 
a per-flow queue and applying weighted fair queuing (WFQ) with weights
according to the reserved bandwidth of the flows (see <xref target="RFC2211"/>, section 11).
This functionality did not proliferate into later generations of routers
because the execution cost of WFQ was too high for a multitude of flows
and the scheduling accuracy was too inaccurate in interrupt driven CPU software
forwarding with higher speed interfaces (100Mbps…1Gbps).</t>

</section>
<section anchor="hardware-forwarding-and-diffserv" title="Hardware forwarding and DiffServ">

<t>With the rise of forwarding planes with “acceleration” through ASIC based
Forwarding Plane Elements (FPE) instead of general purpose CPUs and/or dedicated
QoS hardware, the ability of forwarders to support shaping  evolved to only be
supported, if at all, on DiffServ (DS) boundary nodes, but not on DS interior
nodes. This included both shaping as well as complex queuing such as WFQ.</t>

<t>The DS architecture, <xref target="RFC2475"/>, was specifically targeted to enable the evolving,
now common Service Provider network services architecture, in which “high-touch”
service functions are only performed on so-called Provider Edge (PE) routers,
which as required are DS boundary nodes, whereas the hop-by-hop forwarding
through so-called Provider (P) (core) routers is meant to utilize only a reduced
set of forwarding functions, specifically excluding per-hop, per-flow QoS
forwarding plane functions such as shaping or policing. DiffServ therefore allowed
to build higher speed, lower cost forwarding plane P routers. It also enabled
to build equally higher speed, lower costs PE routers by supporting
boundary node functions only on (lower speed) customer facing interfaces/line cards,
but not on core facing interfaces.</t>

</section>
<section anchor="mpls-and-rsvp-te" title="MPLS and RSVP-TE">

<t>With the advent of MPLS <xref target="RFC3031"/>, RSVP was extended to support MPLS through the
RSVP-TE <xref target="RFC3209"/> extensions. RSVP-TE manages p2p (later on also p2mp) MPLS Label Switched Paths (LSP),
which when signaled through RSVP-TE are also called RSVP-TE tunnels. These can be seen
as the equivalent of IP flows that RSVP manages for IP.  RSVP-TE tunnels can support
a variety of traffic engineering functions, but none of the implementations 
known to the authors ever implemented GS or CL services, specifically because
hardware forwarding for service provider networks was not designed to support
these QoS functions for P Label Switched Routers (LSR).</t>

<t>Because CL/GS where not targeted with RSVP-TE, the signaling extensions for
Interior Gateway Protocols (IGP) required in the classical RSVP-TE reservation
model (such as <xref target="RFC8570"/> for IS-IS) have no parameters to signal
per-hop GS queuing latency or buffer capacity utilization. In result, the existing
IGP signaling for RSVP-TE  only supports RSVP-TE to perform bandwidth but not non-queuing
path latency resource calculations and therefore no latency based traffic engineering.</t>

</section>
<section anchor="path-computation-engines-pce" title="Path Computation Engines (PCE)">

<t>Even though RSVP-TE implementations support only DiffServ (but not GS/CL) with respect
to per-hop QoS functions, its traffic-steering (path selection) and signaling
model introduced per-flow (per-tunnel) control plane and forwarding plane
overhead onto every P-hop. Through the 200x’s, this RSVP-TE overhead was seen as
undesirable complexity and overhead by many service providers using it. There
was also a much larger number of service providers that desired some of the benefits provided
by RSVP-TE, but who were not willing to commit to the complexity, costs and operational risk
introduced into the network by complex per-flow signaling of RSVP-TE. The on-path, per-hop signaling
of RSVP-TE for example introduced so much overhead, that reconvergence of RSVP-TE
paths after a failure or recovery took as much as 20 minutes in networks with
10,000 or more RSVP-TE tunnels.</t>

<t>The design of RSVP-TE’s (decentralized) on path signaling model specifically showed problematic
under high resource utilization. In the original, decentralized RSVP-TE deployment model,
ingress PE LSR would perform so-called Constrained Shored Path Forwarding (CSPF) calculations
to determine the shortest path with enough free resources for a new flow. Afterwards the
ingress PE would signal the path via RSVP-TE. The IGP would signal to all ingress PE
how many (bandwidth) resources where left on every link. Under high load, when multiple
ingress PE where performing this process in parallel this would cause high load, churn
and reservation collisions.</t>

<t>These problems of de-centralized RSVP-TE plus IGP signaling lead to the introduction of
a so-called Path Computation Element (PCE) based architecture, in which the (competing and uncoordinated)
traffic engineering computations on every de-centralized RSVP-TE ingress LSR where replaced by a centralized PCE
function (or at least a coordinated PE function), which would send the calculated
results back as a path object to the headend LSR, in result limiting the functions of RSVP-TE
to the signaling of a steered traffic path through the network to establish the hop-by-hop LSP.
The use of a PCE can likewise eliminate all the reservation state dependent signaling
from the RSVP-TE IGP extensions, because all the reservation calculations solely
need to happen only on the PCE. Nevertheless, the PCE does not eliminate the per-hop
signaling overhead of RSVP-TE to establish LSPs and hence it did not eliminate for example
the majority of the platform and convergence cost of RSVP-TE in the network, especially for
the control plane of P nodes adn could hence not resolve the concerns of service providers
who had chosen not to adopt RSVP-TE.</t>

</section>
<section anchor="sr" title="Segment Routing (SR)">

<t>The introduction of centralized PCE had obsoleted most of the reasons for RSVP: headends did
not need to do path calculation, and P router did not need to manage the available and allocated
bandwdth for TE tunnels. In most service-provider use-cases this left RSVP-TE only serving
as a very complex solution to do traffic steering, and the PCE was doing the rest. 
This ultimately lead to the design of the Segment Routing <xref target="RFC8402"/> architecture, and
its mapping to the MPLS forwarding plane, SR-MPLS <xref target="RFC8660"/>. Later, a mapping to IPv6 was
defined with SRv6 <xref target="RFC8986"/>.  SR relies on strict or loose hop-by-hop hop source routing
information, contained in each packet header, therefore eliminating the need to set up
per-path flow state via RSVP-TE, and allowed in conjunction with DiffServ for hop-by-hop QoS a complete
per-hop, per-flow stateless forwarding solution, arguably therefore lightweight, easy to implement
at  high performance and scalable to large number of flows.</t>

</section>
<section anchor="bier" title="BIER">

<t>In the same way as SR eliminated the need for hop-by-hop traffic steering forwarding state
from RSVP-TE in P-routers for unicast traffic, Bit Indexed Explicit Replication
<xref target="RFC8279"/> (BIER) solves this problem for shortest path multicast replication state across
P-routers, by replacing it with a BIER packet header <xref target="RFC8296"/> and therefore eliminating
any per-application/flow, per-hop forwarding state for multicast in P-routers. BIER also removed
the associated overhead of prior ingress replication solutions Service Providers where
looking into to avoid the per-hop state.</t>

<t>Finally, BIER-TE <xref target="I-D.ietf-bier-te-arch"/> adds traffic steering with replication to the BIER architecture
and calls this Tree Engineering. Likewise, this is without the need for per-hop/per-flow steering
or replication state.</t>

</section>
<section anchor="summary-1" title="Summary">

<t>Service Provider networks have evolved especially in the past 25 years into an architecture,
where high-speed, low-cost and high-reliability are based on designs that eliminate or reduce
as much as possible any form of unnecessary control-plane and even more so per-flow, per-application
plane complexity from P-routers/transit-nodes.</t>

<t>This has led to the development of the DiffServ QoS architecture that eliminated IntServ/per-flow
QoS from P-routers, and later on to the evolution from MPLS/RSVP-TE to SR and BIER that
eliminated per-flow/tunnel forwarding/steering and replication state from the same P-nodes.</t>

<t>Finally, early experience with Traffic Engineering churn under high load
and todays requirements for often NP-complete optimization lead to an architectural
preference for off-path/centralized model for TE calculations via PCE to also free P-routers
from signaling complexity and perform dynamic/service-dependent signaling only to PE-routers.</t>

</section>
</section>
<section anchor="additional-current-considerations" title="Additional current considerations">

<t>The following subsections look at further into the background for why per-hop, per-flow state
can be problematic and discuss problems beyond this core issue.</t>

<section anchor="impact-of-application-based-state-in-networks" title="Impact of application based state in networks">

<t>RSVP-TE was (and is) solely used for services where the operator of a domain explicitly
provisions RSVP-TE tunnels across its domain (for example using a PCE) and can therefore
fairly easily know the worst-case scaling impact. For example the number of tunnels does is not a chance value
arising through dynamic subscriber action, and the number of tunnels in the network is primarily
impacted by topological changes and the (over time relatively rare) of occurrences of additional
services and/or service instances being provisioned. For RSVP-TE there was never (to the
knowledge of the authors) an end-to-end application layer interface such as there was for RSVP over IP,
for example as supported by earlier versions of Microsoft Windows QoS enabled IP sockets.</t>

<t>When per-flow operations including per-hop signaling or even worse per-hop forwarding plane
or QoS state is not a result of well-controlled provisioning or well plannable/predictable
failure behavior but instead driven by applications not under the control of network
operators, the per-hop state requirements can become much more an operational and cost problem,
because of its unpredictability.</t>

</section>
<section anchor="experience-from-ip-multicast" title="Experience from IP multicast">

<t>The widest experience with dynamic, application based signaling in Service Provider networks likely
exist for IP multicast, where creation of per-hop forwarding/replication state is
triggered by applications not under the control of network operations but by customer managed
applications/application-instances. Managing the amount of state and the control plane load
on P-routers was and is one of the mayor concerns when operationalizing IP Multicast services
in SPs.</t>

<t>Service Provider L2-VPN and L3-VPN services can offer IP Multicast via architectures such as <xref target="RFC6513"/>
that attempt to solve/reduce the problem of customer application driven, per-multicast application
in a variety of ways, but they all come with their own problems:</t>

<t><list style="symbols">
  <t>In ingress-replication, the ingress-PE sends a separate unicast copy to every egress-PE. This 
creates significant excess traffic on links close to the ingress-PE and potentially higher-cost 
ingress-PE attachment speeds.</t>
  <t>In L3VPN aggregates-trees, the traffic for multiple trees is sent across a common tree 
reaching the superset of all egress-PE of all included trees. This reduces the number 
of trees from one per-customer application to a lower number of aggregates this, but it 
creates potentially significant excess traffic towards egress-PE that do not need all 
the aggregated traffic and may even result in a requirement for access core access 
link speeds for those egress routers.</t>
</list></t>

<t>Finally, the per P-router stateless BIER solution solved these issues. It does not require
any per P-router, per tree state creation, and achieves a 256x better traffic efficiency
than ingress replication (with 256 long BIER bit strings).</t>

</section>
<section anchor="network-types" title="Service Provider and Private MPLS Networks">

<t>With DetNet services being targeted primarily for so-called private networks such as (but not
limited to) those for industrial, theme parks, power supply systems, road, river, airport and  train
transportation networks, it is important to understand how concerns for SP networks will
apply to such private networks:</t>

<t>While the aforementioned evolution of MPLS networks focused on large-scale service provider
networks, the very same architectural evolution is or will also happen in any private
MPLS networks in the same way as the DiffServ architecture equally became the only
widely adopted QoS architecture in any larger scale (campus or beyond) private networks.</t>

<t>While some of the scaling, cost, performance and reliability issues mentioned above for
service providers may not equally apply to smaller scale private networks, past experience
has shown that that it is unlikely for a critical mass for different solutions to develop across 
a large variety of vertical private type of networks. For this reason, in the past
any larger scale enterprise networks have preferred to adopt solutions that had proven
themselves through SP deployments and that where based on cross-vendor IETF based architecture principles
and widely, interoperable vendor implementations.</t>

<t>Another reason for private network operators looking for service provider calls designs
is that it also is simplifies potential service provider based management of the network
and/or outsourcing of the network to a service provider. This was seen often when large
enterprises that had to support multi-tenants evolved from ad-hoc network virtualization
solutions (such as VRF-lite) over to BGP/MPLS-VPN designs and later outsourced those very networks.</t>

<t>In that same line of future proofing, networking technologies first developed for enterprises
would also be picked up and reused in Service Provider networks as long as they would fit.
IP Multicast for example had (since about 1996) ca. 10 years of deployment for
business critical enterprise use cases (such as financial market data distribution), before
it was adopted widely for IPTV in service providers.</t>

</section>
<section anchor="shared-infra" title="Mission-specific vs. shared infrastructures">

<t>Whereas the previous section points to the practice and benefits to share technologies
between private and SP network, this section highlights one core additional
requirement of SP networks not found in most private networks from which pre-DetNet
deterministic service requirements will likely originate.</t>

<t>In architectural terms, the desire and need to minimize or avoid per-application/flow
forwarding/control-plane state and per-hop control plane interactions (be it through
on-path signaling or direct PCE to P-router signaling) is not primarily a matter of SP/private
networks or not even of size, but foremost a matter of whether or not the network
itself is seen as the (a) communications fabric of a large distributed application
or (b) as an independently running shared infrastructure across
a potentially wide variety of application/services with diverging requirements.</t>

<t>(a) is the dominant view of the network specifically from many (single) mission specific networks
such as many industrial networks and even non-public High Performance Compute (HPC) center architectures. 
In either of these case, it is a single architectural entity that can control both network infrastructure
and application to build a mission optimized compound.</t>

<t>For example, switches in HPC Data Centers had traditionally very shallow interface packet
buffering for cost reasons, resulting in inferior performance under peak load with predominant
older TCP congestion control stacks. Instead of using better, more expensive switches, it
was easier to improve application device TCP stacks, leading for example to BBR TCP. While
this is very much in line with the desired Internet architecure that is putting a 
significant responsibility onto transport layer protocols in hosts (not limited to TCP)
to behave “fair” or “ideal”, the reality even in many private missions centric networks
such as manufacturing plant is different. Dealing with misbehaving user devics or
applications is one of the main challenge. In the example, that is the case when a DC
is offering public cloud services, where TCP stacks can not be controlled, and hence
deeper buffers and/or better AQM are a core requirement.</t>

<t>In general: In networks following the (b) shared infrastructure design principle, any resource
that needs to be shared across different services or even service instances becomes
a potential three party reliability and costing issue between the provider running
the network and the two (or more) parties whose services utilize the common resource.
Minimizing the total amount of complex, failure-prone and hard to quantify in a cost-effective
manner shared resources is thus at the base of any shared infrastructure network design.</t>

<t>This again points to the model, where all network control can happen on the edge, and
due to the absence of per-hop, per-flow state there simply is no shared flow state table
that needs to be managed across multiple different services/subscribers.</t>

</section>
<section anchor="ptp-and-challenges-with-clock-synchronization" title="PTP and challenges with clock synchronization">

<t>Some bounded latency solution require accurate clock synchronization across network
nodes performing the bounded latency algorithm. The most commonly used (family of) protocol(s) for this is 
the Precision Time Protocol (PTP), standardized in IEEE1588 and various
market specific profiles thereof.</t>

<t>PTP can achieve long-term Maximum Time Interval Errors (MTIE) of
as little as 10th of nsec. MTIE is the maximum time difference between the clocks
of two PTP nodes measured over long period of time.</t>

<t>Implementing PTP in devices comes at a range of design requirements. At high degree
of accuracy, PTP requires accordingly accurate local oscillators that includes
hardware such as regulated heating to operate under constant temperature. It includes accurate
distribution of clock across all components of the system, which can be especially
challenging in modular, large-scale devices, and accurate insertion and retrieval
of timestamp field into packet headers.</t>

<t>While PTP is becoming more and more widely available, consistent support of high
accuracy across all target type of switches and routers in wide area networks 
cannot be taken for granted to be a feasible new requirement raised for DetNet
when it did not exist in before. Today, PTP is often found in mobile network
fronthauls, but not their backhauls or any other broadband aggregation, distribution
or core networks. This is because there is, as of today, no strong
business case requirement for PTP at high precision in those networks, whereas
technologies such as eCPRI raise such requirements against mobile fronthauls.
Instead, those other networks most often resort to at best msec accuracy NTP protocol
deployments which is typically sufficient for control-plane and operational event tracing
as its main, accuracy defining use-case.</t>

<t>The larger the network and more multi-vendor varied the deployed equipment is, the 
higher will also be the operational cost of maintaining and controlling the accuracy
of a PTP service. This primarily has been cited in the past as a reason to
not deploy PTP even if hardware was supporting it. This operational challenge
will especially apply when PTP support may be required for only a small
percentage of traffic in a high speed wide area network. The revenue from the
service needs to cover the operational cost incurred by its exclusive components
(hardware, software and operations).</t>

</section>
<section anchor="jitter-in-time-versus-on-time" title="Jitter - in-time versus on-time">

<t>This section discusses how low-jitter bounded latency applications can be highly
beneficial for DetNet applications.</t>

<t>Depending on the bounded latency algorithm, the jitter experienced by packets varies
based on the amount of competing traffic. In algorithms and their resulting
end-to-end service which this memo calls “in-time”, such as GS and <xref target="TSN-ATS"/>, the experienced
latency in the absence of any competing traffic is zero, and in the presence of the
maximum amount of permissible competing traffic, latency is the maximum, guaranteed
bounded latency. In result, the jitter provided by these algorithms is the highest possible.</t>

<t>In algorithms and their resulting end-to-end service which this memo calls “on-time”,
 the experienced latency is completely or most significantly independent of the amount of competing
traffic and the jitter therefore null or minimal. In these algorithms, the network
buffers packets when they are earlier than guaranteed, whereas in-time algorithms 
deliver packets (almost) as fast as possible.</t>

<t>This memo argues that on-time queuing algorithms provide an additional value-add
over in-time algorithms, especially for use in metropolitan or wide-area networks.
Whatever algorithm is used, the receiving application only has a guarantee for
the maximum bounded latency, and the real (shorter) latency of any received packet is no
indication for the latency of the next packet. Instead, the receiver application has
to be prepared for each and any future packet to arrive with the worst possible,
e.g.: the bounded latency.</t>

<t>The majority of applications require  some higher layer function synchronously
to the sender application: Rendering of audio/video and other media information needs
to happen at the same frequency or event intervals at which the media was encoded. When
 these applications receive packets earlier than the time at which they can be processed
(which is equal or close to the bounded latency), these applications buffer media
in a so-called playout buffer and release them only at that target time. Likewise,
remote control loops including industrial Programmable Logic Controller (PLC) loops or
remote controlling of robots or cars is typically based on synchronous operations.
In these applications, early packets are also delayed to then be processed “synchronously”
later.</t>

<t>In all cases, where applications need to buffer (or otherwise remember) received data
when it is too early, in-time queueing latency raises the challenge to application developers
to be able to predict the networks worst possible jitter, and this can be particularly challenging
for embedded, if not constrained receiver devices with minimum memory to buffer/remember.
When these devices are designed against one particular type of network with well-known low jitter,
then they will not necessarily operate correctly in networks with larger jitter. And
in metropolitan and WAN networks, jitter with in-time services can be highly variable
based on its design and the relative location of the communicating nodes in the topology
(see <xref target="reference"></xref> for an example network design).</t>

<t>One example of such issues was encountered when digital TV receivers (Set Top Boxes, STB)
designed for (mostly synchronous) digital cable transmission where evolved to become
IPTV STB, but the playout buffer of &lt; 50 msec was not sufficient to compensate for
a &gt; 50 msec jitter experienced in IP metropolitan networks.</t>

<t>Note that this section does not claim that all applications will benefit from on-time
service, nor that no application would benefit more from in-time service than from
on-time service. Nevertheless, the authors are not aware of instances of <xref target="RFC8578"/>
application for whom in-time service would be more beneficial than on-time service.
Of course, this comparison is only about the benefit to the application and other
factors such as the cost/scale of the service for the network itself have also to be
taken into account.</t>

</section>
</section>
<section anchor="hw-challenges" title="Challenges for high-speed packet forwarding hardware">

<t>The problems of cost and operational feasibility in shared-infrastructure networks specifically
 applies to scaling of hardware resources such as per-application-flow
forwarding or QoS state in high-speed network routers: Even if the business case makes it
clear that only e.g. 1 Gbps worth of traffic may require this advanced state (such as
multicast replication or per-flow shaping for bounded latency), it will be
more expensive to build this functionality into a 100 Gbps transit switch/router than into a 1 Gbps
switch/router. This too is based on experience from migrating services of low-speed
mission specific networks, such as IP multicast onto high speed, shared-infrastructure 
service provider networks.</t>

<t>The reason for this higher cost at higher speed is that the 1 Gbps worth of “advanced” traffic still has
to be built into 100 times faster hardware and each of the “advanced” packets forwarded would
needs to be replicated/shaped 100 times faster.</t>

<t>This packet processing issue may look like it applies equally to both per-hop, per-flow stateful
 based forwarding as well as solely in-packet based mechanisms, in practice,
per-flow state may requires a lot more high-speed memory access because of the need to access
an entry from a state table. In most cases, this table space can only be made to work
at line rate packet processing when it is on-chip, hence it is not only most expensive, it is
also crucial to scale right. And as the 1 vs. 100 Gbps example above showed, it is very hard to
come by an appropriate scale smaller than “would work for 100% of traffic” - because 
network operator providing shared infrastructure networks really do not want to be responsible for
predicting how individual services may grow in adoption by making a specific hardware selection
that constrains any such grows.</t>

<t>Last, but not least, on-chip high-speed state tables become even more expensive when they
do not only have to be read only, but also when they have to be written at line rate and
even worse, when they have to operate for line-rate speed read/write/read control loops:</t>

<t>The main issue with scaling state in hardware routers is that designs will be hesitant
to work against unclear growth predictions. Even if at some point in time only 1 Gbps
of DetNet traffic was expected to be required on a 100 Gbps platform,
hardware designers will be much more likely want to scale against the worst (best) case
service growth expectation so that customers will not feel that they would buy into a 
product that becomes obsolete under success.</t>

<t>Whereas steering state, such as MPLS label entries can easily scale to hundreds of
thousands, the same is not clear about shapers or interleaved regulators. They are more
challenging because they require fast (on-chip) read-write memory for the state
variables, especially when forwarding is parallelized across multiple execution unit.
This does incur additional complexity to split up the state and its packets across
multiple execution units and/or to provide consistent cross-execution units shared read/writeable memory.</t>

<t>Even only writeable (but not cross-execution units then also readable) memory has
traditionally been a sparse resource the faster the forwarding engines are. This
can be seen from (often very limited) scale of packet monitoring state such as for IPfix.</t>

<t>But the main issue of per-hop, per-flow forwarding state that could be quite dynamic
because it might be triggered by applications is the control plane to forwarding-plane-state
interactions. Updating hardware forwarding engine state tables is often one
of the key performance limits of routers. Adding significant additional state with likely
ongoing changes is easily seen as a big contributor to churn in the control plane
and likely reason for stability and reduced peak performance under key events such as
reconvergence of all or large parts of IGP or BGP routing tables.</t>

</section>
<section anchor="reference" title="A reference network design">

<t>The following picture shows an example, worst-case network
topology of interest (in the opinion of the authors) for bounded
latency considerations. This section does not claim that greenfield
rollouts may or want to use all aspects of this topology. What
his memo does claim is that many existing brownfield networks, especially
large metropolitan areas show all or many of these
aspects, and that it would be prudent for bounded latency network
technologies to support networks like these so as to not create
new constraints against network designers by only supporting
physical network topologies optimized for a particular type of
service (bounded latency).</t>

<figure title="Reference Network Topology" anchor="FIG-network"><artwork><![CDATA[
         Subscribers, Towers, IoT devices
                    .............
                    ...Access....    National-Core
                  PE100 ... PE199    Exchanges/
                  | |                Peerings
                  | \----\           /   \
                  |       \         /     \
             ---  P11 --- P12 --- P13 --- P14 --
            /                                   \
Edge  -----P21                                   P15
DC  PE     |                                     |
     ------P21                                   P17
            \                                   /
             ---  P20 --- .........   --- P18 --
                  /                         \
     Edge   --- P30                      P40          
     DC    PE     \                        /
             ----- P31 -- ....  P38 --- P39
                                  \     /
                                   \   /
                                   PE200...PE299
                                   ...Access....
                                   .............
                        Subscribers, Towers, IoT devices
]]></artwork></figure>

<t>An example metropolitan scale network as shown in <xref target="FIG-network"/> may consist of one or more
rings of forwarders. A ring provides the minimum cost n+1 redundancy
between the ring nodes, especially when, as is common in metropolitan networks,
new fibre cannot cost-effectively be put into new optimum trenches,
but existing fibre and/or trenches have to be used. This is specifically
true when the area includes not dense populated suburban areas (higher
cost per subscriber and mile for rollouts).</t>

<t>Multiple, so-called subtended rings typically occur when existing
networks are expanded into new areas: A new ring is simply connected
at two most economic points into the existing infrastructure. Likewise,
such a topology may become more complicated over time by addition
of capacity, which resulting from TE planning calculations may not
follow any of the pre-existing ring paths.</t>

<t>Edge Data-Center (DC), connections to Exchanges/Peerings or national
cores of the provider itself, as well as all subscribers including
Mobile Network Towers, and IoT devices connect to these ring directly 
via PE edge-forwarders and (more often) via additional CE type devices.
P nodes may also double as PE nodes.</t>

<t>In densely populated regions, P, or PE nodes may have a high number
of attached devices, shown in the picture with the example of 100
PE forwarder connecting to a single P forwarder (or rather two
P for redundancy and therefore support of PREOF).</t>

<t>In summary, the following aspects of these networks are relevant
for bounded latency:</t>

<t><list style="symbols">
  <t>Link speeds today are at least 100 Gbps and will be Tbps in the
near future. Even if only a small percentage of that traffic has to
support bounded latency, the queuing mechanism need to support these
high-speed interfaces.</t>
  <t>Fan-in/out at PE or P nodes may be (worst case) in the order of
hundred(s) of incoming interfaces. Bounded latency mechanisms whose
number of queues depend on the number (#I) of interfaces in a more
than linear fashion, such as (#I^2) in the case of <xref target="TSN-ATS"/>, may
introduce significant challenges for cost-effective hardware.</t>
  <t>Through the advent of decentralized edge Data Center and peerings between
different operators and content providers, traffic flows of interest
will not solely be between one central site from/to subscribers hub&amp;spoke.
Instead arbitrary, traffic engineered paths across the topology
between any two edges need to be supportable in scale with the 
bounded latency queuing mechanism.</t>
  <t>The total number of edge (#E) nodes (PE or CE) for a bounded latency service
can easily be in the thousands. Aggregation of bounded latency flows
on the order of (#E^2), which is the best option in per-hop, per-flow
solutions such as <xref target="TSN-ATS"/>, is likely insufficient to significantly reduce
the number of flows that need to be managed across P nodes in such
bounded latency queuing mechanisms.</t>
  <t>The total number of P nodes may be in the hundreds and bounded latency
flows in the tenths of thousands. It should also be expected that such
flows are not necessarily long-term static but may need to be provisionable
in the time-scale order of for example telephone calls (such as flows supporting<vspace />
remote control of devices or operations). Bounded latency solutions that
require per-flow, per-node state maintenance on the P nodes themselves
may therefore be undesirable from a network operational/complexity/reliability 
perspective, but also from a hardware engineering cost perspective, especially
with respect to the control plane cost of dynamically setting up per-flow
bounded latency for flow whenever there is a new flow or all of them whenever
there are topology or load changes that make rerouting desirable.</t>
</list></t>

<t>Beyond queuing concerns, path selection too specifically for deterministic
services is a challenge in these networks:</t>

<t><list style="symbols">
  <t>Path lengths may be significantly longer than e.g. 3 hops.
In large metropolitan networks, they can reach 20 or more hops.
Speed of light end-to-end in these networks will be in the order of
low number of msec. End-to-end queuing latency can be in the same range,
if not higher.</t>
  <t>To avoid undesirable re-routing under failure when PREOF and
engineered disjoint paths are used, traffic steering needs to
support efficiently supportable hop-by-hop traffic steering. In networks
designed for source-routing (e..: SR routing), efficiently encoded
strict-hop-by-hop steering for as much as those (e.g.: 20) hops may
be desirable to support.</t>
</list></t>

</section>
<section anchor="standardized-bounded-latency-algorithms" title="Standardized Bounded Latency algorithms">

<t><xref target="DNBL"/> gives an overview of the math for the most well-known
existing deterministic bounded latency algorithms/solutions. This section reviews the relevant
currently standardized algorithms from the perspective of the above listed problems for high-speed,
high-scale, shared services infrastructures and to provide additional background about them.</t>

<section anchor="guaranteed-service-gs" title="Guaranteed Service (GS)">

<t>GS is described in section 6.5 of <xref target="DNBL"/>. <xref target="GS"></xref> describes its historical evolution and challenges.
We skip further detailing of its issues here to concentrate on IEEE Time Synchronuous Networking - Asynchronous Traffic Shaping <xref target="TSN-ATS"/>,
which in general is seen as superior to GS for high speed hardware implementation. All the
concerns described in the TSN-ATS section apply equally or even  more to GS.</t>

</section>
<section anchor="tsn-asynchronous-traffic-shaping-tsn-ats" title="TSN Asynchronous Traffic Shaping (TSN-ATS)">

<t>Section 6.4 of <xref target="DNBL"/> describes the bounded latency used for TSN Asynchronous
Traffic Shaping <xref target="TSN-ATS"/>. Like GS, this bounded latency solution also relies on per-flow
shaper state, except that it uses optimized shapers called “Interleaved Regulator” as explained
in section 4.2.1 of <xref target="DNBL"/>.</t>

<t>The concept and simplification in interleaved regulators
over traditional shapers and the concept of interleaved regulators is a resulting from 
mathematical work done in the last 10 years starting with <xref target="UBS"/>.</t>

<t>In a system with e.g. N=10,000 flows each with a shaper, the forwarder needs to have 
10,000 shapers each of which would need to calculate the earliest feasible send-time
of the first queued packet of the flow and all these send-times would need to be compared
by a scheduler picking the absolute first packet to send. Of course it is unlikely that
the router would have to queue at least one packet for all queues at any point in time,
but the complexity to implement the scheduler scales with N.</t>

<t>With interleaved regulators,
there is still the per-flow state required to hold each flows traffic parameters and
its next-packet earliest departure time, but instead of requiring a scheduler to compare
N entries, packets are queued into one out of (#IIF,#PRIO) FIFO queues, one queue for all the
packets arriving from the same Incoming InterFace (IIF) and targeted the same
worst-case queuing latency/PRIOrity (PRIO) on this hop. The shaper now only needs to calculate the earliest
departure time of the head of each of these M= #IIF * #PRIO queues and the complexity of
a scheduler to select the first packet across those interleave regulators is therefore
reduced by a factor of O(N/M).</t>

<t>Unfortunately, while industrial ethernet switches today often have no more than 24 IIF, aggregation
routers in metropolitan networks may have thousands of IIF, so the benefit of interleaved
regulators over per-flow shaper will likely be much higher in classical TSN environments than it
would be for example likely DetNet target routers in metropolitan networks.</t>

<t>In addition, the aforementioned core problems for shapers (<xref target="hw-challenges"></xref>), namely control
plane, read/write/read cycle access and scale equally apply to interleaved regulators, so
the main optimization benefits of interleaved regulators is for the original targets of <xref target="UBS"/> / <xref target="TSN-ATS"/>:
low-speed (1..10Gbps switches) with limited number of interfaces - but to a much lower degree
for likely important type of DetNet deployments.</t>

</section>
<section anchor="CQF-section" title="Cyclic Queuing and Forwarding (CQF)">

<t>TSN Cyclic Queuing and Forwarding as described in <xref target="DNBL"/>, section 6.6, is a per-flow, per-transit-hop
stateless forwarding mechanism, which solves the concerns with per-hop, per-flow state issues
described earlier in this memo. It also provides an on-time service in which the per-hop and
end-to-end jitter is very small, namely in the order of a cycle time.</t>

<t><xref target="CQF"/> operates by forwarders sending packets in periodic cycles.
These cycles are derived from clock synchronization: The start of each cycle (and by implication
the end of the prior cycle) are simply periodically increasing clock timestamps that have to be
synchronized across adjacent forwarders, usually via PTP. This method to operate cycles
allows <xref target="CQF"/> to operate without additional <xref target="CQF"/> data packet headers, but it is also the reason for the
two issues of <xref target="CQF"/>, and both relate to the so-called dead time (DT).</t>

<t>For the receiving node to correctly associate a <xref target="CQF"/> packet to the same cycle as the sending
node, the last bit of the last packet in the cycle on the sending node needs to be received by the
receiving node before the cycle ends.</t>

<t><xref target="DNBL"/> explains that DT is the sum of latencies 1,2,3,4
as of <xref target="DNBL"/> Figure 1, but that is missing the MTIE between the forwarders: 
If a cycle is for example 10 usec, and the PTP MTIE is 1 usec, then only 9 usec of
the cycle could be used (without even yet considering the other factors contributing to MTIE).
If MTIE is not taken into account, a packet might arrive in time from the perspective of the
sending forwarder, but not in the perspective of the 1 usec earlier receiving node.</t>

<t>In practice, MTIE should be equal or lower than 1% of the cycle time. When forwarders and links 
increase in speed, cycle times could become proportionally smaller to reduce per-hop cycle time latency.
When this is done, MTIE needs to equally become smaller, raising the costs of the solution. Therefore,
<xref target="CQF"/> has a challenge with higher speed networks.</t>

<t>The second and even more important problem is that DT includes the link latency (2 in
<xref target="DNBL"/>, Figure 1). With a speed of light in fibre of 200,000 Km, link latency is 10 usec
for 2 Km. This makes <xref target="CQF"/> very problematic and limited in metropolitan and wide-area
networks. If the longest link of a network was 10 Km, this would cause a DT on that link
of 50 usec and with a cycle time of 100 usec, only 50% bandwidth could be used for cycle-time
(bounded latency) traffic (excluding all other DT factors).</t>

<t>When links are subject to thermal expansion also known as sag on hanging wires, such as broadband
copper wires (Cable Networks), their length can also change by as much as 20% between noon and night temperatures,
which without changes in the design has to be taken into account as part of DT.</t>

<t>In conclusion, <xref target="CQF"/> solves many of the problems discussed in this memo, but it’s reliance on
timestamp synchronized cycles may pose undesirable challenges with the required accuracy of
 PTP in high speed network and especially limits <xref target="CQF"/> ability to support wider-scale networks due to DT.</t>

</section>
</section>
<section anchor="candidate-solution-directions" title="Candidate solution directions">

<t>As this memo outlines, per-hop, per-flow stateless forwarding is the one
core requirement for to support Gbps speed metropolitan or wide-area networks.</t>

<t>This section gives an overview and evaluation from the perspective of the authors of
this memo of currently known non-standardized proposals for per-hop-stateless forwarding
with the explicit goal and/or possibility of bounded latency forwarding and in relationship. 
to the concerns and desires described in the previous sections.</t>

<section anchor="packet-tagging-based-cqf" title="Packet tagging based CQF">

<t>To overcome the challenges outlined in <xref target="CQF-section"></xref>, <xref target="I-D.qiang-DetNet-large-scale-DetNet"/> and
 <xref target="I-D.dang-queuing-with-multiple-cyclic-buffers"/> (tagged-CQF) propose a modified <xref target="CQF"/> mechanism
in which timestamp based cycle indication of <xref target="CQF"/> is replaced by indicating the senders cycle in
an appropriate packet header field, so that the receiver can accordingly map the received
packet to the right local cycle.</t>

<t>This approach completely eliminates the link-latency as a factor
impacting the effectiveness of the mechanism, because in this approach, the link latency
does not impact the DT. Instead the link latency is used to calculate which cycle from the
sender needs to be mapped to which cycle on the receiver, and this is programmd during
setup of links into the receiving routers cycle mapping table.</t>

<t>Depending on the number of cycles configured, it is also possible to compensate for
variability in the link-latency and higher MTIE (picture TBD). If one more cycle is used
for example, this would allow for MTIE to be the order of one cycle time as opposed to
a likely target of 1% of cycle time as in <xref target="CQF"/>, reducing the required PTP clock accuracy by
a factor of 100. This possible reduction in required accuracy of operations by appropriate
configuration does not only cover PTP but also extends into any forwarding operation within
the nodes, e.g.: it could also reduce the cost of implementation of forwarding hardware
at higher speeds accordingly.</t>

<t>In MPLS networks, packet tagged CQF with a small number of cycle tags (such as 3 or 4)
could easily be realized and standardized by relying on E-LSP where 3 or 4 EXP code
points would be used to indicate the cycle value. Given how such deterministic bounded
latency traffic is not subject to congestion control, it also does not require additional
ECN EXP code points, so those would be available for e.g.: best-effort traffic that
should use the same E-LSP.</t>

</section>
<section anchor="packet-tagging-based-cqf-with-sr" title="Packet tagging based CQF with SR">

<t><xref target="I-D.chen-DetNet-sr-based-bounded-latency"/> applies the taged-CQF mechanisms to Segment Routing (SR)
by proposing SR style header elements to indicate the per-segment/hop cycle. This eliminates the
need to set up on every hop a cycle mapping table.</t>

<t>It is unclear to the authors of this memo
how big a saving this is given how the PCE would need to update all the ingress router per-flow
configurations where header imposition happens when links change, whereas the mapping table approach
would require only localized changes on the affected routers.</t>

</section>
<section anchor="srtsn" title="Per-hop latency indications for Segment Routing">

<t><xref target="I-D.stein-srtsn"/> describes a mechanism in which a source-routed header in the spirit of a Segment Routing (SR)
header can be used to enable a per-transit-hop per-flow stateless latency control. For every hop,
a maximum latency is specified. The draft outlines a control plane which similarly to packet
tagging based CQF or <xref target="TSN-ATS"/> would put the work of admitting flows, determining their paths and admitting
their resources along those paths to some form of PCE/SDN-Controller.</t>

<t>The basic principle of forwarding in this proposal is to put received packets into
a priority heap and schedule them in order of their urgency (shortest latency) for this hop.</t>

<t>The draft explicitly does not prescribes specific algorithms on the forwarders to
take the indicated latency for the hop into account in a way that the controller can
calculate the resource availability, such as specific queuing or scheduling
algorithms.</t>

<t>It is not entirely clear to the authors of this memo, if the sole indication of
such deadline latencies is sufficient to completely eliminate per-transit-hop, per-flow
state and still achieve deterministic latency because of the <xref target="UBS"/> work.
Consider that the packets latency for a hop could be used to derive a priority
queue on the hop relative to other packets with higher or lower latency for this hop,</t>

<t>As was shown in the research work leading up to <xref target="TSN-ATS"/>, the priority queuing on
each hop alone is not sufficient to achieve a simple, solely per-hop calculated
latency bound under high load because of the problem of multi-hop burst aggregation and the
resulting hard to calculate incurred upper latency bound. To overcome that calculation
issue,  shapers or as in <xref target="TSN-ATS"/> their optimization, interleaved regulators, are 
used in <xref target="TSN-ATS"/> and GS.  Shapers/interleaved requires to maintain across packets
from the same flow  per-flow state.</t>

<t>Nevertheless, appropriate mathematical models for SDN controllers may be possible to develop
deterministic per-hop forwarding models relying not only on the per-hop indicated latency but
also on additional constraints such as limited number of hops or sufficiently low degrees of maximum
admitted amount of traffic. Or else this may be used for to be developed latency models that
are not 100% deterministic, but close enough in probability such that the amount of late
packets would be in the same order as otherwise unavoidable problems such as BER based packet loss.</t>

<t>To that end, the author of <xref target="I-D.stein-srtsn"/> has conducted simulations of the
proposed mechanism, contrasting it with other mechanisms. These results, which will be
published elsewhere, show hat this mechanism excels in cases with high load and a
small number of flows with tight budgets.  However, some small percentage of packets
will miss their end-to-end latency bounds, and must be treated as lost packets.</t>

<t>Depending on the algorithms chosen, solutions may or may not rely on strong, weak, or no
clock synchronization across nodes.</t>

</section>
<section anchor="lbf" title="Latency Based Forwarding">

<t>“High-Precision Latency Forwarding over Packet-Programmable Networks”, NOMS 2020 conference <xref target="LBF"/>
describes a framework for per-transit-hop, per-flow stateless forwarding based on
three packet parameters: The minimum and maximum desired end-to-end latency, set by
the sender and not changed by the network, and the experienced latency updated by
every hop. Routers supporting this LBF mechanism do also extend their routing (e.g.: IGP)
to be able to calculate the non-queueing latency towards the destination. Based on
the in-packet parameters and the future latency prediction are used to prioritize packets
in queuing including giving them higher priority when they are late due to prior hop incurred
latency, or delaying them when they are too early.</t>

<t>LBF was started as a more fundamental research into how application experience could
be improved when they are allowed to indicate such differential min/max latency Service Level
Objectives (SLO). Benefits include the ability to compensate for prior hop incurred
queuing latency, but also to automatically prioritize packets on a single hop based on their
future path length, all without the need for any explicit admission control.</t>

<t>The LBF algorithm is completely without need for clock synchronization across nodes. Instead,
it assumes mechanisms to know or learn link latency and the remaining latencies (as defined in
the DetNet architecture) can be calculated locally (e.g.: latency through a forwarder).</t>

<t>The authors have not yet tried to define a mathematical model that would
allow to derive completely deterministic behavior for this original LBF algorithm in conjunction with a
PCE/SDN controller. Due to the absence of per-flow (shaper/interleaved-regulator),
the authors believe that deterministic solutions would as outlined above for SRTSN (<xref target="srtsn"></xref>) likely only
be possible under additional assumed constraints.</t>

</section>
</section>
<section anchor="conclusions" title="Conclusions">

<t>Bounded Latency for DetNet have been designed by trying to adopt solutions developed either
several decades ago (GS) or recently for limited scope and scale L2 networks <xref target="TSN-ATS"/>.</t>

<t>To allow DetNet solutions to explore opportunities in larger speed &amp; scale shared network
infrastructures, both private and service provider networks, it is highly desirable for
DetNet WG (and/or other IETF WGs claiming responsibility in conjunction with DetNet as the driver)
to explore the opportunities to standardize additional, and in the
opinion of the authors better per-hop forwarding models in support of (near) deterministic bounded
latency by mean of standardizing per-flow stateless/”DiffServ” style per-hop forwarding behavior (PHB) with
appropriate network packet header parameters.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document has no security considerations (yet?).</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no IANA considerations.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks for Yaakov Stein for reviewing and proposing text for <xref target="srtsn"></xref>.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference anchor='RFC2205' target='https://www.rfc-editor.org/info/rfc2205'>
<front>
<title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification</title>
<author fullname='R. Braden' initials='R.' role='editor' surname='Braden'><organization/></author>
<author fullname='L. Zhang' initials='L.' surname='Zhang'><organization/></author>
<author fullname='S. Berson' initials='S.' surname='Berson'><organization/></author>
<author fullname='S. Herzog' initials='S.' surname='Herzog'><organization/></author>
<author fullname='S. Jamin' initials='S.' surname='Jamin'><organization/></author>
<date month='September' year='1997'/>
<abstract><t>This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet.  RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2205'/>
<seriesInfo name='DOI' value='10.17487/RFC2205'/>
</reference>



<reference anchor='RFC2210' target='https://www.rfc-editor.org/info/rfc2210'>
<front>
<title>The Use of RSVP with IETF Integrated Services</title>
<author fullname='J. Wroclawski' initials='J.' surname='Wroclawski'><organization/></author>
<date month='September' year='1997'/>
<abstract><t>This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2210'/>
<seriesInfo name='DOI' value='10.17487/RFC2210'/>
</reference>



<reference anchor='RFC2211' target='https://www.rfc-editor.org/info/rfc2211'>
<front>
<title>Specification of the Controlled-Load Network Element Service</title>
<author fullname='J. Wroclawski' initials='J.' surname='Wroclawski'><organization/></author>
<date month='September' year='1997'/>
<abstract><t>This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2211'/>
<seriesInfo name='DOI' value='10.17487/RFC2211'/>
</reference>



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



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



<reference anchor='RFC3031' target='https://www.rfc-editor.org/info/rfc3031'>
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author fullname='E. Rosen' initials='E.' surname='Rosen'><organization/></author>
<author fullname='A. Viswanathan' initials='A.' surname='Viswanathan'><organization/></author>
<author fullname='R. Callon' initials='R.' surname='Callon'><organization/></author>
<date month='January' year='2001'/>
<abstract><t>This document specifies the architecture for Multiprotocol Label Switching (MPLS).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3031'/>
<seriesInfo name='DOI' value='10.17487/RFC3031'/>
</reference>



<reference anchor='RFC3209' target='https://www.rfc-editor.org/info/rfc3209'>
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author fullname='D. Awduche' initials='D.' surname='Awduche'><organization/></author>
<author fullname='L. Berger' initials='L.' surname='Berger'><organization/></author>
<author fullname='D. Gan' initials='D.' surname='Gan'><organization/></author>
<author fullname='T. Li' initials='T.' surname='Li'><organization/></author>
<author fullname='V. Srinivasan' initials='V.' surname='Srinivasan'><organization/></author>
<author fullname='G. Swallow' initials='G.' surname='Swallow'><organization/></author>
<date month='December' year='2001'/>
<abstract><t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3209'/>
<seriesInfo name='DOI' value='10.17487/RFC3209'/>
</reference>



<reference anchor='RFC6513' target='https://www.rfc-editor.org/info/rfc6513'>
<front>
<title>Multicast in MPLS/BGP IP VPNs</title>
<author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'><organization/></author>
<author fullname='R. Aggarwal' initials='R.' role='editor' surname='Aggarwal'><organization/></author>
<date month='February' year='2012'/>
<abstract><t>In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider.  These protocols and procedures are specified in this document.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6513'/>
<seriesInfo name='DOI' value='10.17487/RFC6513'/>
</reference>



<reference anchor='RFC8279' target='https://www.rfc-editor.org/info/rfc8279'>
<front>
<title>Multicast Using Bit Index Explicit Replication (BIER)</title>
<author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'><organization/></author>
<author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'><organization/></author>
<author fullname='A. Dolganow' initials='A.' surname='Dolganow'><organization/></author>
<author fullname='T. Przygienda' initials='T.' surname='Przygienda'><organization/></author>
<author fullname='S. Aldrin' initials='S.' surname='Aldrin'><organization/></author>
<date month='November' year='2017'/>
<abstract><t>This document specifies a new architecture for the forwarding of multicast data packets.  It provides optimal forwarding of multicast packets through a &quot;multicast domain&quot;.  However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as &quot;Bit Index Explicit Replication&quot; (BIER).  When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent.  The ingress router then encapsulates the packet in a BIER header.  The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header.  The procedures for forwarding a packet based on its BIER header are specified in this document.  Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</t></abstract>
</front>
<seriesInfo name='RFC' value='8279'/>
<seriesInfo name='DOI' value='10.17487/RFC8279'/>
</reference>



<reference anchor='RFC8296' target='https://www.rfc-editor.org/info/rfc8296'>
<front>
<title>Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks</title>
<author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'><organization/></author>
<author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'><organization/></author>
<author fullname='A. Dolganow' initials='A.' surname='Dolganow'><organization/></author>
<author fullname='J. Tantsura' initials='J.' surname='Tantsura'><organization/></author>
<author fullname='S. Aldrin' initials='S.' surname='Aldrin'><organization/></author>
<author fullname='I. Meilik' initials='I.' surname='Meilik'><organization/></author>
<date month='January' year='2018'/>
<abstract><t>Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a &quot;multicast domain&quot;, without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol.  When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent.  The ingress router then encapsulates the packet in a BIER header.  The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header.  The details of the encapsulation depend on the type of network used to realize the multicast domain.  This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.</t></abstract>
</front>
<seriesInfo name='RFC' value='8296'/>
<seriesInfo name='DOI' value='10.17487/RFC8296'/>
</reference>



<reference anchor='RFC8402' target='https://www.rfc-editor.org/info/rfc8402'>
<front>
<title>Segment Routing Architecture</title>
<author fullname='C. Filsfils' initials='C.' role='editor' surname='Filsfils'><organization/></author>
<author fullname='S. Previdi' initials='S.' role='editor' surname='Previdi'><organization/></author>
<author fullname='L. Ginsberg' initials='L.' surname='Ginsberg'><organization/></author>
<author fullname='B. Decraene' initials='B.' surname='Decraene'><organization/></author>
<author fullname='S. Litkowski' initials='S.' surname='Litkowski'><organization/></author>
<author fullname='R. Shakir' initials='R.' surname='Shakir'><organization/></author>
<date month='July' year='2018'/>
<abstract><t>Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called &quot;segments&quot;.  A segment can represent any instruction, topological or service based.  A segment can have a semantic local to an SR node or global within an SR domain.  SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t><t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane.  A segment is encoded as an MPLS label.  An ordered list of segments is encoded as a stack of labels.  The segment to process is on the top of the stack.  Upon completion of a segment, the related label is popped from the stack.</t><t>SR can be applied to the IPv6 architecture, with a new type of routing header.  A segment is encoded as an IPv6 address.  An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header.  The active segment is indicated by the Destination Address (DA) of the packet.  The next active segment is indicated by a pointer in the new routing header.</t></abstract>
</front>
<seriesInfo name='RFC' value='8402'/>
<seriesInfo name='DOI' value='10.17487/RFC8402'/>
</reference>



<reference anchor='RFC8570' target='https://www.rfc-editor.org/info/rfc8570'>
<front>
<title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
<author fullname='L. Ginsberg' initials='L.' role='editor' surname='Ginsberg'><organization/></author>
<author fullname='S. Previdi' initials='S.' role='editor' surname='Previdi'><organization/></author>
<author fullname='S. Giacalone' initials='S.' surname='Giacalone'><organization/></author>
<author fullname='D. Ward' initials='D.' surname='Ward'><organization/></author>
<author fullname='J. Drake' initials='J.' surname='Drake'><organization/></author>
<author fullname='Q. Wu' initials='Q.' surname='Wu'><organization/></author>
<date month='March' year='2019'/>
<abstract><t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t><t>This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305).  These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t><t>Note that this document only covers the mechanisms with which network-performance information is distributed.  The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t><t>This document obsoletes RFC 7810.</t></abstract>
</front>
<seriesInfo name='RFC' value='8570'/>
<seriesInfo name='DOI' value='10.17487/RFC8570'/>
</reference>



<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 &quot;deterministic flows&quot;.  &quot;Deterministic&quot; 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='RFC8660' target='https://www.rfc-editor.org/info/rfc8660'>
<front>
<title>Segment Routing with the MPLS Data Plane</title>
<author fullname='A. Bashandy' initials='A.' role='editor' surname='Bashandy'><organization/></author>
<author fullname='C. Filsfils' initials='C.' role='editor' surname='Filsfils'><organization/></author>
<author fullname='S. Previdi' initials='S.' surname='Previdi'><organization/></author>
<author fullname='B. Decraene' initials='B.' surname='Decraene'><organization/></author>
<author fullname='S. Litkowski' initials='S.' surname='Litkowski'><organization/></author>
<author fullname='R. Shakir' initials='R.' surname='Shakir'><organization/></author>
<date month='December' year='2019'/>
<abstract><t>Segment Routing (SR) leverages the source-routing paradigm.  A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header.  In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).</t></abstract>
</front>
<seriesInfo name='RFC' value='8660'/>
<seriesInfo name='DOI' value='10.17487/RFC8660'/>
</reference>



<reference anchor='RFC8964' target='https://www.rfc-editor.org/info/rfc8964'>
<front>
<title>Deterministic Networking (DetNet) Data Plane: MPLS</title>
<author fullname='B. Varga' initials='B.' role='editor' surname='Varga'><organization/></author>
<author fullname='J. Farkas' initials='J.' surname='Farkas'><organization/></author>
<author fullname='L. Berger' initials='L.' surname='Berger'><organization/></author>
<author fullname='A. Malis' initials='A.' surname='Malis'><organization/></author>
<author fullname='S. Bryant' initials='S.' surname='Bryant'><organization/></author>
<author fullname='J. Korhonen' initials='J.' surname='Korhonen'><organization/></author>
<date month='January' year='2021'/>
<abstract><t>This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network.  It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms.  This document builds on the DetNet architecture and data plane framework.</t></abstract>
</front>
<seriesInfo name='RFC' value='8964'/>
<seriesInfo name='DOI' value='10.17487/RFC8964'/>
</reference>



<reference anchor='RFC8986' target='https://www.rfc-editor.org/info/rfc8986'>
<front>
<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
<author fullname='C. Filsfils' initials='C.' role='editor' surname='Filsfils'><organization/></author>
<author fullname='P. Camarillo' initials='P.' role='editor' surname='Camarillo'><organization/></author>
<author fullname='J. Leddy' initials='J.' surname='Leddy'><organization/></author>
<author fullname='D. Voyer' initials='D.' surname='Voyer'><organization/></author>
<author fullname='S. Matsushima' initials='S.' surname='Matsushima'><organization/></author>
<author fullname='Z. Li' initials='Z.' surname='Li'><organization/></author>
<date month='February' year='2021'/>
<abstract><t>The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t><t>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t><t>This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t></abstract>
</front>
<seriesInfo name='RFC' value='8986'/>
<seriesInfo name='DOI' value='10.17487/RFC8986'/>
</reference>


<reference anchor='I-D.ietf-bier-te-arch'>
   <front>
      <title>Tree Engineering for Bit Index Explicit Replication (BIER-TE)</title>
      <author fullname='Toerless Eckert'>
	 <organization>Futurewei Technologies Inc.</organization>
      </author>
      <author fullname='Gregory Cauchie'>
	 <organization>Bouygues Telecom</organization>
      </author>
      <author fullname='Michael Menth'>
	 <organization>University of Tuebingen</organization>
      </author>
      <date day='9' month='July' year='2021'/>
      <abstract>
	 <t>   This memo describes per-packet stateless strict and loose path
   steered replication and forwarding for Bit Index Explicit Replication
   packets (RFC8279).  It is called BIER Tree Engineering (BIER-TE) and
   is intended to be used as the path steering mechanism for Traffic
   Engineering with BIER.

   BIER-TE introduces a new semantic for bit positions (BP) that
   indicate adjacencies, as opposed to BIER in which BPs indicate Bit-
   Forwarding Egress Routers (BFER).  BIER-TE can leverage BIER
   forwarding engines with little changes.  Co-existence of BIER and
   BIER-TE forwarding in the same domain is possible, for example by
   using separate BIER sub-domains (SDs).  Except for the optional
   routed adjacencies, BIER-TE does not require a BIER routing underlay,
   and can therefore operate without depending on an Interior Gateway
   Routing protocol (IGP).

   As it operates on the same per-packet stateless forwarding
   principles, BIER-TE can also be a good fit to support multicast path
   steering in Segment Routing (SR) networks.

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


<reference anchor='DNBL'>
   <front>
      <title>DetNet Bounded Latency</title>
      <author fullname='Norman Finn'>
	 <organization>Huawei Technologies Co. Ltd</organization>
      </author>
      <author fullname='Jean-Yves Le Boudec'>
	 <organization>EPFL</organization>
      </author>
      <author fullname='Ehsan Mohammadpour'>
	 <organization>EPFL</organization>
      </author>
      <author fullname='Jiayi Zhang'>
	 <organization>Huawei Technologies Co. Ltd</organization>
      </author>
      <author fullname='Balázs Varga'>
	 <organization>Ericsson</organization>
      </author>
      <author fullname='János Farkas'>
	 <organization>Ericsson</organization>
      </author>
      <date day='17' month='May' year='2021'/>
      <abstract>
	 <t>   This document references specific queuing mechanisms, defined in
   other documents, that can be used to control packet transmission at
   each output port and achieve the DetNet qualities of service.  This
   document presents a timing model for sources, destinations, and the
   DetNet transit nodes that relay packets that is applicable to all of
   those referenced queuing mechanisms.  Using the model presented in
   this document, it should be possible for an implementor, user, or
   standards development organization to select a particular set of
   queuing mechanisms for each device in a DetNet network, and to select
   a resource reservation algorithm for that network, so that those
   elements can work together to provide the DetNet service.

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


<reference anchor='I-D.stein-srtsn'>
   <front>
      <title>Segment Routed Time Sensitive Networking</title>
      <author fullname='Yaakov (J) Stein'>
	 <organization>RAD</organization>
      </author>
      <date day='22' month='February' year='2021'/>
      <abstract>
	 <t>   Routers perform two distinct user-plane functionalities, namely
   forwarding (where the packet should be sent) and scheduling (when the
   packet should be sent).  One forwarding paradigm is segment routing,
   in which forwarding instructions are encoded in the packet in a stack
   data structure, rather than programmed into the routers.  Time
   Sensitive Networking and Deterministic Networking provide several
   mechanisms for scheduling under the assumption that routers are time
   synchronized.  The most effective mechanisms for delay minimization
   involve per-flow resource allocation.

   SRTSN is a unified approach to forwarding and scheduling that uses a
   single stack data structure.  Each stack entry consists of a
   forwarding portion (e.g., IP addresses or suffixes) and a scheduling
   portion (deadline by which the packet must exit the router).  SRTSN
   thus fully implements network programming for time sensitive flows,
   by prescribing to each router both to-where and by-when each packet
   should be sent.

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


<reference anchor='I-D.chen-DetNet-sr-based-bounded-latency'>
   <front>
      <title>Segment Routing (SR) Based Bounded Latency</title>
      <author fullname='Mach(Guoyi) Chen'>
	 <organization>Huawei</organization>
      </author>
      <author fullname='Xuesong Geng'>
	 <organization>Huawei</organization>
      </author>
      <author fullname='Zhenqiang Li'>
	 <organization>China Mobile</organization>
      </author>
      <date day='7' month='May' year='2019'/>
      <abstract>
	 <t>   One of the goals of DetNet is to provide bounded end-to-end latency
   for critical flows.  This document defines how to leverage Segment
   Routing (SR) to implement bounded latency.  Specifically, the SR
   Identifier (SID) is used to specify transmission time (cycles) of a
   packet.  When forwarding devices along the path follow the
   instructions carried in the packet, the bounded latency is achieved.
   This is called Cycle Specified Queuing and Forwarding (CSQF) in this
   document.

   Since SR is a source routing technology, no per-flow state is
   maintained at intermediate and egress nodes, SR-based CSQF naturally
   supports flow aggregation that is deemed to be a key capability to
   allow DetNet to scale to large networks.


	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-chen-DetNet-sr-based-bounded-latency-01'/>
   <format target='https://www.ietf.org/archive/id/draft-chen-DetNet-sr-based-bounded-latency-01.txt' type='TXT'/>
</reference>


<reference anchor='I-D.qiang-DetNet-large-scale-DetNet'>
   <front>
      <title>Large-Scale Deterministic IP Network</title>
      <author fullname='Li Qiang'>
	 <organization>Huawei</organization>
      </author>
      <author fullname='Xuesong Geng'>
	 <organization>Huawei</organization>
      </author>
      <author fullname='Bingyang Liu'>
	 <organization>Huawei</organization>
      </author>
      <author fullname='Toerless Eckert'>
	 <organization>Huawei</organization>
      </author>
      <author fullname='Liang Geng'>
	 <organization>China Mobile</organization>
      </author>
      <author fullname='Guangpeng Li'>
	 </author>
      <date day='2' month='September' year='2019'/>
      <abstract>
	 <t>   This document presents the overall framework and key method for
   Large-scale Deterministic Network (LDN).  LDN can provide bounded
   latency and delay variation (jitter) without requiring precise time
   synchronization among nodes, or per-flow state in transit nodes.

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


<reference anchor='I-D.dang-queuing-with-multiple-cyclic-buffers'>
   <front>
      <title>A Queuing Mechanism with Multiple Cyclic Buffers</title>
      <author fullname='Bingyang Liu'>
	 <organization>Huawei</organization>
      </author>
      <author fullname='Joanna Dang'>
	 <organization>Huawei</organization>
      </author>
      <date day='22' month='February' year='2021'/>
      <abstract>
	 <t>   This document presents a queuing mechanism with multiple cyclic
   buffers.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-dang-queuing-with-multiple-cyclic-buffers-00'/>
   <format target='https://www.ietf.org/archive/id/draft-dang-queuing-with-multiple-cyclic-buffers-00.txt' type='TXT'/>
</reference>


<reference anchor="CQF" >
  <front>
    <title>IEEE Std 802.1Qch-2017: IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks — Amendment 29: Cyclic Queuing and Forwarding</title>
    <author >
      <organization>IEEE Time-Sensitive Networking (TSN) Task Group.</organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="UBS" >
  <front>
    <title>Urgency-Based Scheduler for Time-Sensitive Switched Ethernet Networks</title>
    <author initials="J." surname="Specht" fullname="Johannes Specht">
      <organization></organization>
    </author>
    <author initials="S." surname="Samii" fullname="Soheil Samii">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
  <seriesInfo name="IEEE" value="28th Euromicro Conference on Real-Time Systems (ECRTS)"/>
</reference>
<reference anchor="TSN-ATS" target="https://1.ieee802.org/tsn/802-1qcr/">
  <front>
    <title>P802.1Qcr – Bridges and Bridged Networks Amendment: Asynchronous Traffic Shaping</title>
    <author initials="J." surname="Specht" fullname="Johannes Specht">
      <organization></organization>
    </author>
    <date year="2020" month="July" day="09"/>
  </front>
  <seriesInfo name="IEEE" value=""/>
</reference>
<reference anchor="LBF" >
  <front>
    <title>High-Precision Latency Forwarding over Packet-Programmable Networks</title>
    <author initials="A." surname="Clemm" fullname="Alexander Clemm">
      <organization></organization>
    </author>
    <author initials="T." surname="Eckert" fullname="Toerless Eckert">
      <organization></organization>
    </author>
    <date year="2020" month="April"/>
  </front>
  <seriesInfo name="IEEE" value="2020 IEEE/IFIP Network Operations and Management Symposium (NOMS 2020)"/>
  <seriesInfo name="doi" value="10.1109/NOMS47738.2020.9110431"/>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIABiq7GAAA529bXMbWZIu9p0R/A8V7Ni7gBcAX7rV3VJ47StRlIZrtZoj
cmbsuHvtKKCKZI0AFKaqQDZHqwj/B/sX+pc4nyczzzlVADW9V7vToojCqfOS
J1+fzJxOp4cHi7qo1nevsm13O/358ODwoKu6Zfkqu2rq+bJctdlj1d1n5W9V
28lz2duy+1h22bzerouyyJZ5V64XT9nftuUWH6/KxX2+rtpVe3iQz+dN+fDK
n53as9ONjXx4UNSLdb6SlxVNfttNy8XnsummRdmty2763NemJyeHB48y47cX
Nx8vbmQF8sBd3Ty9yqr1bY0ltF2+Lv6vfFmvZeynUt60qV5l/62rF5OsrZuu
KW9b+elppT8s6tWqXHftf8d38213XzevDg+ybIr/8I/O8qYum2XZttkFJxo+
rRuZzbttt23Kx7LKbmQP1vWyvqvKNvvT9evwXCsvLrtX2dnZ2Ul2Lm9s8mV2
8dumkTEf86fw3KLqZDHX+brLs/Nl3uTxk7qQeZy/zl6+OHlxkvx6K4PJd9K3
lau8Wr7Kuq78r4t2dptvZ0W5b1XXXfmYN132pnmSN/YX1f8s+9AVw+Hb+X9t
9aE5n5nJZmIbcRTNKu+qh5J7+enduaz6Rfz59CT5+TT5+Sz8/MNP4fnvT74P
z3x/dvLSf/7xxen3/vPPZz+9jD+//DH8/MNJGPPnFz+dJD//HH7+8cWL+POP
8ZmXP/4Qf/4ZY+Jfl9O3s6qUGzOvymbaldO8Wdzzubcf33x4FT/fT8s+hOxc
tZ62TdeuX/nvFvfleqq3TD6ZzvNWvjf4fnj4b1W+vvOnhVLuymm7yJel/So8
V+Axu6NTXOjparvsqo08uXhaLKvFdL69vS2b1tZ3/sd3r/SkjRscXV5cXAg5
FNnPJ2ez0z8u7qdnJ6c/yUr193Lf8qbI5MyzD7XMIJNfZL+UXVNv6mUlH2ev
mzLPZE6PdfO5zf6///v/FaKqiju5InhUfy76D7yWW1ngZmZnL4XqOdHsj8Zp
8K13dSOUB/51pLNNLm+gYc7wplqV0+ty3VagSH8NxhndXH8cZzd5+zl739Tb
zSzTbxey1XJVZZG6JX96c93fkj/JboMvvcEJZddybsV2WTbcg8HrrmXL8Xl2
0d2XjRBEWKeO2JaN8ApcmTB1zFpe/7Pw3ottU6+qRVNn5/VaDkneWmb1OvtU
5ssp3pRdPwklCaseXZx/urkeDxbw4969iWxA2Gb7Kvu3WXa9Ec4VOYDxh3+r
haOv5Zz6Hw+/fy3fz1dVNfz6dX1fVkv/DJ/Khk9f3wx28+jKCKuRo/9/vk0b
gS5eZa/bp/XivqnX9bbNbkSK3AqJXN/nm0gTz25uf5vOTqYnP01PXtqscJdk
/Puu27Svjo9P5TqXJaYoNHUs9/VYfp6e/m3RHO/d3We2Dh9/eDO4W3+o7u6n
V025qNpKjvWDidRI3Fn9IHR1lYvU6eTB+q7JV6tchOHvJiNZHX88vnx3eeXf
yn7dlI1w6Hqt+/xLvs7vSt6366fVpm6r7Sobffz1l2sOMPYxi1qE6enJ7PT0
5OUxPv7hp5++/3mGZ2Yv5Zc/fH+6u7U//C4ifD0TgVeuVkMier0sf5Mpyi70
Ph5+/WY2FM3PSe7Dg+l0muVzEcn5gv++uS+zzbaRZcvlus26+6oVbWZVZ/J3
V4sCtFnm1Vp+X2ai4iyX5drpc1mthMPpPta3hwdBVxq1xherv5fF+HfoTOQd
hRxhw9MdkaNn5OhjIddfrj5c443H8pQcI0VDtvZbIZOUadWPmOIK/2q3m40o
O66yCXU8VIuynWWy1FZUgWQZTYlJ4UsywHRRt90kuwdZtptS3nEvaxBaLLNq
JSIDFKLLnYgKF2ZrE+H879ZZvhGFLReuR00L/Al6lnz9N9FuJnhjlc+rJf+B
Ffo/oJG2HY4Aw+RL2aFJJoRKdQKcD1v+10rUmgaHApLHb7FzOBtbrLxdhIXO
ciY7l6+f9FRl5ZlrkhmW1NR1J0u0o93q6cuw0/t6wxdPb7GpIx14jBf5tZSZ
HB74KcpZd+Ukm2877tzyKcsXi22DbfWdeawK2WMwbOda1d85xWwhAnKOpdUQ
EMnRcF1tvQqDYDUgVqfOopbjk6/JAoSqChzhBkJX1pFncnqLChwxTLJebvFC
naeuWdRluSOZKKD4xeN9tbjPqg7HuGiquYw+IHnZnkixEzwqWn5VPrbZff0o
5sN9HbeYO5wXBTRc2eT5UyZbIgKsk+2xaYKCH/fchZlf0lVVFMsS//ouu94K
42ue/L5C66q6ciGat6gc5YOtDlO8vDrmdQnXY/Tf/vvou/DIeAyW4XcCc3mQ
w5GdB3XxELIj3j7R7mRCoh5VS+oZOo6NOu2eNmU7HgsFyxUR/Ux4b5MLT9li
SmUYvj+J9NmxcNX7vM2WJY8uz5ocpy4LaMq/bauGl00I9U54j9wKo8uUCFOL
Sw8Pex63GbRhnEBPgMepH/tt4U4lYwqrW5fZly+mAH/9qvuyeytwbCVnIYbJ
Ur8gmvTXr5PsWo4FZ/H97GySlaREIaEnNScb/qLDkkmBf6yvA7uK12/IMcm5
TIS0fSYtP60/y3/zLtA4uSnoEVe+v5u49uB4opvJjMq8rXBdi0IPARs0tHcT
SiuxibIhBbfKZ417mi9Fxy2e4peNVzul663jgSSCYd+hYrf9StQb52JK9Lc1
uLy+ez5tdZtb+QeuhgzI+dv9m4TdyO7qfKnyqr8XLd6/KGUrhJkZedgW637L
mlrhVPI+47GynbLtJhAj60zmZXPilLOPNSQLTmbnEMDYHvEJFJyl8Gx8G9ey
zm7zBnOT6T9wE9YmlcFTlvI5PoBhz7va6s6WOajfuE2b7oPQgujQcr2K6pYa
NK8SaVAWPuG2YEIYrJRlliQK8AMQYNN2da3GTfy+HOHn8r5e4uMZlDXZkRzy
7ZXpVaBRLruohbmuSextWSZ0fnhg1HUbv82fr8s7qmGf6q0qEtefxtljvV0W
pJ6E2HkD5P+P1jmZ4PLpiOsmS5f90xcIi9eXYjBKSVnGtTCnHl3LNX0ocZb1
9u4+uUb64vv8ASIFqoDKsETDqNdL4cnxjDJhdzz8775zP5KquZnqE5HSVc1Q
FUfOfC1c8Rh/ycLxfdOBZYuVbwxVqHWpV9YnAiHY3ObCcvkiMonTk5Ps/XzT
ZtuNPCp3SH6eiNL2GXefmnUOYqjkhPl09lTmjRFMtRYDTkRLUW6W9RPPBOyp
btsKKo9rVr5VsuY/yAQbe3OYjTCpPE52XiYMWahd5LTshB69rjYb9bdizM28
jmc43AdSAi6mLRv03B9CBEuFS0Hlih+DwlXn6qmC8/Kphh5BMU4au88Ll08b
EW5iSNy8yy7XHQlo9P56HNiZCDjKAHh3IAP8H2dfv4qcE8Je1WS9C2ykmIE7
60h38vAgcg5d3H2kIKxAiabHVEjAixxaXLKkx3v5bd9xeXjgr+zMaMQ9ogoV
DmnbKqmSvHFKKxlRuaUowHeB2JNjtsGc9q9T5vsq+yDz7x5L/HeyR5hSg6SV
IsPAdZD1pQIGfSP8bq9mjg1xPbMnrEwdH2EhyspbVa5X0JDl9PnVlVD6yrRR
OalbU2iypmo/Z7fbtTL0MXjZbf4AWZe8w/icX8JcLldYaLqWw4MdHcNml4oH
qLO7yoi8clGvu6Ze+i+i8foIWhUeR3rwWciVlcNs4SjBIa23q7lcLKzM7KBj
+2EKzQqWhVBvObubvXJSwaHIkmty/EIME8gYmafoxMryfOwWUteIwc/AhpKl
+PmGI9eDHsPRRCr5FCn4VXad6BNBj4iUcSw/l8KsEl2+NcUA8vSerHpePuem
N11C95vzFP4j+/pXO2HlspinHduUx9ajTN6W5HzaLaQuxmwoOK7vwdlki65y
GetdJdJTBNjVu7GYWirO+BJT0Meyr3JLRZHAJsfV2f5B8PGuhxk0ZbDsJuHd
b4TALmWlv8HH9psStuxreJKvPMZ/wApvGhHDF/ZSvuzN5cWnSYb/Tm8uxrN9
B3N1fgG+II9DvTgu+Vf24fqTkoLeYLdY/0ePxK3Y1BFhO17G+R4ejKr1YrlV
VbFtRfDTJXi7KxcWTd22KWGOdbp21yLzOTzgcZ2Lib5V6952KBvJysdxadgE
J/LBZuB8yyZqudClE06mH7d7dzcl+6CcwCqgYcGLFkcKuvB/en+dOfR0oPga
cALR4MkAuU14ziUdH9k7+Q+yf+aR+LZA+x+ZclfflbRHeWswITVP+8q0qMSH
B2bFCgOel5wNTFdc87abLnIhJ5skN1lfPRBYvWW9fVrnq2oxSZ0pRgdQB1Iu
6bbJPmvJlutbHwmJWkjkI8aT8OxKVOvUsmJUrkY0aUEbMp2Qcm/R0rrBnMyr
tCzNSZeIpNqkR8l1f3n1yiKAX/HPRE99xu+VOLJcTXlFU2mfchXudGLfBr/M
hj7dnoxf5k84ImPIOYeQi7OkqTUvcVfVI5mLViE6a/kb/T4YcqsmLWdA5yB0
8uxe1NlpK/rnvFTNKFEfku2Pa23dgYVlll3lY4qaKBYf3GZzcFEabnBc4XXy
N2680HQBM4AWtvwHbp7tfFm192Uxyz6KetbIVoCPT/j9w4NKldVKnVj5Q17p
mYlcEnIutouupd9MRqI+ZsammLrYuHYDXX/Fxck4CDsWIIy6cfdA36h5EAsZ
kQK9QjkNQL09iB0vt3Ql8mswmVS2BPPYX1rzHLdrnkwjt3bxWQ3H+tbo6Til
p++yi284prIujRZjK1QlarMv0VvFcW5qOcrlBkocDSKzTPGVxL1C6ZHqGSY0
w702S3guls+E3pE9hnt0JqjskA2RLcXl6zvZduYelLJ8CXYkUgoxxjYo8cF5
oyasOWLKBzOPkyV19wPV3u8AcAW1EXneqt87MauVRJQPBA3r/TYX6dGB4q/N
JUdu+un6z1eyz++vvzoDk1WK0JN1jm6puHBRIgnGavX0/TbDy5vp3U0fiv5h
ZerkBkN+bzTNN8CW353uUc+WotEFCi3L1Oc9HLaoF1vsHb6LsLR80Q44+3H2
Ypa91iNRY15+kPGzxxxgCb+y2ej05cufxhPlX+naIxd/xBVxV64aTrqtXyzk
L4agug8T/zqf4BG8v+YIvcFlPxIzMjq+XElNDH75+jO7ObQgyGr8dlDlEZ1F
A4VQL8CanhILHPcHABL1l2ygGz1Sessb9eBbUxNK1f3IhURUy/0FGQROZbpR
9EzQZ5oV21INag7FS2nOLLyBAmwmqkfWPW1479yFPAkuH53x7jyV6i/yRrgB
zu/k+Ozk5GQc16ZhJvUV60HIAQQJJzPXhW5byqO2ni5U4B+19W0HEXGUbC58
hHTC8gr7Nd8x30hX6TvcWhApVq5LuO9d5z2/+lPmmjqcrMpOonyyo6cxSd0t
mKfBHAjn2rgXdZZlf7mvlqV5EpK9KKoiuMeieUNtXkeZOI2useO9jVL7bxXI
u2p0QwdhMrxDhUzijM9GDMHcresGwUFeQPmukPr11cX58Sf8N7lmG2EJq7Ij
43e/xI57/FL114mNNJwGVdrIJ5VgwrAcURYi0lY99MJ61MzywAI24R4iUh6V
R4wszuEVeV2sqpbh63Oz0kfnr8/VkhIqxi1xM3sCV4pRUnLhBipW5M9hwiqt
bHy8+UOdC4s6/zAOgRZnG6fwPumkQ4DMtWPqk751GgbjrnEDFnH0JOggBO5v
gL4iym35YOEskca0aYUGBmERlVCiqT6RTVL1xMHlVaDKbPSXd38c61r1AcDm
FovaNOLaxCBejveF0zFng+q5I8iB3sqdzZ+e4gQ4/75CCYK0PVlWt1SFwaFq
LrqxK+kRbTfcZNdMg9QIiSicpg1rvFbWQhLp6lpddYyJZEQadduCjN+sBRcH
raJmaA0wWir824cQMewB1Gqt/LPZboS/NhU0OrAJJ6OeY4m7ifdDFFPLTRx0
o9OTk1/mYkHOZqdwCgdb/w/OXgZRGLcS8dhf3AJrKhVjQzZnXuojmbhoNbqD
R4HVvb6+PHe9PAF3XJFBXixNzxm9uxJz22lSXrKHP7YeWRIShrqLEcEJnUeq
wLaIejJRXPNEeDqbpFL3oOKbPGJeBpaIqFV1C7eXXPMJOF6wm0dvrw3UkDeI
MxZlG21/PHitO1/hwvFju0vqvABBw5vps5BjfyyFleSt21cxbG18XSgsaAMy
ej94oTfgh58YfaROYVaW6sUE9OgayzVNDFLxgwaYJpjhI5GgMnNXEq8sLByU
dfcdDl4d4uZHtK26WuZ7BP1Mh4kCCgTGHTZAg8qQKGLDCy+KO3heLsZ++QIT
zoM2ryGrt9c7Z0D5nZvqXm+m86fp0JPsNLnn1aOrcTYSFlSGd2dRwIuO3glV
/b10p7hMY7sA/bVlN7gSYdmT/lGUv7nvatcHLlS8x0v8TQkPgOGCIj5QZgzj
ERFD0SGaKWL4Pc4wAdylbJSD7bz1KnissstO5bdSTjqcHAUX9dywbXZ1EfZx
HsQvD6F3bski3bc80mE45jhbbMUIW8E3kC80Tupc7RiGkYjjpmjNS203EKe4
+7izPIcTUcxOby56LC4vHizaxcd4uQDCxeUKSqP6HvohOD7u5MXgvg1vY5yd
vBRDhN9s6Rjz14sCDfyZWBNnG0CfIIhkDdz3zdlqM9ahP+TzchkRlfBaCtP8
cH01jnoK4j2qOiWapr+G0RIMaoTvvxeLfl0uHR7lkByRrWuRV3qZcO8eZFDd
mMsrE8BUe7kpvoRbIrRE6RwMzlGDApvTH1Eqi97j501vkJ5qjLAOdbvDg8/C
wNauM7idvaOyii4rczv/EFjZ4HKaiAcqZVcgEow0gMxEcAt15LozB0aPKhyG
0VfXMdzV8EA/2V2RI/2k0vmNaR3nH46hidM4oXvZWXrQFWWnzVYNenMkNFX8
Lk0iZe9zwNafwPe6elHL2Ywu3wvrC8zVwX7LXBRbmGB+lolqfHigjuOR8yWF
wLz4SexWJYLr6aVISQbPEQuK6jY2h7MUe9v8NbI6l3jBFSw6OZHZQjliK0Kc
KwPm62khynREw5r0YCuyzvdXyS5gKj79nhnQRgqtXSgleqbzEqE8h4/LdGEM
+wTl7fW2WeC+LNUB6XDSyITXdXhcMYt7aD3ABfZHIVoNQ9CyTfx5PvnhbUiB
CYnC4st5f30MqyGFIpGl+0H0yBQQtxD4msYAFbehFT2Pj1mYKgaAPKLQ0Ytp
MB+FEjK+RoYwHgQ1By5xc1wApHBPbRAqutr9V5goeFVgtJmY+b/9szsIfGfC
d6kRCTPLYInD+HHcZnRmq7fLvyDCagXY5PDCt+oZkF0hq4T2jbHJUqHtL0Ac
QM7txlyTMRQZg0nAmwSAozG2uai7t9hxe1ZRSeF2z+l5rkVVNC7wWC09LAXt
rXJQWQ9tqpJ44KFkcBsu43BENIHSKO78KeiiMUwfbpU5smReipSSSwKiSAK9
kRzisz20T/Jy2T5unh/AxKPiQiLyq7vSYnxBWm8o+vLbjhAWsSuXCLcwzL+o
SSRiRn0GV1oZdzo7QaBf+Ct08IRxyz04PDg9mZycnGSO0hiKRde7LWIfJ/LP
cjcLQjrESlGks1xbvR1hq/Q29CRNew/NzBFaiO0Y2kqNx8BYhvyuS9y0k6z3
5jDpBK/DN09wzOqIE3UMQVsNNDnHi2rwudx4GY7RFkSyTcVI0fijc0azU4ZH
7lGAsa+gilEEeRhcfYdMolvzrt4i/OzLa81KBggW5DXLXuNAH4mmofqUTFwn
rbsa/ZIPVd6nQ/D+/qOEhmdxJBHvQsm83qPA7cfJpFTKLsvbLjpH5SA/z7I/
xSNa1qBSalueTtSfLgexPdYQX8V7vVCPKMWh7PpSP9ApxxiVjb+43zZrdRkk
klfupdz7Ng2tpshuIc+inO4jjc1y22Z96bgEu7Ob7xfSQhxQ0hIbaUc4qdSx
GLkKt2dMQww+soia+RZEwtR09cCCF9m2TwVcxLe18SieWZvvPQmcmw+0RL5Q
X1Wepd+RGYul5S71EYiww04g6JEl88JB+mNjd6oZdZXmxvGrAGat6ojYOgiL
QS4okdbzv0bAL2KSBb4sE+UW6Zc0k8Ixiok9lDA9G6DHhHOFjSSKBV+ZGCEx
2ibys+1yxjeG9rHYEDPlcRalyAn6gMoOtOAjnD4lpoh94YWK3jkLjiPgZsgj
YkQj/2fUzZ28OCuQYFROJyE6u2/cnm7V1nJjng4PHE4olrC8rwdIkmkPo632
6+gOjStJQoZixseNDVrHbaokxu2T/VKZSp8wcwbMrRjHTmSdum9X+V+FeXee
jQEVpyMLZhQ5kXTuVYy0nR5kD1LuOO8hQuxWrAu6RMSaBcMgjJWDY5JgdsuH
0nQF+W1jyLihrgKzsiYKcgGg2dqxLXlRb7rAeR3ytw+6++W7tgkhxgGHGV5K
vqie45Rx+1a2DV1AYrdBm3/l98iiGNTUjSqKWi9BQjoKc3avRjgs/4barmo9
hjA8fdjLZW1ORsoKGAZMckxsZpHLnKlj6oJ1KCRN7EmrPJ4SJeimNETwDdwQ
8gpyN1e5AnZd1+OX21XwiZsZ3DbooEXtzEMOl+Ff+hshm1YIhT/1WH3UZPCv
4cGpJffDCeKtfZZOKAQ01JUh1m28vVkUk+z60zS6UJBb/PXrjEl+DSIhyRiX
Vw8/aqCsEA147Ybt9Sf5teVi/Pwjviy/Yv5USYkg6kolnBVIhBr+4YSjUQdV
Lcqwd0liNggCFyaA+Amft6A2CauZpIB4u9O+wwF6LU9vN2rEkuIiljXVTCaB
lB71bTuow2CmgbaSRcAYy40mujJYy3uBsyksMaQ6iTGyFWJ+ShazTJG4cque
CO1zI1JosctUBRkmngVMEWMlyM6LRo4FbY0RAEwoFx8J4l8tChaA+fA7CLnK
MQZOWcRNHax/SPa9RWLlJlwSRnk1dY8jxtquReNuQ3Bz8g/RkocHSm5nP8FV
R3Dk2BIuggrH7C76g3p6LvVAvi3BaRo1KBjx8CDMbgKtRDUUNSiVEHLdux4l
2gU4e/kjrmPPu5AQJrRE+tanCULsuA++He4eFxGnne7eTCdCy7YpV/WDxyDz
tq0XijhLpeSGjiVXwnobEJIphqEFU7UPD+TyfjY/bU3p8lBXxS6ch3LmHWyf
5VNArMru7K1IgL0qinaXhMzzESdoLEzXm3A71buh/trRD7GzwspMN4rIBI/e
9yjaVnGc3FpHs9JkHVBLkKcx4++5qEyr7jUPYiWKgekMzFo4e2GJHdxgwNZS
pg4ZD305YuMmIRVWdRx8kCSt0o2sCr9M2TFbtNij9sOFwbqndHMrPKSPgFip
+wjtQJDCLMop/6jGTKNPiBg2muXtEFCeULrwRn4j8eiQMwSCPnZUt0bjQiZp
koGogvGhXNYbT3fZAcv24J39JRcOlw3nrJHJ/jxUGAQXv+fcBWgZn4bQPE4U
T+GWrAYAEu2IHUze6m87Vo0kueXHgejVghxypaCYkzNfJVsTbllJLE2SbMzr
49UGUiA5bdVs2zeRLdxdF/lTD4mn3LkWc3+dfbyauoQjUsxzMYLC0idYhdeV
XgxCx7ml/D1O9Ul1u5iy1rMiIJoN0k7+RqdEOCATKdEYGDgJ3W9SKEQ4pFLs
MX0MSF2LHTlNEeAARr6O8B7PSBXab3G53a+yJ+cxoBSXdG91Yik2BE4F9x1s
z7sG0TWDOj09l26D6kGM8yRuKEVhVu1i27bRoxDyoqpW42pV224Dm7pcibji
bUmxycoflM4Shxu+44QNtXWkCNixmXYR4BPCzcqc6Pmy3EK1T4t6haIEpQlx
mIXUvDXgMQw+WTYAVFf74ij1Rapbl2QxdlBvlLNCEnnVxHRZhJs4owRfDu2I
Moy70cuKVGEQdCWfEs1RB/8iZwvk/JAvt2CZTdWqtql2vBEbSYCp6Y2sKBo2
+1/QNxszKi8VsK3YK52npUWjUk19x0gP5uHVHei3YZoggZJJ3jAAzkgPyuqF
Uu9Cs+MjaC1AAAJgI8CIQs7RnPnT4dSAk36XRGu4/wn8bOQp09h/4dkxDc1C
fji6TC7htKunpSGQnB4Vn5okSYbUHX+Jm5aaGHl5NVGYnR9i3ma9XHJwRtE3
YLa17qr5BaVqgMzJ/lKtC8RHIQAsco6gqehOwDzy6vwFzsNwJZOcrpjgsuNM
h1ilQATllfsUO4+bKD7Q7p8TmfmaZKaAm0wTxFc4BHsJ4SgYi3M/FoZbiKWF
n3kZ6G6fl6J8VAzTRSSZQZTmvUwFfb/KhtRZIRMx6pQZe+bwZFfz64sOZVsL
BE6oV1A5kN+l8Q11qbRdyAaPCC5kp3bAkIdFUatxdnaRFNaAIJBTCyqy82Sg
8mXsoVgs9mWNGCMMJ1g9j7FpLTXX6qhYKD2+3uAthrxTF8ouCRzvCvoKXvqm
urujp/A/ezYpbeKoWcrCABnqOYGcT0Y8Tv4RUwxnWmXHjeh8hcpt9DqpieQO
1Z4jS5WIOrXrGHHTvIkEFLDKnxTDqM4seuYTgqj+jvfKZv4SzB3nT/ALZNdX
eil3jubD2fTPVx/5wg/f88fA10CHzJDsjwv1op8i2ouQo2wbqkpQecy7rlxt
ND8eKvyx6sx6A8zShJ/MtzslLL1pKtWjEdfTiZlhnQAtxPg2PIW84In+Vl4j
z6+qRH48roPgZ0W0f4GDywy7aS8DUWMG+sHVBV3i8GO1JWIbcqJufC/qDbUg
9d+X/gVDxIkaAnLGNskdYYhsjau1SHMuwcCrtVyQxZK52fXw5dTMalEnuyrB
JKkNEwIzfLDr8sU99XtNGJ/ZEj98z3O+kyfvMJ0pKhYaM0pSP0O4J+PnGfGx
MpgpGLnj6PBphpAAILNG8iI/hIAVLIa9D1vhvwjoQI5tG6Qk0aZCnjFVfT95
FO4ByGAvnTBfSuFUUUeI68w0VYg8vEtOI93Nb5xMV2u8Lq7FCz8EBytWZs4D
f2sMVzADO39SqWbyiWTby9tBiGbB91L/tJ8PD0AUnvivyWYgj15O5sCgMdkS
+EniQaN5FRyvreFCreiHKLwKhgtRBJtgcLyEIXkllQCUtTm/NkegYqhBK2cv
fvwtJCx6BAz/rbRUIpMY9zlVRryx8vWM+Q+c+bzq6BBd30Vo7w47oxtcGAem
RddsqCz3pV/Z52uAxA1qaJnWFhBIQae0ek0eMNzYW4Jscy7oUBSc3qpSXOrY
Tu6WTqRii3UgxI0UAyL1kf2xUUjgFrhyq6slv20YKQUvhFO5ajQPX5aZMZbN
0OK6xW9162I2iexXxewPfLaThXVPTKyJE1YmuUphA8ulyrwnhXrBfTxY8CtV
8izzIsthSYCaqen2k8n65Zpu68XWnCtJXcs9BZvSxJhS4wda/OSZ2lCQmA3n
roavhc9w3UDCOn+rtRZmU+06b3tekZ5HxCGh0LUstUoLpFgeI+NGsrQdV4rN
wdAzuuCRjLHZcs5qgY539ngW9zgF0pgxpuCX3RJqqS9Lb3YWD0ZT7BhX24Xu
sJYJony2zkgBKJARZj6c5kT9cFFf1MpXgIFYAQj+Rwlyu7YCLYqOEHOPub/y
7rYdFuIJvlViMOi6ckmE8L266RMFAGFRDuYzxF1PVD0r59Op3EHIbZJ6EpXX
9Q4J0Mpmw6yAvk9SfTSNutY0XphM14urYGuBMsVFb0tzs1sxhasEy+IGKfKk
qQMH/yNXO5VBCmjLyCPcxSJkMR9TPVJKjhO1B6kmwilpgwwQdaSx12tPPcem
qFe3f8jBPaHOmWcxo+pQNq+pZebp2Wsubmv1SW6rVAjvjqOrXMXClf0qHFwn
zG4RSYyDGWBggAjIdwY2rSNg5tRJR32aB4+aFX7kyUEmMGhqSFP5Vq51aVSQ
au5tIcbKIkzgoWq6bb4MxVcigQRU6Z8/vZvKRYW3gY6IOnvzXtOIqYy79zlx
qtp6Sy/kQ77YYxiXdunI0wggRwhra5RS17fkHetYKLeX7KvZsXbbzFuVbInw
OkbbeZrwrlVi8heowKSsx1O5nzcC4ZGuNSuEarqOd1t1MvmepZG6J3AGo7Yi
i2OO+unLlz8CqTWLdZ2IDAroME0Gg+eLepWzmeRCs5YQA9jhOGRrhI1WZEfM
CC/yDqXFILDnWwPKzM1rhqgWjDVj+iYD1Kq9+fO+IoQRoK8pddNQLuBBWJMV
5ulXGoTmkpYV/Gq+lZAGskGNRmS+e2rYpq5AmGZEbFAFtTLJEBCYIOd7lkVL
jh4+hO4Rl8LvPr4T9QILA/l7WEqAmW1U0FVzTRxkqYYrR5PqF5Axt3TiVoYu
2FGneJ8UkiQrnHq1M0fiAQy9CPvb859QAfAiYIomtKDT5cDTnmEsUy8UsGrF
lgw2oZWTGOzRmN2++GOa1HLcj+9Ey9/dGH3rn+w5N5f3aE6gjYkHOAWmA6Ql
ZWMDrJW596OS78+M3RkW1VYAEaiB8wyOgxoUdlqGpcx/IDdkySO1l6jRMUqW
DCGckpLCvtVjyUJZ5fJWbUbCkdXFmo9pNdJetvSAfN7A7IWjW4V4uGJl0bfx
5T2j+ZhwM6hyIQwBL+12TX/e3nsTYtJ5z9RjodZEY0hPM/rk6e2Cyk13Tkpd
pCOsyFLOixpxqjXcIuXjUAD1QLEkaMVlalG4ceaJtYELxDCCMyR+IZoMCRf1
2CEA/EzrX2gdvqtEG1RAoxzBH67Ox4QjlYP6XgA1yLUoKz1Ur6MLtugWRChi
N9C7ZUu7J5U0cBU5aTPzL5YRSs9ElZOB8a7JVnnYDIuRlQUjU2ASM6sX6MJg
krWaUkLtXZaWvQWXPufyWhXXTe6MSLZeTYd7raEcfeQKQ4CQgMLpGg19KobH
mpjJbo7NCjXaK414hz1W1+KmzD/Tm2d1toQgjTKEhFFJMrs5v8Ie3ZWtgVx1
u4RHLD63IcGbAWPGRtRunqj7F6r1ukW1Fl86Tkfh+VrP0mAuDQtopG60khwS
b9dXTRh49NWGGI4oHm8+4bGZptNDZ9WYP3ePnuhqrepEqFfkKH+m3qyT8kAh
fIyozLZTXGymGET3tCA9AyFBz2Vde1Epalka0NiEFB559z2h/iOwnWhaY8pj
zdorqZgfIZh1BP50JHc9Xx5NHGHH1/DOQOokNqHTXquIvecu4laoRsjYwxBc
XDBWZtnb0spmYHdkRI0fyC9Ez2j0HMBs+77kHTcv8FNe3zCA4gPh+54qNFcu
KhXXPHt7TlW7dkI2hrBY1tsiyQdT2yLSAi+uVfeJ0ZJJhH5C4JZw91gTCQ92
mVPn9R9/0aQ7lf4Jo3R5aynOr7CSxAPgMV/KB2Hv+1m4wfiCdTOhEe1QdvMx
r+kds+KbOoyZiIkh6Zzd40v7gnVwFfflBYRxSf9M99Szqj38Qr4ACztzzck8
26rymoBS52Ao4WiBAPkXsdkr5uPiHVVpBQ/jfD0l17Je4Hn15aP2uSoovpFd
3SE0FAIPFtmfeAIJoJuGOtFar3Umdr6s9PZJfZJY0rSUTWPt3MODFVocNKFg
ZEghIAGKxmklQWCqUZaun545yH4B+YhOYfHrgcKqWR1GqvCt+pedY4JmAzJa
r0dx5+BNK75Cj9S89cSaZyACFh2lQfqkmpMvIH1Iw4I7xGaxIae24DjfJbvj
GNcOFsDVzZWSUVLMFIxDruzi87CKPEM3cAA9V4QuVP0LhRX2juNzDRqbYqh7
eRy7L8mXdwB23680B4UqoRKjIxpGt/kKumZ9Ow4se9SOzWetYkRvQWyGwfYm
nqKZjWQ/UGx9UCwInS1OX/z8M7fKSnyBLq1EmNdaa8Sm1WJUsVYXNpg1zNQf
TZtzCoU/+yX/rVptVzoDiq4HdGtqGjg3Rr/cXF6MNT8EAcuu0+D46YkW51iL
+TPL8JDz4ZUNRxCBH/6izxJ4GlpWCPcec9OtX4n03jaGNlS7OFYsxojKSN1l
w6oS8uXKBTsrKpS8ikmFeWOcPcUVRaEIXCoQPyg5F6/MMeGgoUprqFOStjpY
svlP3S7EvEpKYFtMp03Sil1kNuWdpo4A6dkZFNrK85naBEyQOqfLFT+QvWAY
wocN75ernVjhZG+kcA9MaaxPFAotKWaOUnrRPbXF8EARRRirI5uCJ7xHZixK
V+qYto326EYoXNLC2Vivze8hUysfYPbaucmyVpvstiqXlnzYA72mnl2epwkg
TagzO5Q/uGfZcfsTxVG1HRlMLDyIo2WFGS21kmyLhjKCKzTozpy3l4FYq2WU
o5VTkNOEUJl6gJro6hi8YwUzrwiWW0VEtgl57IW1WJe6SGpSEoq57qWTEAhQ
rc2nIgwGWLqJ74k65xJPwbxaJvammFRrIcLtMqlOomFewMT4AW13dAihfTNH
NGXOc7RQHcNWKWXR4qQ2E33GN8bCkiI5RIlNQOU4b500pIdIKNZ/CH6nvN+i
QDPjwfvtNm4CQ6Qjum5Tt7qV+xDWmXro/H6V51efLnWX9Xd7G0vYpsW9gpvN
q0npC3VzwrFbYkqnEUsWz6pDdeSV8L9Y0eejrMQZPnTF6M+2biOtlzljYrrF
/rq0IFOChU0RLiWLVKCHj6eQaF5GhTCjv57ZFKZiE6cWclnNiT9UvHil1IFr
3nD6AgqzZjD9kpU/KsXIVuYdEu6mVUBidGmeovYM6WgZPZglki8cmuqqdcCG
2PyVB5McTFUwWoveG8RR5pAiiyrpZcNwC7NqzGGP6vdaoAFL4Ihq6NzG6mqP
EeIVk7xxydIVuDaCkBZC+BFxrbEgXmBO2L3hWqEz1FYYVlVnVkdaVt2LskPh
TMq+77Afb1Ehy9hGLG+MWgVVbKGe831nIVJk2xgmCOTD+jQ0o6OsODwYxeJK
oXpZjxxjwPnftMzuVEaeUt4DHocYnv4zKLbuIzWsackOOoSdP1NNuGcTmqDS
Wq3wysJrS690Ut930AcJHSfgGlNc7rf1OKXpnU5L3CYvW8h7AZewB6L6oKaY
7up1hmHhhTcEgGXVRBcKQisBvOjH6Cm03u5F40dHtr9HsRD4e61o8+WLNZlD
uRq1jcP8Y+l/uyeJCQAhsDNp8Ke/l02tst0vF/Iz7VukOFfw4uo38EEb1H9n
0EmsV9lTECfZXaj+GcvUJRX+evU+7HS8VIK192EWadjjymu4CmuCD92yD4Kv
+5unkf3+w6j9MA4PhluertVh7vS7W9Jg9PcwaSOiyB3auktRMVvaTWXbi5gY
tN4Kb8I7YADnS/eT9HZn0vdNuwPD6ZuMTGFi7AmjaFciUuIxxYJbft+TPYW8
W8JJHMYc5Uusmt7qW2PRvUOJzb2QuebxRdveUCEmeUeo+71OC2YSRT2VX2gB
kT2TGybRMtYFDSrt20mwRIF8okTpm0EtlTNl9xQfj3F7tjlSVxqqJnOmiaOR
TP+eQilsYMzf9Ts0IPuI74Z/LhtpylkzjlVybs3nY4WaTYumrR5qQlcWsu4o
+MMX9fx/6+xLSRHNuIoBmOw+b82XCDawyV2iaf8h6I1I7LFQqk4FulEDfE50
ixI3H04ebRDY8WAPTw76Spo83ZMFbtgrAMS0kH4l8SzplAl54Yn0JU2sZLRX
2Sf+zpPrt0VVH4O+6iw2R1uVRZVnSS6pSloOa24X8/swvnyLCXpBI1XaKjOp
aZXGEgk6MD3Wa3Q7LuBpBjjCr25/2TydcLV6F5TOLhJ8Mv5TFvM9FmxKJ5I9
aKFEtLDVSIqwHJyGlkMeTsWqNHH6hjlNYGByFAhH20MGvylztRJWpgp5/Vyz
xGDWx+Q6REpX6IfjDq5lXW9SmHwS/um1CP2AnIZYNRX1/T6cj+3ruHj9cb2m
QlPP646G0SLXCoBRRQ/SPm2+GvWgmSe7DvbIE6n8tEIhNq+YrPvdP57sqEe3
Ryq9myi9lhqdD77AHqjbOy7pvsORSvJlKQeYQECCjiPfQBw/mp+V1iHlpCeB
fYaWd6ECVl55t7HYthH3vR9fIVCiCYzDk4gNf5+KoXbAGkyyOResgupHdzBS
urCriZPCcjZkcWhpx/qdUPsXSWmbwNfcQWTxiDX5L4QPywfZzh37Xs0sY0MP
17+bBy88HJ1mURKOGyY4xFh5zdvlcqp165ahh4ZWpTexS/tCQbSaHUkHonmH
xABHoFsTPXvVjNyy0xFn2Wum7A8kG7bzL68/Jpa0qRAcwc+7h3QP+jY1X3X5
htvAvCprfhrklbVkYAUFc0m5m95C3UJK6uUzzdISkYRFs7AvOkaGTD91liLB
xyJyfZ+5WiC/rkMsiK4cBuUU4ed8dQvmWxaq3xTVXYWYwM2fA1mIlnItPOim
3mRv6t9wu65v3oy12ytPGdMYQY0hCjVc0HEYbKEEjkidx2z1gia1ZjWaAjyP
vFpeEFD5Q4Ypq/ifsxcn6lbwMoOJo0BrfyH4aQndCND8L+Ebe2wYeI2v+uTQ
Q0elrcdSS81xz+yEoQ+ABfW4DmnWQDQOTTfDz4gJXqBGv73uM4pHaw2jX6Yj
whrR9ahRJZwVje9/tK/wi1eDzK1mWk7rlR3qPLIl//DahT+z32cyKc2h3DML
n61ONLFAOb3hxIQyocBvm5ArjkNDlp/BcikF55457pvggZpkQkEPQR7Wgm7m
JJWNVv2xumXdxeuVeOu+t8ewKNrbEKKIVCkMiH5MzRRf8LqobZ+dx0AMyzTE
Viq73SCCT+XLd/eP0xjCCZVg0mpVIdE8dU+kbWQAFNvbZDZiyxMgiehL3LBS
UVyLUCspTCoG6pJGJyluaTrELWX9fLp1unrfUHMVv8ouzLHEk+z5OdHcpyUu
YSEqUOPWDTJLRQHOTrVZ4yNLzCeuILiQXM0l8eTFQ867rPNxdJ5Y4ntrUFgJ
grSy/74i+uOJ1qHgFUYVxx6uIiBRut2a6kotsd2kN6xSV/qxgbAsm0Ef5YPC
FdInzN/GCuhtVLXKQUbeqrprVHjEsPUtfUc8EJn5c7Ch6CxJ0+oUWRFdbc+1
NN4FhA87U3udohjXM3tESbwb1GZPmsMMj/7Ij/goqWCBk0kMMBxHpxuKnWdQ
hWY1MvDT5og0zowdJAOHBhxWIb1QpqbltTyI63RUFscgHXlo+K5ouBsfMAU2
xv5Bv0xYB+iQSGe7nw6jx6tq6763Jwx9u13KpVZ6SGvUx6rplj1eARLIORg6
Om3WvQ5Qz4lW0klC2MkNa5ktZQIoueamGFrqUZJM2iUVgfRTwLgA/2qevPdu
EiiPBaNMeSed8CPr6cS8Qq1FLxMrePUM0t0pvogq4O5uJ9q78LDFfSU7GQqU
Ge6RA/P14Wobjk2GZ2loIfdKCydal1FAWKlHupA5JRo33PaQIc3MCa1t6dg4
bdSiYAq0t1+xhTQ00A065zSoJGPv8RQKsokjla9krLhM8rJ/SljiUTYNRxCQ
mrFAgN7P56GPQW7AqbJ88mw1b1VMsjfs1dKUKjNWKNwIkisqecU2IvM1OeSu
4YeKeWb6L0rJflZ4V+BHMRLsNXQNPhHslFbBIuBWGFIZzAfmAHsgjwULJ37S
Kakm1Oa4naSMSmTpwcUn2m0dqYMqgW9Drk2g9LUkkOgYTB58bKBo0vMRKZSA
k5iuPtnzVbdncMb44pT/0mXg5ccYGGmxedE3/19FxxCAh+QzNF5c4EdRHcR+
LOkfSvDeRaVVrkoLbVjrIWtEzAw6EXaU1zgKAy9W1uc7SHu2X0eyGsA6NGig
AHJDXdgJ/fZ7D1oleRRhDvHiECiCshcvmRcLnCQ4AjNJmriEmA9v+O7QfZtX
zNcTfXAjxCzHZEVRvNkydWJexcmArJZh2kbz9LZkFdPckopNMd4GrYB1OVD0
Tx8yHFmo82dAByF1sLFZit6P/V5xllF4M0FtydrphCOahWrVOXSpkOixHzWu
l9hoQpBmFtA1V7lBg7NV7ZsyrqHzh146+eiBpEikhjeGV5/4ikkOKUIiiX9H
jY2O7pFd0zGpekqqdpHimrlVZXHzuu+j5tVJhB/FrZaQJRZoCLKKPWrQrc9b
4WjNEQT9Und5UuEGpCKyuWPH8PsUoc+61O6+Muj4M28LKEg6edRBn4AyNGNr
+JUAovNLT4moWzQLxc95n+LHoaz5/jHpTLEaZnmBb4x901WP6qGgGUYGl86b
NhoJ3AbTqvhjPIPS6rPnjcWlQ0kdwvsp+0eKE7AqwgTljrNgoJkMX9Uy3TqS
eqB0zZW5rX7TbgBmHiYsby92b6fOm8kWs1iFLFGqVYtVxLoYMLrZIxSB+2eL
RTi2tpen0aVdqxWvMDVqTlM4ZtmfNoVq7vtaLOh29qVXwLjUa0Vk4eWfy6ce
wpz7mrZrmrG8EpafwKkTgtdXqLfMKm7U67tay1hp/ZuqDfzEUjXybF7d6cIB
hVHy1qpX3i8h3RTF8hsbTsyCtktBstZDRuHxu6h5rJQxg2Cqwmk9qIqea6xP
80Tgd+RWoMiu/PbN+6vQfFr31Mz511ksotV3pYnRHj4KBnuEJG+q0Nz2sU0c
cpO0HFIIK7pLT10ucL2BG9qG1WKKJp7BUMYnMU5jyLpfHiv0JnveOwUU35oA
M9k0TH/bqZIGn44nfFvZYe+HWt+aPm7TRggG9dZCXJIv0pe4HkGkfGhYPhfh
qW9NzM4UUqfn1HfHqriDYmmHyTE92wToHk7P/eCaLxpcUJtmWzhoaIhpiAeR
IqSSbM1e7RnzbqOdAR9S1lpaPtRj1E8T/FSfeKzXT9pog275zf1Tm3ZzDEWn
oAqEjBZNed71nUfdZDR0WpCcs/TPdQQTT7IbFA2Qvy/rG3faDx5P/szSP998
7LVqK/IHv/hoXqvpOVWC/d+6uoAyh2/ITy9f4lcXvxm7OX7uS/8h/zccR5Wi
Z5fxH9m/T+XPvye/Opb//fvzz+uf+IVj/feeL8i4MoHTU/5wdXpmf39vf/8g
f+9+63j/e3t/7GXs/YXBptOrs9Pf8b2r0xf6zbfn2OHegr795z+SiU7/U2/8
aXeJ/77vycGffWes+3l2wh8C5dkHV6c/791PG+7ZF6UHpxuqw31/sv/5qx+S
D5LvYkvDpj67wmeWxReCTjJd0dX3P9ssXj5/sQbreHb855///U9fXZydnMjU
5O+Xv3tK/av/n/nW7+Er+POPmdeXV9l37y7fTwMjrbpl+a9Hn4I0t5IuCGFR
hh193WGRGQ76dYyl9aSRaqcBFep1KtiaOHnx168UpqbYsxjguvQeKiJxwaP6
DRhnUDpCyb/CIsceeaWPdP0vp9SJ1kXOCjhpjkAT4oU7lhGBxhpVWSlSeG98
a6JS7LaaN6X3be/n9KjXbbM1vyqepnRC+gJ2F4mF2mcuCHwdzS0eeyj1jQAY
FDHS/VBF12yjH0bhnQHZr3jVNer81RtLFGi3820zDyrDSB3K8Kwhak47OlaI
BJ63UgdW5gqQystfzHCbJEgN+aa1tNOji6AHFnnUWcYuWzHRVn1KOb8ado3z
eyUHTtC7WayWSCQks6bLgx5N5HuoQ1J+X6PKpeU7hZqmYav7brweRETV46C3
GexWiwTCH0IbVx3ZWSxpCevGzAJaF95pzDMiIhiQxhx7qOSaVN0rKWt1YRAy
Yg5t1N6YnB8WoNSP5kVq0oI7Izd3qrm52ejt+Xji++OFXaKW4KKfyeWh2TzA
+G18nYUmNL43Sb3k0C2TTKuIoBGCUBB8ZB2PoVZxwnx8ZhaYbO1OatK9HOzh
AWvrXjDhbBovPscZ8RxozY21SF40yJCuD03P3iObE/J/UHKISJl6O9dMIxk/
Viq+XOsdAbgm3JKmvFPUzdUEW+Vf4GAa8NRwj9ZDU5Q568IBCOPZLIHrcVvN
6AkQtgRlIGqdzPciaejsB6gZPSE//Cp5BIAcMWUQDZItx3pvrWS2sr5Bpfck
keXq08Wv70J76VaLhE/MN+FGWs+eKdPiPBoAXZYP9HTuMRms6t+HpLQa8zcU
tOSNcoJjUsvpqPvxZr5xLAcEzhp+NQUDRj9pin3PBtB3OhHNNXpPCwTD+Np3
oJFYsmNCQ6gndmfwxuZqQmWph3zQEfRfsnc5KlUes/F6B4Jhf8ZINbK4kXpM
Yd6OnSxqniXsk8zdjUjro61r2UrJq7I3A+Msxqc0r5WbFmr0EW7VWk8dR5jb
x6PvLsfBpNb+zgTercwAYRAFDnWcQN7eM40nVGD77vL/PAtrWFh2ag84LmvG
MKFHW8+TsugjAfoSNLh2bGfTNn2xs2q/d1npfNBqFFhJEGN2pgNgPjF1NFZb
8gQS/DbUkZn0+tm3qfcB4wTntQUO5zEbkaVadG6yaKuSfkx6ipzzfjv/L+2m
/lxSm/PSBHkzr+R7vI2DflZESbBnnfpp+2inLLwdggMCETuSgPgCA6DXs3Id
LXAjDjEgrp2bEQ7EM6EjqfEARt9djI3kR3oDUA1bTfKdvFo1x/HexPU+LwOS
y93tovPFTDK8ajiStUXPnMD9SmE6QqWTJFGKyBiomhpaq9a7vk/yi1BFKhZe
TUi78jK7gAD1gFR9ML63L8jSe+e9TrKQ7bw/2fkqAtswid91Pu03DmjAi2yX
Q4SDtYv64+OVOlU/ElnlvUmEcDiXCHn06lXFcBRLZNnkdSQHUaWIxJg2DK+q
kDyUY+pDcXNCdWmFDWZhSqKDWRJpOPZe0Q2RU5t73kgmWsQyVJxOkqzFGzCA
CZPNhLIGabLSDiPuV6bTsTR60+84wW7VDhkAQ1nTWeu9x+yQulDMDiNhL6Ig
n6tr1zuQGj5gp9JyvjyOUZnjtLQChkSIaqPsNgnM2ljBtd7vpaf2Qfxa6pLM
ev1gYxfR1MfvuXsWN9CExVIrl2w3vQu4c8Vl+xmYgAlRPnimitbO8e6PTERd
Lk1jWYVn7QI2tI6ifs+eT+xLpv5688R+hnLj/u6wzdZLmV0M/Np5bc9J1u9m
S/hRvzAR6kqlZbWS2vZcQsQ+V+uBumXKFLsn4hHcQLvDfW6Da+TgB4LBvkcj
pNbkS7bHadyr/qngflYbRqtTs8LjENdUewCTYognSW3amXLQ5vboODinyJRW
TPW/iGMNWzhbNCwtIcoU/Al5gEKz1YJlFeYbb/2T3hAxn/w8NSbi5ec10xLK
sAINslTYFlX7VwbiTeo2pefnDPsBOdgp1TS9Bm8XndicyzdaU83SAi5UVVK8
sIYSw0JG5Wz2iq3M9Bci5dJXWvoHZ8QOZ9PkxWkvrLTBrWYqjzST5uxkzLN3
PW5exsuQ6MbWsSu7TqtKOG/8MMyKZPOOL1/efnzz4evX7K5iDeM1rem0uNcq
tyZ5ndfCiFh3q2yvlzMtVPdsKmZ7HHjzIOSDsn7lY+tgczNorJkKDi5dVJIy
FrreJOwwRKAIYVoiUF1EjGof7jrRXGeVW44VjCigYXVCbYATE9Wi0Zu0agnQ
35Un0r4POXahUuTo/TW7gL+/ZmGlUrXRQuso6p78OHuhqrwe0owQevlaeFqz
xGUbEW5e9KoD94utIN1BruznahN6zMiJydUzMC2GMWS9NmiplaNCce4oEVGa
REuIXBtKfotkmY+xrOY0e52m0XhXoWuDqKZaG1JTKq2wZRWT0ip6LKxeaUT2
/XU4L8MRBYHYL+wqmqn2G4UHxeo89zYVBGEzCBusSd6OW/RqScps+XI/P/ni
t1c3sqHH2nbAz++H9PySY9uTjRWb5Qxfdnjwjb1Ut5lM1aCHz5bMMeCEN1uM
El5BMo7KQUH4TaxgvG17ET0H1JiT8egyQdV8clTNUaY4qCUzdJiu4hv+w+xs
dtqjaY9I89A2nTWf15K5BnhmKbp96B3LB01wH2GCSf8JDusW484YKvMHnkEk
QeP65lpEVQOi9TrIvqX6TKwQq+ycqq1Uu758+dOba1vYJREorMpijbOhC3z8
V+tQrnovpbz1C9Tpu/vHvUsBwUtvV2hw7mt1QHDa0djV9dDQWN1cTCtErVkv
YtJSd2BKhzFNLYhLb0XIBfCP1BlaeGvfNvl+O3jxvLSkCOt7L2uDQ24LTCiK
6IbiEHNSqL83Zpli5FkWEi2G5bRVs6e0UDy6vt4d9Zx/9G9pDpfnNXD+5o9B
3gtK46U4P4sJWHpTAqYKLEc1oLAgCg9L2PqoYvgvmnq1j+Q0L0w1ZoWBm/xK
McwBOIhjr5cG+zZrNTSHbkQJ64zetZUrMoAdNh2Ou0Burza5w/J6LX6As+G7
DNUaFmW5SDlcUB8dmjfpJT0aldC1z3DRtlNb//Ly3eS7q0+Xv46zd5fvfrXN
nvAhPRo/BnLsOGajmdb9XnaX7n0ju3kHVPVI3qC9vULrAn8cJZsDcmWgwx5j
Tkw8HunsaOsB2V9vtAKHcUP0BKNvM9bd2HuTWAUm2Vu/Kt5JMwHry2x++dcM
W5P9Txk3J9BgYFaB2Kxhe3oYatMkd9ROOfig6rZMKG7A44LNCsiRopR4KzXt
CFP8dfTx+Bf1RP8J6dDdds1Ww/TZ0E8V8nJZExcFMEN1JfUpK7iLd3BdmxiF
CXT2QwaKSMsQAcQTijHttYSifz94OIiEwkCtJTRbZlWfu2OFYemUEL18GS9r
Y4zEcbaWzIGClMLeFd0CSVyuHyqRw1rmR5NeOq8KPu/1BfcRHRWs6c//aJlB
UJgqaYlu/f4SrNDU02Cd+Y+gE/ayssZif4hRXy5D/01rpznZxWA/LZah/4p3
BS53+yE8w8fkGLzcQbXud3sMpbe/KXjdrrC61V68y5L4KEez41TbeYX2spYZ
lI1OZ7PTE4YtnA7HDgPUeqnRuE0861NNzkQkhwevzXS8TJxC19WhGHuJWM6v
nWxS+MkVxHPZSeHIf/SaFrKX7yIWcnT+x3doni5/TU0VUiie0Ne3v5kPtFjX
myaJkfDjRJWYvnPLO6QKZxMdb19j6eCqdK9s6Iyc9JHX+r7PFJRUk4HZtDZF
L1xQGV8Fyo5+SaqfASmwm1TJmmyheIIXENecg+iSsARYT0Vh2ClQ+8DDAVcO
6TvUFfzyRQ5ASMrSFAhtS8KardUTcmmkHumqLlBaFiO1BF6zYDT/afniTRU6
IuwtQ/lKBQu0xCASdGbslzknpcUS4BQv6yKGgGEK8fkxX2hhd5+a9QcGro9p
QzqFUJMvNHVwAIMQQ5he9HDnxV/zhaEObT8movwrH2AY+ObKLHbhYvd1kaZ7
6G4g44jqiW9z8oQ3Uk7sZX+KLQf61QJD/yqQ9dJ4fS8XD5mtj7WbrOQWHG1i
vnO6P1VYW3WQAIwo2IcWlDd6ezMOxba7XqUXeoapAHlifuiULWTlU4/KalBV
jKPqJTKC0rqjk2g5zKugUvPfXuXFIngcwpzQTpOcUD+Tz0o9aKUkAonTyWuF
wWRA9HOb9Xw+ZqIZhby98ahMu2WbOlWZYC6eTs4m309+YFm61J59V91B7zn1
dHct1sx8TdPuWTg0Rf1E8nqFUuzxkpo0cFEqxpWYnotYMAdF2LwM6al9xoQA
amkv+RtLDfEVB4i8Fm11GqSN/1TGDr0+WS0I43nYARpucX8WSp1xzj4PFmDc
SbCeZIGeFYFv9XI8iegbHiu4otderFz3KWaIOXZh18+l+xF4b58SXL8I6ZI6
fYsTzctYK0YFIVWc038K9R0iC2X9mpRhKiR+zdKZxoE0nKl5t/GrbTgLQniQ
K1g3IVMjpArWFqWL/SPCCEkFIavbofgrWOW2onA7krZVeJsNP2F9Ez/rBYur
e1K9+UhoAaiWPInSQos8xagAJWIv9Xcnb7gF+KkYNDyP6oT3gqySq+cwMTIF
gDXcgTM6y9D3LAp+v3VjORDzGvTDAXICimKT35ydqK/gfxMh3xsW10jvmOo8
Z/KIM3jmtfvyKWiHTaVdwdpXiSQU2YqoMtEAjN1pRwCdCkV0KKPCosOcJ89W
FWzNZcmxQ7W1+cFX6ax4odO3d3IjEnpRJI8xCvKIFyf/lKEYqswPhad7zOHW
Raz5QnZw6cHmHrGooupmiG+RZ8j0jG2MYzNgvRlaIXj+1xiJa1awoACxa4Nf
TkvHwPeZs54hwmDqUWrKJM89FHSFk3Ojlgy80qNzhgK8+58Wdqoai1FpXWhm
AzO8RsMvhhrOsC/Gote1uY7XpKSkTHEbnLbOR0NujfIlyzZRoE8soZtyRtZm
MC3o7Y36SS7ZG4J1KmH7ONWZKrrqQe/M/PEqk0VPy3Sl4Z9brV2vkVyRB6E6
cU/vMQ0ONuYGhnMapBoWKVfdwPwxoRorY2hWnTrxT6f1VxNcq2U1+fo8/psg
m3BvmmkPritr1QLvsltWtkOGrQomlbljV/F6lTWZf93GLYE/BqihdvKcBj80
CUwDYHrWsMeBql5xvmp4WTb9P6yzl+0UC90NOSm/zJdbq9byrdCOFYJRiR/W
i+a6HjHSO4V+Mb3YEYVPi3Jtt1ZJA+G4fbuBorABH6h96bO7WttRAx2sZa2s
ncceKExixWlkVosoyUHdVxtsSIzMq62Fx7THyJ7YxbDxVSytb1pofqdZq6yV
IFTGDa+5u5SDfFWkbKMNjg8fQmKbjnEPL6dvZ3+Ta3RnzaimSZFw+xXomLFa
fbrAw+Zwm2Lrpp5ROl3QyJ1aVUr53gjTLYspDWM9kpKAtwKt8opwT4KNyjCC
GYjhRutaTYGMxRGjPZBV2mk1N3+XP2RagNYMbMMILPWQ1jLo2SVa3nwSsqej
ycBGgOteIflVvkkfKNzJ6dYC6zBYlXm+PmkTgQnQSIwVRkvwj7V1+FUNYRqi
q23w48kurTb5Iiww4PhYtcZDutHuD9mixkj91ZMdPQRFBQzFrq/gE+Dijpfb
0VysimbfeWq16bnhaZXjdS/QQQjWZqNfTr9iZpFve1JKjnWktVyg3CL2rcG4
3XajmtH6c4JBjyqyu+d0eLw05FbuLzMcfUomQuT63lIlC2Uy1NfhRe/21PTS
pPBQDmn3RNGzRDVMqrYjByzfvHk7pjIFR7oi4d162rIEZGJD9RQpbQaFTzlg
Fwt6u7eEuKyoP8HU2+BWaq2P3J1i5tWEevVPYRPCV+ihMkucurwTYhCf7FNh
rQxMkM6fMH50RIve5oXBfQ85lgcD94niXlf7p/QOMx7MA8r7uaVUCrWaNiYV
gFflbx17n6vmsu4x8vAWKgaVeWs8i4Vgjcpzsy3gGjrAO+SqH7dOcmrSTGrm
UqRGRq9Nhdt0vd6+k+CPIGuFCAhhRcKzB5SL5xIQ3vcQ3D+MsV1bhpscA8pW
UnQVrYs+DGPONkFPdjkuph+ur6w2ng6WXfzvaAJWIMKjSSCPPa2bnmUy5NRR
wXK/s+w9uBars3CGewEmMZ04qXCtJfWCxr3bhGwS2rMOu3/3GjpenH8MC7Ak
FuP9kFVhJaFVhfovSAPAtQJDTcC6t1ZnwNLMbisroT4jbtw/kuZ6lNef1IMD
cbsQI8Nlc9tM+eTUNsY5CSS0V0+754mrzE2x6rJH1+UdNbxPjmi6/jRm1FYl
M351/UnO/mlZuiwsl9Z4YXiI0KhaHe842PB2n/tSTEtTaWiLJSpQHUxLDMH1
+yxLvrRIsFVdqwcKYdR/Dw9APsjzlyugzclcVNwF6qJz6fxiEL7ebqhkW4RS
Vpg2oU/AEz3e0hr12xbB4G8rK7SMSsJWhltlkZpPseS2xlGStQZh7NEmJ1Iy
LmoOasmYHeZF6ynyyyJWT3DKMqdKLBpfhDoQ7Ig+IIIv37VN12qgQilO5Hwl
2jR/m6JZ8iRfI2hpeQqTK4uwKebX3FSNekHzZ6jPnjfQofOLcq1bMwxx7LNr
klIDuPbaDDsQ2ARCx+t0JyqLgUU1yU/MWrm+XTCk2DUsxdFa4ETIWovXhs43
KL04vMLy+iSWZRS32YYKPuoSKcRQVCgKvOmTyPlUlFaNoyDhYfKHKYi03r0V
Q8zZXUmZlX4BFw2GAKpSEIV+fnF8/fbjNJZUDg4smTMbTVknuoGQcm3RTSkt
MMyVDCqXqxRllzmEMaDvyLluLNaowW0sinQTVBFdypY1MZ68Sjq8Ru6MiQX5
6k2Ys56UW2qsA1Z6d9hAqqFoVwIhrIeuaWo8cF/Y3S8s0zBFQDPIL3TX828w
aecxf4r2wSKWqxZKRkWZFEUQqtKYEKFGGN09YbKOYkDcV3eNRx7XkPBF9hla
d1XDAPA/YpETL22J1Jm+DWVZmIiXsAhYjAfgluzUrB0aKsMbmmZ1xDpEin/x
pmV9Ie/bPajO54Fhdk05PDg3L37ccye99LjyTPsRD9QPDd5lkTwPDxSeYjSB
L4XSx4hn0d0XmioknuDgP+8TidLoxDwzj2n6tRFAiSaievu9UymqNdW7rT/C
FQrkAAQuDEXKyyUBavtKCvv25ho7ZJ4wE6WCn92pMtGoqEkYSJvuLQL0B2fh
nmzAx9lmCKPNt0CnJFgPD+IgSOU4O2/JGC9E6F6zpWezNw90yko9GWzCGzJ2
0Qy03cqy0oJfbo1EfqtsJYUpTJ5FNuSsEOrd3dNRsJb317OMYEx513F/CKs6
KSvztkgeYjWqYR+vBNxEoTUQX1q5uVf9OPVK9MCJbCBpEvztx4ThhNSE1BK1
+u3DzuJOCCk6QMd1BT9YTHUIQ02V/w25oxhSVnyyXvfrksVqM87hdoEa91rN
P6FgKjuPBtAg9zKpLW+h+INpEvqqhP48v0JHba3Eru1E8PWr/evF7JMUTl20
6uqeH8Vqlb39Ul+z9lYo10yIZEHSeu5WPRcYOFKc3pIWaWAgzo/SnAoVg7C/
O6/wv10zk4KqT3CD+x6+ufhkOobZfzItC0WZo0rM2bR8tvrHdhU6uO4Rt9pS
fRRWERLiPTppjroidSGR4HLL6O+UJ3prjZAKlylsQq9/63iTUJyY/Xtb5Gvj
yKgRa8Z2FgqXRw0TCGXtkMySq5ELK4eiWiQiZmDyKnJSHbpaF21bAGokF/kP
wrfpS2pDuHCQyhyuLmeMALcxkwSa0uNXlmy/2rZWgK3kFQHF1yHg/0wfq0Qz
WUB7W0+ShDYreGUVCng72b+CjfhkX8v880Sb1aMq9bd6ooacezENQnbIG9JR
gj/68t1yfksT4Ajt1qexoal/JXlYfSlc27TXusMDU0eT7OOvv1xnZydnJ/Sb
WY2TL18+vHmHYu2pTXELcGsoGfusNrE/kOHlpqEXa1NjLa8bELMKyvFqJTws
swW8y/fu2U5oqMJdFZ3HGi2rPRzmeAz3ykQAw74uUmplFhwyGCYzGkIEJMWM
SN4B2aTkHhR16q8ygkxykuCIuHwfuoWHRh19FRTxkZ1OIF2NfWw9rtdVa8ux
eJNsa5kUaO4jkVWd1rZBPmSsshrStzSRhjoNmj6HSyY32zWc2BXmrjL7XbQN
U7mCPtRvbsWlWdxMwVMqp1S7CAoOrwkbtoRx++OElilarVf2nuobYFx6lXNr
a4AaD/TnLaM+R7OAFeCSav9J6fOF1uael97Fvhi8nQ7bgY9M9XFPmgcQV+j3
WOg27LInF32AZDs8+JVeMMbZRtcffkWqrOMyDXCgHCcGI/ue6r37N4BUJymr
UDW3XW2ayfJpz+lqHVyroEFlMWm4V6ENgnebCimWE3phPOqsd8vEuJbqs9Ac
lAGtFO8Gv1uGOLtec6/EXvFxw5i/g2uGzlqA3AMZtl2V7cCl9nmtSbAwwNb9
uEjsqbKyrpnRtBoR8HlrgTm9Zt4BUehKlCUGAsbuF4mau3qEZEV29cNdtooN
eTRwx2Fn3CQ0yHZHXFSnLUJrmwjofEfhVMXCKsxrcCGaU8n2Dty2pbwIFBWM
o4D8HZwRD/Gv3vFL3diHB+axSJTcWfb22RbolA4jNQlSLX0aFP2xpmKEbZgj
PerBDIz+1KMItoBKEkHVPENq4J8A6SUmm1rVeOxxE+jOvO9BG1fTKlGQlZCK
VFH2qH9ASDDGP8zpTNpk8iBZ+jZkrEIgNU9evQaVzJPFRBW4rDrWnmohiGQ2
hVh6hOre1cxVzGpFllEhV5S06u7tQr6foMc/nEX4QpqoZhqpEotNN8nUr3mT
WVSIUg81fyuFl1gPJMUa/BcvMK+ZmqEi5iBTc2I9CIQgg6/huX4PHrezjkhJ
Pj+CdTbVv7wnXPfYW29llxc37+S3Vj+UsUQvMx8ieztE7HfZZCuuS6MS2lfP
oFxvB+C3i2GXhGLSPp6HB/vLrwLa4y7r/RYei1qEekQjFJkZ/6NwC+rglznf
FadG7PSOVnZ89FYkFgTTkUUQ9kwlMIbR1R/eKIifnXuCyeuomn5APqoddlGu
S5FS2PvzXnnZEFov6sWWvuZ79l4ClkKf75ejzUbCB/9Xa4ObXb7++Pr3Dshn
B7VtrULvAiJhidosK23EiyFyhAJwm/6PPP9cP2TXsMiseBQwMY4eiYGYDi0e
8UBkMnzD/w9GWGFBBOsAAA==

-->

</rfc>

