<?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.2.13 --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-mpls-rfc6374-sfl-10" category="std"> number="9571" obsoletes="" updates=""
submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"
sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <front>
    <title abbrev="RFC6374-SFL">RFC6374 abbrev="SFL">Extension of RFC 6374-Based Performance Measurement Using Synonymous Flow Labels</title>
    <seriesInfo name="RFC" value="9571"/>
    <author initials="S." surname="Bryant (Ed)" surname="Bryant" fullname="Stewart Bryant"> Bryant" role="editor">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author initials="G." surname="Swallow" fullname="George Swallow">
      <organization>Southend Technical Center</organization>
      <address>
        <email>swallow.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="Chen" fullname="Mach fullname="Mach(Guoyi) Chen">
      <organization>Huawei</organization>
      <address>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>
    <author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
      <organization>Huawei Technologies</organization>
      <address>
        <email>giuseppe.fioccola@huawei.com</email>
      </address>
    </author>
    <author initials="G." surname="Mirsky" fullname="Gregory Mirsky">
      <organization>ZTE Corp.</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="March" day="05"/>

    <workgroup>MPLS Working Group</workgroup> year="2024" month="May"/>
    <workgroup>MPLS</workgroup>

    <keyword>Performance Measurement</keyword>
    <keyword>OAM</keyword>

    <abstract>
      <t>RFC 6374 describes methods of making loss and delay measurements on
      Label Switched Paths (LSPs) primarily as they are used in MPLS Transport
      Profile (MPLS-TP) networks.  This document describes a method of
      extending RFC 6374 the performance measurements (specified in RFC 6374) from
      flows carried over MPLS-TP to flows carried over generic MPLS LSPs.  In
      particular, it extends the technique to allow loss and delay
      measurements to be made on multi-point to point multipoint-to-point LSPs and introduces some
      additional techniques to allow more sophisticated measurements to be
      made in both MPLS-TP and generic MPLS networks.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC6374"/> target="RFC6374" format="default"/> was originally designed for use as an Operations, Administration, and
Maintenance (OAM) protocol
for use with MPLS Transport Profile (MPLS-TP) <xref target="RFC5921"/> target="RFC5921" format="default"/> LSPs. MPLS-TP only
supports point-to-point and point-to-multi-point point-to-multipoint LSPs. This document describes
how to use RFC6374 <xref target="RFC6374" format="default"/> in the generic MPLS case, case and also introduces a number
of more sophisticated measurements of applicability to both cases.</t>
      <t><xref target="RFC8372"/> target="RFC8372" format="default"/> describes the requirement for introducing
flow identities when using RFC6374 <xref target="RFC6374"/> packet Loss Measurements
(LM). loss measurements described in <xref target="RFC6374" format="default"/>.

In summary RFC6374 uses summary, <xref target="RFC6374" format="default"/> describes use of the loss-measurement loss measurement (LM) packet message as the
packet accounting
demarcation point.  Unfortunately Unfortunately, this gives rise to a number of
problems that may lead to significant packet accounting errors in
certain situations.  For example:</t>

<t><list style="numbers">
  <t>Where
      <ol spacing="normal" type="1"><li>Where a flow is subjected to Equal Cost Multi-Path Equal-Cost Multipath (ECMP)
treatment
treatment, packets can arrive out of order with respect to the LM
packet.</t>
  <t>Where
packet.</li>
        <li>Where a flow is subjected to ECMP treatment, packets can arrive
at different hardware interfaces, thus requiring reception of an
LM packet on one interface to trigger a packet accounting action
on a different interface which that may not be co-located with it.
This is a difficult technical problem to address with the
required degree of accuracy.</t>
  <t>Even accuracy.</li>
        <li>Even where there is no ECMP (for example example, on RSVP-TE, MPLS-TP LSPs LSPs,
and pseudowires(PWs)) pseudowires (PWs)), local processing may be distributed over a number of
processor cores, leading to synchronization problems.</t>
  <t>Link problems.</li>
        <li>Link aggregation techniques <xref target="RFC7190"/> target="RFC7190" format="default"/> may also lead to synchronization
issues.</t>
  <t>Some
issues.</li>
        <li>Some forwarder implementations have a long pipeline between
processing a packet and incrementing the associated counter, again
leading to synchronization difficulties.</t>
</list></t> difficulties.</li>
      </ol>

      <t>An approach to mitigating these synchronization issue issues is described in
<xref target="RFC8321"/> in which target="RFC9341" format="default"/> -- the packets are
batched by the sender sender, and each batch is marked in some way such that
adjacent batches can be easily recognized by the receiver.</t>
      <t>An additional problem arises where the LSP is a multi-point to point
LSP, multipoint-to-point
LSP since MPLS does not include a source address in the packet.
Network management operations require the measurement of packet loss
between a source and destination.  It is thus necessary to introduce
some source specific source-specific information into the packet to identify packet
batches from a specific source.</t>
      <t><xref target="RFC8957"/> target="RFC8957" format="default"/> describes a method of encoding per flow per-flow
instructions in an MPLS label stack using a technique called
Synonymous Flow Labels (SFL) (SFLs), in which labels which that mimic the
behavior of other labels provide the packet batch identifiers and
enable the per batch per-batch packet accounting.  This memo specifies how SFLs
are used to perform RFC6374 packet loss and RFC6374 delay measurements.</t> measurements as described in <xref target="RFC6374" format="default"/>.</t>
<t>
  When the terms "performance measurement method," "Query," "packet," or "message" are used in this document,
  they refer to a performance measurement method, Query, packet, or message as specified in <xref
  target="RFC6374"/>.  </t> </section> <section anchor="requirements-language" title="Requirements Language">

<t>The
  numbered="true" toc="default"> <name>Requirements Language</name>
        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
“OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section anchor="rfc6374-packet-loss-measurement-with-sfl" title="RFC6374 Packet numbered="true" toc="default">
      <name>Packet Loss Measurement with SFL"> Using SFL</name>
      <t>The data service packets of the flow being instrumented are grouped
into batches, and all the packets within a batch are marked with
the SFL <xref target="RFC8372"/> target="RFC8372" format="default"/> corresponding to that batch.
The sender counts the number of packets in the batch. When the
batch has completed and the sender is confident that all of the
packets in that batch will have been received, the sender issues
an RFC6374
a Query message to determine the number actually
received and hence the number of packets lost. The RFC6374
Query message is sent using the same SFL as the corresponding batch of
data service packets. The format of the Query and Response packets is
described in <xref target="RFC6374SFL"/>.</t> target="sec-RFC6374SFL" format="default"/>.</t>
    </section>
    <section anchor="SPD" title="RFC6374 Single numbered="true" toc="default">
      <name>Single Packet Delay Measurement">

<t>RFC6374 Measurement Using SFL</name>
      <t><xref target="RFC6374" format="default"/> describes how to measure the packet delay by measuring the
transit time of an RFC6374 a packet over an LSP. Such a packet may not
need to be carried over an SFL since the delay over a particular LSP
should be a function of the Traffic Class (TC) bits.</t>
      <t>However, where SFLs are being used to monitor packet loss or where
label inferred
label-inferred scheduling is used <xref target="RFC3270"/> target="RFC3270" format="default"/>, then
the SFL would be REQUIRED <bcp14>REQUIRED</bcp14> to ensure that the RFC6374 packet
which
that was being used as a proxy for a data service packet experienced
a representative delay. The format of an
RFC6374 a packet carried over the LSP using an SFL is shown in <xref target="RFC6374SFL"/>.</t> target="sec-RFC6374SFL" format="default"/>.</t>
    </section>
    <section anchor="data-service-packet-delay-measurement" title="Data numbered="true" toc="default">
      <name>Data Service Packet Delay Measurement"> Measurement</name>
      <t>Where it is desired to more thoroughly instrument a packet flow and to
determine the delay of a number of packets packets, it is undesirable to
send a large number of RFC6374 packets acting as a proxy data service
packets (see <xref target="SPD"/>). target="SPD" format="default"/>). A method of directly measuring the delay characteristics
of a batch of packets is therefore needed.</t>
      <t>Given the long intervals over which it is necessary to measure packet
loss, it is not necessarily the case that the batch times for the two
measurement types would be identical. Thus, we use a technique that
permits the two measurements are to be made concurrently and yet relatively
independent
independently from each other. The notion that they are relatively
independent arises from the potential for the two batches to overlap in time,
in which case either the delay batch time will need to be cut short or the loss
time will need to be extended to allow correct reconciliation of the
various counters.</t>
<t>The problem is illustrated in <xref target="FIGDM"/> below:</t> target="fig1"/>.</t>

<figure title="RFC6734 Query anchor="fig1">
<name>Query Packet with SFL" anchor="FIGDM"><artwork><![CDATA[
   (1) SFL</name>
<artwork>
(Case 1)  AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB

          SFL Marking marking of a packet batch for loss measurement

   (2)

(Case 2)  AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB

          SFL Marking marking of a subset of the packets for delay

   (3)

(Case 3)  AAAAAAAADDDDBBBBBBBBAAAAAAAAAABBBBBBBBBB

          SFL Marking marking of a subset of the packets across a packet loss
          measurement boundary

   (4)

(Case 4)  AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB

   The

          A case of multiple delay measurements within a packet loss
          measurement

where
   A & and B are packets where loss is being measured measured.
   C & and D are pacekts packets where loss and delay are being measured.
</artwork></figure>

<!-- Alternative format, if artwork is not preferred.
<ul spacing="compact" empty="true">
  <li>A and B are packets where loss is being measured
]]></artwork></figure>

<t>In measured.</li>
  <li>C and D are packets where loss and delay are being measured.</li>
</ul>
<ol type="(Case %d)" anchor="list1">
<li anchor="case1">
<t>AAAAAAAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB</t>
<t>SFL marking of a packet batch for loss measurement</t>
</li>

<li anchor="case2">
<t>AADDDDAAAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB</t>
<t>SFL marking of a subset of the packets for delay</t>
</li>

<li anchor="case3">
<t>AAAAAAAADDDDBBBBBBBBAAAAAAAAAABBBBBBBBBB</t>
<t>SFL marking of a subset of the packets across a packet loss measurement boundary</t>
</li>

<li anchor="case4">
<t>AACDCDCDAABBBBBBBBBBAAAAAAAAAABBBBBBBBBB</t>
<t>A case 1 of <xref target="FIGDM"/> multiple delay measurements within a packet loss measurement</t>
</li>
</ol>
-->
      <t>In Case 1, we show the case where loss measurement alone
is being carried out on the flow under analysis. For illustrative
purposes
purposes, consider that 10 packets are used in each flow in the
time interval being analyzed.</t>
      <t>Now consider case 2 of <xref target="FIGDM"/> Case 2, where a small batch of
packets need to be analyzed for delay. These are marked with a different
SFL type type, indicating that they are to be monitored for both loss
and delay. The SFL=A indicates loss batch A, and SFL=D indicates a batch
of packets that are to be instrumented for delay, but SFL D is
synonymous with SFL A, which in turn is synonymous with the underlying
Forwarding Equivalence Class (FEC). Thus, a packet marked D "D" will be accumulated into the A loss
batch, into the delay statistics statistics, and will be forwarded as normal.
Whether the packet is actually counted twice (for loss and delay)
or whether the two counters are reconciled during reporting is
a local matter.</t>
      <t>Now consider case 3 of <xref target="FIGDM"/> Case 3, where a small batch of packets
are
is marked for delay across a loss batch boundary. These packets
need to be considered as a part of batch A or a part of batch B, and
any RFC6374 Query needs to take place after all the packets
A or D (whichever option is chosen) have arrived at the receiving LSR.</t> Label Switching Router (LSR).</t>
      <t>Now consider case 4 of <xref target="FIGDM"/>. Here Case 4. Here, we have a case where
it is required to take a number of delay measurements within
a batch of packets that we are measuring for loss. To do this this,
we need two SFLs for delay (C and D) and alternate between
them (on a delay batch by delay batch delay-batch-by-delay-batch basis) for the purposes of
measuring the delay characteristics of the different batches of packets.</t>
    </section>
    <section anchor="some-simplifying-rules" title="Some numbered="true" toc="default">
      <name>Some Simplifying Rules"> Rules</name>
      <t>It is possible to construct a large set of overlapping measurement
types,
types in terms of loss, delay, loss and delay delay, and batch overlap. If
we allow all combinations of cases, this leads to configuration,
testing
testing, and implementation complexity and hence and, hence, increased costs.
The following simplifying rules represent the
default case:</t>

<t><list style="numbers">
  <t>Any
      <ol spacing="normal" type="1"><li>Any system that needs to measure delay MUST <bcp14>MUST</bcp14> be able to
measure loss.</t>
  <t>Any loss.</li>
        <li>Any system that is to measure delay MUST <bcp14>MUST</bcp14> be configured to
measure loss. Whether the loss statistics are collected
or not is a local matter.</t>
  <t>A matter.</li>
        <li>A delay measurement MAY <bcp14>MAY</bcp14> start at any point during a loss measurement
batch, subject to rule 4.</t>
  <t>A 4.</li>
        <li>A delay measurement interval MUST <bcp14>MUST</bcp14> be short enough that it
will complete before the enclosing loss batch completes.</t>
  <t>The completes.</li>
        <li>The duration of a second delay batch (D in <xref target="FIGDM"/> batch target="fig1"/>) must be such
that all packets from the packets belonging to a first
delay batch (C in <xref target="FIGDM"/>)will target="fig1"/>) will have been received before
the second delay batch completes. This condition is satisfied
when the time to send a batch is long compared to the network
propagation time, time and is a parameter that can be established
by the network operator.</t>
</list></t> operator.</li>
      </ol>
      <t>Given that the sender controls both the start and duration of
a loss and a delay packet batch, these rules are readily implemented
in the control plane.</t>
    </section>
    <section anchor="multiple-packet-delay-characteristics" title="Multiple numbered="true" toc="default">
      <name>Multiple Packet Delay Characteristics"> Characteristics</name>
      <t>A number of methods are described which that add to the set of measurements
originally specified in <xref target="RFC6374"/>. target="RFC6374" format="default"/>. Each of these methods has different
characteristics and different processing demands on the packet forwarder.
The choice of method will depend on the type of diagnostic that the operator seeks.</t>
      <t>Three Methods methods are discussed:</t>

<t><list style="numbers">
  <t>Time Buckets</t>
  <t>Classic
      <ol spacing="normal" type="1"><li>Time Buckets</li>
        <li>Classic Standard Deviation</t>
  <t>Average Delay</t>
</list></t> Deviation</li>
        <li>Average Delay</li>
      </ol>
      <section anchor="method-1-time-buckets" title="Method numbered="true" toc="default">
        <name>Method 1: Time Buckets"> Buckets</name>

  <t>In this method method, the receiving LSR measures the inter-packet gap, classifies the
  delay into a number of delay buckets buckets, and records the number of packets
  in each bucket.
  As an example, if the operator were concerned about packets with a delay of
  up to 1us, 2us, 4us, 8us, 1 μs, 2 μs, 4 μs, 8 μs, and over 8us 8 μs, then there would be five buckets
  buckets, and packets that arrived up to 1us 1 μs would cause the 1us "up to 1 μs"
  bucket counter to increase, increase.  Likewise, for those that arrived between 1us 1 μs and 2us 2 μs, the 2us "2 μs" bucket counter would increase increase, etc. In practice practice, it
  might be better in terms of processing and potential parallelism if, if both the "up to 1 μs" and "2 μs" counters were incremented when a packet had
a delay relative to its predecessor of 2us, then  both the up to 1us and the 2us counter
were incremented, 2 μs, and any more detailed information was calculated in the analytics
system.</t>
        <t>This method allows the operator to see more structure in the jitter characteristics
than simply measuring the average jitter, jitter and avoids the complication of needing
to perform a per packet multiply, per-packet multiply but will probably need the time intervals between
buckets to be programmable by the operator.</t>
        <t>The packet format of a Time Bucket Jitter Measurement Message message
is shown below:</t>

        <figure title="Time anchor="FIGBucket">
          <name>Time Bucket Jitter Measurement Message Format" anchor="FIGBucket"><artwork><![CDATA[ Format</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags |  Control Code |        Message Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  QTF  |  RTF  | RPTF  |              Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session Identifier          |    DS     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of     |      Reserved 1                               |
| Buckets       |                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Interval in 10ns units (in 10 ns units)                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Number pkts of Pkts in Bucket 1                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Number of Pkts in Bucket N                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
~                           TLV Block                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF, Querier Timestamp Format (QTF), Responder Timestamp Format (RTF), Responder's Preferred Timestamp Format (RPTF),
Session Identifier, Reserved Reserved, and DS Fields Differentiated Services (DS) fields are as defined in section 3.2
of RFC6374. <xref target="RFC6374" sectionFormat="of" section="3.2"/>. The remaining fields, which are unsigned integers, are as follows:</t>

<figure><artwork><![CDATA[
o Number
<ul empty="false">
<li>Number of Buckets in the measurement

o Reserved measurement.</li>

<li>Reserved 1 must be sent as zero and ignored on receipt

o Interval in 10ns units receipt.</li>

<li>Interval (in 10 ns units) is the inter-packet interval for
  this bucket

o Number bucket.</li>

<li>Number of Pkts in Bucket 1 is the number of packets found in
  this bucket.
]]></artwork></figure>
  the first bucket.</li>
<li>Number of Pkts in Bucket N is the number of packets found in
  the Nth bucket, where N is the value in the Number of Buckets field.</li>
</ul>
        <t>There will be a number of Interval/Number pairs depending on the
number of buckets being specified by the Querier. If an RFC6374 a message is being used to configure the buckets, (i.e. buckets (i.e., the responder
is creating or modifying the buckets according to the intervals in
the Query message), then the Responder
MUST responder
<bcp14>MUST</bcp14> respond with 0 packets in each bucket until it has been
configured for a full measurement period. This indicates that it was configured
at the time of the last response message, and thus thus, the response
is valid for the whole interval.

As per the <xref target="RFC6374"/> convention in <xref target="RFC6374" format="default"/>,
the Number of pkts Pkts in Bucket fields are included in the Query message and set
to zero.</t>

<t>Out of band
        <t>Out-of-band configuration is permitted by this mode of operation.</t>
        <t>Note this is a departure from the normal fixed format used in
RFC6374.</t>
<xref target="RFC6374" format="default"/>.</t>
        <t>The time bucket jitter measurement Time Bucket Jitter Measurement message is carried over an LSP in the way described in
<xref target="RFC6374"/> target="RFC6374" format="default"/> and over an LSP with an SFL as described in <xref target="RFC6374SFL"/>.</t> target="sec-RFC6374SFL" format="default"/>.</t>
      </section>
      <section anchor="method-2-classic-standard-deviation" title="Method 2 numbered="true" toc="default">
        <name>Method 2: Classic Standard Deviation"> Deviation</name>
        <t>In this method, provision is made for reporting the following delay
characteristics:</t>

<t><list style="numbers">
  <t>Number
        <ol spacing="normal" type="1"><li>Number of packets in the batch (n).</t>
  <t>Sum (n)</li>
          <li>Sum of delays in a batch (S)</t>
  <t>Maximum Delay.</t>
  <t>Minimum Delay.</t>
  <t>Sum (S)</li>
          <li>Maximum delay</li>
          <li>Minimum delay</li>
          <li>Sum of squares of Inter-packet inter-packet delay (SS).</t>
</list></t> (SS)</li>
        </ol>
        <t>Characteristics 1 and 2 give the mean delay. Measuring the delay of each
pair in the batch is discussed in <xref target="PPDM"/>.</t> target="PPDM" format="default"/>.</t>
        <t>Characteristics 3 and 4 give the outliers.</t>
        <t>Characteristics 1, 2 2, and 5 can be used to calculate the variance of the
inter-packet gap and gap, hence the standard deviation giving a view of
the distribution of packet delays and hence the jitter. The equation
for the variance (var) is given by:</t>

<figure><artwork><![CDATA[
<artwork><![CDATA[
var = (SS - S*S/n)/(n-1)
]]></artwork></figure>
]]></artwork>

        <t>There is some concern over the use of this algorithm for measuring
variance,
variance because SS and S*S/n can be similar numbers, particularly
where variance is low. However However, the method commends is acceptable because it self by does
not
requiring require a division in the hardware.</t>
        <section anchor="multi-packet-delay-measurement-message-format" title="Multi-Packet numbered="true" toc="default">
          <name>Multi-packet Delay Measurement Message Format"> Format</name>
          <t>The packet format of a  Multi-Packet  Multi-packet Delay Measurement Message message
is shown below:</t>
          <figure title="Multi-packet anchor="FIGMPM">
            <name>Multi-packet Delay Measurement Message Format" anchor="FIGMPM"><artwork><![CDATA[ Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags |  Control Code |        Message Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  QTF  |  RTF  | RPTF  |              Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session Identifier          |    DS     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number of Packets                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Sum of Delays for Batch                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Minimum Delay                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Maximum Delay                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Sum of squares of Inter-packet delay           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
~                           TLV Block                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
]]></artwork>
          </figure>
          <t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
Session Identifier, Reserved Reserved, and DS Fields fields are as defined in section 3.2
of RFC6374. <xref target="RFC6374" sectionFormat="of" section="3.2"/>. The remaining fields are as follows:</t>

<figure><artwork><![CDATA[
o Number
<ul empty="false">
<li>Number of Packets is the number of packets in this batch

o Sum batch.</li>

<li>Sum of Delays for Batch is the duration of the batch in the
  time measurement format specified in the RTF field.

o Minimum field.</li>

<li>Minimum Delay is the minimum inter-packet gap observed during
  the batch in the time format specified in the RTF field.

o Maximum field.</li>

<li>Maximum Delay is the maximum inter-packet gap observed during
  the batch in the time format specified in the RTF field.
]]></artwork></figure> field.</li>
</ul>
          <t>The multi-packet delay measurement Multi-packet Delay Measurement message is carried over an LSP in the way described in
<xref target="RFC6374"/> target="RFC6374" format="default"/> and over an LSP with an SFL as described in <xref target="RFC6374SFL"/>.</t> target="sec-RFC6374SFL" format="default"/>.</t>
        </section>
      </section>
      <section anchor="PPDM" title="Per Packet numbered="true" toc="default">
        <name>Per-Packet Delay Measurement"> Measurement</name>
        <t>If detailed packet delay measurement is required required, then it might be
possible to record the inter-packet gap for each packet pair.
   In cases other than exception cases the exceptions of slow flows or small batch sizes,
   this would create a large (per packet) (per-packet) demand on storage in the
   instrumentation system, a large bandwidth to for such a storage system and
   large bandwidth to for the analytics system.
Such a measurement technique is outside the scope of this document.</t>
      </section>
      <section anchor="average-delay" title="Average Delay"> numbered="true" toc="default">
        <name>Average Delay</name>
        <t>Introduced in <xref target="RFC8321"/> target="RFC9341" format="default"/> is the concept of a one
way one-way delay measurement in which the average time of arrival of a
set of packets is measured. In this approach approach, the packet is time-stamped timestamped
at arrival arrival, and the Responder responder returns the sum of the time-stamps timestamps
and the number of times-tamps. timestamps. From this this, the analytics engine can
determine the mean delay. An alternative model is that the Responder responder
returns the time stamp timestamp of the first and last packet and the
number of packets. This later latter method has the advantage of allowing the
average delay to be determined at a number of points along the
packet path and allowing the components of the delay to be
characterized. Unless specifically configured otherwise, the
responder may return either or both types of response response, and
the analytics engine should process the response appropriately.</t>
        <t>The packet format of an Average Delay Measurement Message message
is shown below:</t>
        <figure title="Average anchor="FIGAD">
          <name>Average Delay Measurement Message Format" anchor="FIGAD"><artwork><![CDATA[ Format</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags |  Control Code |        Message Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  QTF  |  RTF  | RPTF  |              Reserved                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Session Identifier          |    DS     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Number of Packets                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Time of First Packet                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Time of Last Packet                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Sum of Timestamps of Batch                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

~                                                               ~
~                           TLV Block                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>The Version, Flags, Control Code, Message Length, QTF, RTF, RPTF,
Session Identifier, and DS Fields fields are as defined in section 3.2
of RFC6374. <xref target="RFC6374" sectionFormat="of" section="3.2"/>. The remaining fields are as follows:</t>

<figure><artwork><![CDATA[
o Number
<ul empty="false">
<li>Number of Packets is the number of packets in this batch.

o Time batch.</li>

<li>Time of First Packet is the time of arrival of the first
  packet in the batch.

o Time batch.</li>

<li>Time of Last Packet is the time of arrival of the last
  packet in the batch.

o Sum batch.</li>

<li>Sum of Timestamps of Batch.
]]></artwork></figure> Batch.</li>
</ul>
        <t>The average delay measurement Average Delay Measurement message
is carried over an LSP in the way described in
<xref target="RFC6374"/> target="RFC6374" format="default"/> and over an LSP with an SFL as described in <xref target="RFC6374SFL"/>. target="sec-RFC6374SFL" format="default"/>.
As is the convention with RFC6374, <xref target="RFC6374" format="default"/>, the Query message contains placeholders
for the Response message. The placeholders are sent as zero.</t>
      </section>
    </section>
    <section anchor="sampled-measurement" title="Sampled Measurement"> numbered="true" toc="default">
      <name>Sampled Measurement</name>
      <t>In the discussion so far far, it has been assumed that we would measure
the delay characteristics of every packet in a delay measurement
interval defined by an SFL of constant color.
In <xref target="RFC8321"/> target="RFC9341" format="default"/>, the concept of a sampled
measurement is considered. That is is, the Responder responder only measures a packet
at the start of a group of packets being marked for delay measurement
by a particular color, rather than every packet in the marked batch.
A measurement
interval is not defined by the duration of a marked batch of packets
but the interval between a pair of RFC6374 packets taking a readout
of the delay characteristic. This approach has the advantage that
the measurement is not impacted by ECMP effects.</t>
      <t>This sampled approach may be used if supported by the Responder responder and
configured by the opertor.</t> operator.</t>
    </section>
    <section anchor="RFC6374SFL" title="Carrying RFC6374 anchor="sec-RFC6374SFL" numbered="true" toc="default">
      <name>Carrying Packets over an LSP using Using an SFL"> SFL</name>
      <t>We illustrate the packet format of an RFC6374 a Query message using SFLs
for the case of an MPLS direct loss measurement Direct Loss Measurement in
<xref target="Figure1"/>.</t> target="Figure1" format="default"/>.</t>
      <figure title="RFC6734 Query anchor="Figure1">
        <name>Query Packet with SFL" anchor="Figure1"><artwork><![CDATA[ SFL</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------------------+
|                               |
|             LSP               |
|            Label              |
+-------------------------------+
|                               |
|        Synonymous Flow        |
|            Label              |
+-------------------------------+
|                               |
|            GAL                |
|                               |
+-------------------------------+
|                               |
|      ACH Type = 0xA           |
|                               |
+-------------------------------+
|                               |
|  RFC6374      Measurement Message      |
|                               |
|  +-------------------------+  |
|  |                         |  |
|  |      Fixed-format       |  |
|  |      portion of msg     |  |
|  |                         |  |
|  +-------------------------+  |
|  |                         |  |
|  |      Optional SFL TLV   |  |
|  |                         |  |
|  +-------------------------+  |
|  |                         |  |
|  |      Optional Return    |  |
|  |      Information        |  |
|  |                         |  |
|  +-------------------------+  |
|                               |
+-------------------------------+
]]></artwork></figure>
]]></artwork>
      </figure>
      <t>The MPLS label stack is exactly the same as that used for the user
data service packets being instrumented except for the inclusion
of the Generic Associated Channel Label (GAL) <xref target="RFC5586"/> target="RFC5586" format="default"/> to allow the receiver to distinguish between
normal data packets and OAM packets. Since the packet loss
measurements are being made on the data service packets,
an RFC6374 direct loss measurement MPLS Direct Loss Measurement is being made,
and
which is indicated by the type field in the ACH Associated Channel Header (ACH) (Type = 0x000A).</t>

      <t>The RFC6374 measurement message consists of the up to three components,
the RFC6374 components as follows.</t>
      <ul>
	<li>
	  <t>The fixed-format portion of the message as specified in <xref target="RFC6374"/> is carried over the ACH
	  channel. The ACH channel type specified specifies the type of measurement
	  being made (currently: loss, delay delay, or loss and delay) as specified in RFC6374.</t>

<t>Two optional TLVs MAY also be carried if needed. delay).</t>
	</li>
	<li>
	  <t>(Optional) The first is the SFL TLV specified in <xref target="sfltlv"/>.  This target="sfltlv"
	  format="default"/> <bcp14>MAY</bcp14> be carried if needed. It is
	  used to provide the implementation with a reminder of the SFL that
	  was used to carry the
RFC6374 message.  This is needed because a number of
	  MPLS implementations do not provide the MPLS label stack to the MPLS
	  OAM handler.  This TLV is required if RFC6374 messages are sent over UDP
	  <xref target="RFC7876"/>. target="RFC7876" format="default"/>.  This TLV MUST
	  <bcp14>MUST</bcp14> be included unless, by some method outside the
	  scope of this document, it is known that this information is not
	  needed by the RFC6374 Responder.</t>

<t>The second set of information that may responder.</t>
      </li>
      <li>
	<t>(Optional) The Return Information <bcp14>MAY</bcp14> be needed is the return
information that carried if
	needed. It allows the responder send the RFC6374 response to the Querier.  This is not needed if the
	response is requested in-band in band and the MPLS construct being measured is
	a point to point point-to-point LSP, but it otherwise MUST <bcp14>MUST</bcp14> be carried.
	The return address Return Address TLV is defined in <xref target="RFC6374"/> target="RFC6374"
	format="default"/>, and the optional UDP Return Object is defined in
	<xref target="RFC7876"/>.</t> target="RFC7876" format="default"/>.</t>
      </li>
    </ul>
      <t>Where a measurement other than an MPLS direct loss measurement Direct Loss Measurement is to be
made, the appropriate RFC6374 measurement message is used (for example, one of the
new types defined in this document) document), and this is indicated to the receiver
by the use of the corresponding ACH type.</t>
      <section anchor="sfltlv" title="RFC6374 numbered="true" toc="default">
        <name>Extending RFC 6374 with SFL TLV"> TLV</name>
        <t>The RFC6374 <xref target="RFC6374" format="default"/> SFL TLV is shown in <xref target="Figure2"/>. target="Figure2" format="default"/>.
   This contains the SFL that was carried in the label stack, the FEC that was
   used to allocate the SFL SFL, and the index into (into the batch of SLs SFLs that were
   allocated for the FEC FEC) that corresponds to this SFL.</t>

        <figure title="SFL TLV" anchor="Figure2"><artwork><![CDATA[ anchor="Figure2">
          <name>SFL TLV</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type       |    Length     |MBZ| SFL Batch |    SFL Index  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 SFL                   |        Reserved       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 FEC                                           |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
]]></artwork>
        </figure>
        <t>Where:</t>

<figure><artwork><![CDATA[
Type      Type is set
<dl indent="15">
<dt>Type</dt><dd>      Set to Synonymous Flow Label (SFL-TLV).

Length (SFL-TLV).</dd>

<dt>Length</dt><dd>    The length of the TLV is as specified in RFC6374.

MBZ       MUST <xref target="RFC6374"/>.</dd>

<dt>MBZ</dt><dd>       <bcp14>MUST</bcp14> be sent as zero and ignored on receive.

SFL Batch The SFL batch that this SFL was allocated as part receive.</dd>

<dt>SFL Batch</dt><dd> An identifier for a collection of see [I-D.bryant-mpls-sfl-control]

SPL Index The SFLs grouped together for management and control purposes. </dd>

<dt>SFL Index</dt><dd><t>The index into of this SFL within the list of SFLs that were assigned
          against the FEC that corresponds to
          for the SFL. FEC.</t>
<t>       Multiple SFLs can be assigned to a FEC FEC, each
          with different actions. This index is an optional
          convenience for use in mapping between the TLV
          and the associated data structures in the LSRs.
          The use of this feature is agreed upon between the
          two parties during configuration. It is not required, required
          but is a convenience for the receiver if both parties
          support the facility,

SFL       The facility.</t></dd>

<dt>SFL</dt><dd>The SFL used to deliver this packet.  This is an MPLS
          label which that is a component of a label stack entry as
          defined in Section 2.1 of [RFC3032].

Reserved  MUST <xref target="RFC3032" sectionFormat="of" section="2.1"/>.</dd>

<dt>Reserved</dt><dd>  <bcp14>MUST</bcp14> be sent as zero and ignored on receive.

FEC receive.</dd>

<dt>FEC</dt><dd>       The Forwarding Equivalence Class that was used to
          request this SFL.  This is encoded as per
          Section 3.4.1 of [RFC5036]
]]></artwork></figure>
          <xref target="RFC5036" sectionFormat="of" section="3.4.1"/>.</dd>
	</dl>
        <t>This information is needed to allow for operation with hardware that
discards the MPLS label stack before passing the remainder of the
stack to the OAM handler.  By providing both the SFL and the FEC plus
index into the array of allocated SFLs SFLs, a number of implementation
types are supported.</t>
      </section>
    </section>
    <section anchor="rfc6374-combined-loss-delay-measurement" title="RFC6374 Combined Loss-Delay Measurement"> numbered="true" toc="default">
      <name>Combined Loss/Delay Measurement Using SFL</name>
      <t>This mode of operation is not currently supported by this specification.</t>
    </section>
    <section anchor="PCSEC" title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>The inclusion of originating and/or flow information in a packet
provides more identity information and hence potentially degrades the
privacy of the communication.  Whilst  While the inclusion of the additional
granularity does allow greater insight into the flow characteristics characteristics,
it does not specifically identify which node originated the packet
other than by inspection of the network at the point of ingress, ingress or
inspection of the control protocol packets.  This privacy threat may
be mitigated by encrypting the control protocol packets, regularly
changing the synonymous labels labels, and by concurrently using a number of
such labels.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations documented in <xref target="RFC6374"/> target="RFC6374" format="default"/> and <xref target="RFC8372"/> target="RFC8372" format="default"/>
(which in turn calls up <xref target="RFC7258"/> target="RFC5920" format="default"/> and <xref target="RFC5920"/>) target="RFC7258" format="default"/>) are applicable to this
protocol.</t>
      <t>The issue noted in <xref target="PCSEC"/> target="PCSEC" format="default"/> is a security consideration.  There are
no other new security issues associated with the MPLS dataplane. data plane.  Any
control protocol used to request SFLs will need to ensure the
legitimacy of the request.</t>
      <t>An attacker that manages to corrupt the RFC6374 <xref target="RFC6374" format="default"/> SFL TLV in <xref target="sfltlv"/> target="sfltlv" format="default"/> could
disrupt the measurements in a way that the RFC6374 <xref target="RFC6374" format="default"/> responder is unable to
detect. However, the network opertator operator is likely to notice the
anomalous network performance measurements, and in any case case,
normal MPLS network security proceedures procedures make this type of attack extremely unlikley.</t> unlikely.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="allocation-of-mpls-generalized-associated-channel-g-ach-types" title="Allocation numbered="true" toc="default">
        <name>Allocation of MPLS Generalized Associated Channel (G-ACh) Types"> Types</name>
        <t>As per the IANA considerations in <xref target="RFC5586"/> target="RFC5586" format="default"/> updated by <xref target="RFC7026"/> target="RFC7026" format="default"/> and <xref target="RFC7214"/>, target="RFC7214" format="default"/>, IANA is requested to
allocate has
allocated the following codeponts values in the “MPLS "MPLS Generalized Associated Channel
(G-ACh) Type” Types" registry, in the “Generic "Generic Associated Channel (G-ACh) Parameters”
name space:</t>

<figure><artwork><![CDATA[
Value  Description                            Reference
-----  ---------------------------------      -----------
TBD    RFC6374 Time Parameters"
registry group:</t>

<table anchor="tab-1">
  <name/>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x0010</td>
      <td>Time Bucket Jitter Measurement This

TBD    RFC6374 Multi-Packet Measurement</td>
      <td>RFC 9571</td>
    </tr>
    <tr>
      <td>0x0011</td>
      <td>Multi-packet Delay             This
       Measurement

TBD    RFC6374 Average Measurement</td>
      <td>RFC 9571</td>
    </tr>
    <tr>
      <td>0x0012</td>
      <td>Average Delay Measurement      This
]]></artwork></figure> Measurement</td>
      <td>RFC 9571</td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="allocation-of-mpls-lossdelay-tlv-object" title="Allocation numbered="true" toc="default">
        <name>Allocation of MPLS Loss/Delay TLV Object"> Object</name>
        <t>IANA is requested to allocate a new has allocated the following TLV from the 0-127 range of the
MPLS
"MPLS Loss/Delay Measurement TLV Object Registry Object" registry in the
“Generic
"Generic Associated Channel (G-ACh) Parameters” namespace:</t>

<figure><artwork><![CDATA[
  Type Description                       Reference
  ---- --------------------------------- ---------
  TBD  Synonymous Parameters" registry group:</t>

<table anchor="tab-2">
  <name/>
  <thead>
    <tr>
      <th>Type</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>4</td>
      <td>Synonymous Flow Label             This
]]></artwork></figure>

<t>A value of 4 is recommended.</t>

<t>RFC Editor please delete this para <xref target="RFC3032"/><xref target="I-D.bryant-mpls-sfl-control"/><xref target="RFC5036"/></t> Label</td>
      <td>RFC 9571</td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7876.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8957.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5036.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7026.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7214.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8372.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5921.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7190.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"/>
      </references>
    </references>
    <section anchor="acknowledgments" title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors thank Benjamin Kaduk and Elwyn Davies <contact fullname="Benjamin Kaduk"/> and <contact fullname="Elwyn Davies"/> for their thorough and thoughtful
review of this document.</t>
    </section>

    <section anchor="contributing-authors" title="Contributing Authors">

<figure><artwork><![CDATA[
 Zhenbin Li
 Huawei
 Email: lizhenbin@huawei.com

 Siva Sivabalan
 Ciena Corporation
 Email: ssivabal@ciena.com
]]></artwork></figure> anchor="contributors" numbered="false" toc="default">
      <name>Contributors</name>
    <contact fullname="Zhenbin Li" >
        <organization>Huawei</organization>
        <address>
          <email>lizhenbin@huawei.com</email>
        </address>
    </contact>

    <contact fullname="Siva Sivabalan">
        <organization>Ciena Corporation</organization>
        <address>
          <email>ssivabal@ciena.com</email>
        </address>
    </contact>
    </section>

  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="I-D.bryant-mpls-sfl-control">
<front>
<title>A Simple Control Protocol for MPLS SFLs</title>

<author initials='S' surname='Bryant' fullname='Stewart Bryant'>
    <organization />
</author>

<author initials='G' surname='Swallow' fullname='George Swallow'>
    <organization />
</author>

<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
    <organization />
</author>

<date month='December' day='7' year='2020' />

<abstract><t>In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow labels (SFL) was introduced.  This document describes a simple control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels.  It is not the only control protocol that moght be used to support SFL, but it has the benefit of being able to be used without modifying of the existing MPLS control prodocols.  The existance of this design is not intended to restrict the ability to enhance an existing MPLS control protocol to add a similar capability.  A Querier MUST wait a configured time (suggested wait of 60 seconds) before re-attempting a Withdraw request.  No more than three Withdraw requests SHOULD be made.  These restricctions are to prevent overloading the control plane of the actioning router.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bryant-mpls-sfl-control-09' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bryant-mpls-sfl-control-09.txt' />
</reference>

<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference  anchor="RFC3032" target='https://www.rfc-editor.org/info/rfc3032'>
<front>
<title>MPLS Label Stack Encoding</title>
<author initials='E.' surname='Rosen' fullname='E. Rosen'><organization /></author>
<author initials='D.' surname='Tappan' fullname='D. Tappan'><organization /></author>
<author initials='G.' surname='Fedorkow' fullname='G. Fedorkow'><organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'><organization /></author>
<author initials='D.' surname='Farinacci' fullname='D. Farinacci'><organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'><organization /></author>
<author initials='A.' surname='Conta' fullname='A. Conta'><organization /></author>
<date year='2001' month='January' />
<abstract><t>This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well.  This document also specifies rules and procedures for processing the various fields of the label stack encoding.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3032'/>
<seriesInfo name='DOI' value='10.17487/RFC3032'/>
</reference>

<reference  anchor="RFC7876" target='https://www.rfc-editor.org/info/rfc7876'>
<front>
<title>UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks</title>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></author>
<author initials='S.' surname='Sivabalan' fullname='S. Sivabalan'><organization /></author>
<author initials='S.' surname='Soni' fullname='S. Soni'><organization /></author>
<date year='2016' month='July' />
<abstract><t>RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM).  This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.</t></abstract>
</front>
<seriesInfo name='RFC' value='7876'/>
<seriesInfo name='DOI' value='10.17487/RFC7876'/>
</reference>

<reference  anchor="RFC5586" target='https://www.rfc-editor.org/info/rfc5586'>
<front>
<title>MPLS Generic Associated Channel</title>
<author initials='M.' surname='Bocci' fullname='M. Bocci' role='editor'><organization /></author>
<author initials='M.' surname='Vigoureux' fullname='M. Vigoureux' role='editor'><organization /></author>
<author initials='S.' surname='Bryant' fullname='S. Bryant' role='editor'><organization /></author>
<date year='2009' month='June' />
<abstract><t>This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires.  In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.</t></abstract>
</front>
<seriesInfo name='RFC' value='5586'/>
<seriesInfo name='DOI' value='10.17487/RFC5586'/>
</reference>

<reference  anchor="RFC6374" target='https://www.rfc-editor.org/info/rfc6374'>
<front>
<title>Packet Loss and Delay Measurement for MPLS Networks</title>
<author initials='D.' surname='Frost' fullname='D. Frost'><organization /></author>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></author>
<date year='2011' month='September' />
<abstract><t>Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput.  This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation.  This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6374'/>
<seriesInfo name='DOI' value='10.17487/RFC6374'/>
</reference>

<reference  anchor="RFC8957" target='https://www.rfc-editor.org/info/rfc8957'>
<front>
<title>Synonymous Flow Label Framework</title>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></author>
<author initials='M.' surname='Chen' fullname='M. Chen'><organization /></author>
<author initials='G.' surname='Swallow' fullname='G. Swallow'><organization /></author>
<author initials='S.' surname='Sivabalan' fullname='S. Sivabalan'><organization /></author>
<author initials='G.' surname='Mirsky' fullname='G. Mirsky'><organization /></author>
<date year='2021' month='January' />
<abstract><t>RFC 8372 (&quot;MPLS Flow Identification Considerations&quot;) describes the requirement for introducing flow identities within the MPLS architecture.  This document describes a method of accomplishing this by using a technique called &quot;Synonymous Flow Labels&quot; in which labels that mimic the behavior of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router.</t></abstract>
</front>
<seriesInfo name='RFC' value='8957'/>
<seriesInfo name='DOI' value='10.17487/RFC8957'/>
</reference>

<reference  anchor="RFC5036" target='https://www.rfc-editor.org/info/rfc5036'>
<front>
<title>LDP Specification</title>
<author initials='L.' surname='Andersson' fullname='L. Andersson' role='editor'><organization /></author>
<author initials='I.' surname='Minei' fullname='I. Minei' role='editor'><organization /></author>
<author initials='B.' surname='Thomas' fullname='B. Thomas' role='editor'><organization /></author>
<date year='2007' month='October' />
<abstract><t>The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031.  A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them.  This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made.  This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5036'/>
<seriesInfo name='DOI' value='10.17487/RFC5036'/>
</reference>

<reference  anchor="RFC7026" target='https://www.rfc-editor.org/info/rfc7026'>
<front>
<title>Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel</title>
<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></author>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></author>
<date year='2013' month='September' />
<abstract><t>The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH).  RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message.  These TLVs are called ACH TLVs</t><t>No Associated Channel Type yet defined uses an ACH TLV.  Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.</t><t>This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.</t></abstract>
</front>
<seriesInfo name='RFC' value='7026'/>
<seriesInfo name='DOI' value='10.17487/RFC7026'/>
</reference>

<reference  anchor="RFC7214" target='https://www.rfc-editor.org/info/rfc7214'>
<front>
<title>Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry</title>
<author initials='L.' surname='Andersson' fullname='L. Andersson'><organization /></author>
<author initials='C.' surname='Pignataro' fullname='C. Pignataro'><organization /></author>
<date year='2014' month='May' />
<abstract><t>RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new &quot;Generic Associated  Channel (G-ACh) Parameters&quot; registry under the &quot;Multiprotocol Label  Switching Architecture (MPLS)&quot; heading.  This document updates RFC 5586.</t><t>This document also updates RFCs 6374, 6378, 6427, and 6428.</t></abstract>
</front>
<seriesInfo name='RFC' value='7214'/>
<seriesInfo name='DOI' value='10.17487/RFC7214'/>
</reference>

    </references>

    <references title='Informative References'>

<reference  anchor="RFC8372" target='https://www.rfc-editor.org/info/rfc8372'>
<front>
<title>MPLS Flow Identification Considerations</title>
<author initials='S.' surname='Bryant' fullname='S. Bryant'><organization /></author>
<author initials='C.' surname='Pignataro' fullname='C. Pignataro'><organization /></author>
<author initials='M.' surname='Chen' fullname='M. Chen'><organization /></author>
<author initials='Z.' surname='Li' fullname='Z. Li'><organization /></author>
<author initials='G.' surname='Mirsky' fullname='G. Mirsky'><organization /></author>
<date year='2018' month='May' />
<abstract><t>This document discusses aspects to consider when developing a solution for MPLS flow identification.  The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.</t></abstract>
</front>
<seriesInfo name='RFC' value='8372'/>
<seriesInfo name='DOI' value='10.17487/RFC8372'/>
</reference>

<reference  anchor="RFC8321" target='https://www.rfc-editor.org/info/rfc8321'>
<front>
<title>Alternate-Marking Method for Passive and Hybrid Performance Monitoring</title>
<author initials='G.' surname='Fioccola' fullname='G. Fioccola' role='editor'><organization /></author>
<author initials='A.' surname='Capello' fullname='A. Capello'><organization /></author>
<author initials='M.' surname='Cociglio' fullname='M. Cociglio'><organization /></author>
<author initials='L.' surname='Castaldelli' fullname='L. Castaldelli'><organization /></author>
<author initials='M.' surname='Chen' fullname='M. Chen'><organization /></author>
<author initials='L.' surname='Zheng' fullname='L. Zheng'><organization /></author>
<author initials='G.' surname='Mirsky' fullname='G. Mirsky'><organization /></author>
<author initials='T.' surname='Mizrahi' fullname='T. Mizrahi'><organization /></author>
<date year='2018' month='January' />
<abstract><t>This document describes a method to perform packet loss, delay, and jitter measurements on live traffic.  This method is based on an Alternate-Marking (coloring) technique.  A report is provided in order to explain an example and show the method applicability.  This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.</t></abstract>
</front>
<seriesInfo name='RFC' value='8321'/>
<seriesInfo name='DOI' value='10.17487/RFC8321'/>
</reference>

<reference  anchor="RFC3270" target='https://www.rfc-editor.org/info/rfc3270'>
<front>
<title>Multi-Protocol Label Switching (MPLS) Support of Differentiated Services</title>
<author initials='F.' surname='Le Faucheur' fullname='F. Le Faucheur'><organization /></author>
<author initials='L.' surname='Wu' fullname='L. Wu'><organization /></author>
<author initials='B.' surname='Davie' fullname='B. Davie'><organization /></author>
<author initials='S.' surname='Davari' fullname='S. Davari'><organization /></author>
<author initials='P.' surname='Vaananen' fullname='P. Vaananen'><organization /></author>
<author initials='R.' surname='Krishnan' fullname='R. Krishnan'><organization /></author>
<author initials='P.' surname='Cheval' fullname='P. Cheval'><organization /></author>
<author initials='J.' surname='Heinanen' fullname='J. Heinanen'><organization /></author>
<date year='2002' month='May' />
<abstract><t>This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3270'/>
<seriesInfo name='DOI' value='10.17487/RFC3270'/>
</reference>

<reference  anchor="RFC5921" target='https://www.rfc-editor.org/info/rfc5921'>
<front>
<title>A Framework for MPLS in Transport Networks</title>
<author initials='M.' surname='Bocci' fullname='M. Bocci' role='editor'><organization /></author>
<author initials='S.' surname='Bryant' fullname='S. Bryant' role='editor'><organization /></author>
<author initials='D.' surname='Frost' fullname='D. Frost' role='editor'><organization /></author>
<author initials='L.' surname='Levrau' fullname='L. Levrau'><organization /></author>
<author initials='L.' surname='Berger' fullname='L. Berger'><organization /></author>
<date year='2010' month='July' />
<abstract><t>This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks.  It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support.  Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.</t><t>This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths.  The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.</t><t>This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.  This document  is not an Internet Standards Track specification; it is published for  informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5921'/>
<seriesInfo name='DOI' value='10.17487/RFC5921'/>
</reference>

<reference  anchor="RFC7190" target='https://www.rfc-editor.org/info/rfc7190'>
<front>
<title>Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)</title>
<author initials='C.' surname='Villamizar' fullname='C. Villamizar'><organization /></author>
<date year='2014' month='March' />
<abstract><t>Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks.  MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques.  Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.</t><t>Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs.  This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.</t></abstract>
</front>
<seriesInfo name='RFC' value='7190'/>
<seriesInfo name='DOI' value='10.17487/RFC7190'/>
</reference>

<reference  anchor="RFC7258" target='https://www.rfc-editor.org/info/rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2014' month='May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>

<reference  anchor="RFC5920" target='https://www.rfc-editor.org/info/rfc5920'>
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author initials='L.' surname='Fang' fullname='L. Fang' role='editor'><organization /></author>
<date year='2010' month='July' />
<abstract><t>This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks.  This document addresses the security aspects that are relevant in the context of MPLS and GMPLS.  It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting.  This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5920'/>
<seriesInfo name='DOI' value='10.17487/RFC5920'/>
</reference>

    </references>

  </back>

<!-- ##markdown-source:
H4sIAJCNQmAAA+09a28bR5Lf+1c0bOAg3VKMJduxYyBAZMlydCfFWlNJcLsI
Ds2ZJjXRcIaZnpHM2N7ffvXqxwxJ2UHi2ySIFutI5HR3dXW9q7pmb29PZXVe
VPNnumtne0+Vaou2tM/065Ojzx8+eaQnq6quVou6c/qkrG/1mZna0ikznTb2
Jjy2Nzk5U3mdVWYBY/PGzNq9wsKEi2Xp9ppZRg+5Wbm3/0DdwmLnF2cT/X3d
XMPS+mVTd0uVmdbO62b1TLs2V8q1psr/15R1BTOurFPL4pn+Z1tnI+3qpm3s
zMFvqwX/ktWLha1a94NSpmuv6uaZ0noP/k8/ReWe6clYP29Wpmr1zot813/F
EE9ae2uaVh7w39UNQHrStV1jb22hL212VdVlPS+s06dVNvbP2YUpSgB7+pXj
eaY0zRiAWoPi5VhPbk0JqOxD8NLCanb4HUEwqWFHtsoZgCIzpT6CvdpmuD6P
HSPiv5rjZxshOB/rI5iuv/y5ya56H9PKX3cGNj5YZgGPjjN49Ksr+nrbNk+K
Osvq0gz2WXTOLpd27etkwR6mB6vPZfx4JuM/AMV50bjr1QCGhght8B0B8I/L
F/qobpbDs9VzGFMsaECCW6WqulmYtrixSHCne8djPnsmfCT4rK7api7xa2CW
g/39L+TXp/tPHsmvDx88PJBfnzx98rn8+vjx08/XH0BO8jN88fiJf/bBQ//s
kwcH4deDfXhWFdUshRJHPnxyEH492PerHDx54Of7Inz6ZP+LB2G+x0/jA/Sp
2tvb02bq2sZkrVLwjSa5kVuXNcUUOGVhgR9zp+sZkA7xe1k7p4G74aHSrOAB
44DFiH91XSkSMcAJRQtUlusL0145vXM2uXC7etkUC9MU5Uobp4EScjhoFiaX
jancEiSDvmjqWVFavYOf711e7KrKtrcga9xY68urwmmQVB0ul0BpBE4E075p
gd0Q0rCdpW0Ih1VmVQ/eWVMv9AzYzunMNE0BENU3ttGytm7rTd/ObWWbImPI
cWdjdVrpJYiOIutK04x00QoYTgHz65ZY/6fO4oSa+PxONMJTUwv4zi1gVC+6
si32lnUBW4Zv6BeFy9LwAgk07zLAgqsXVps8L9qirkDOhGVpRl52UTcWHlwC
IgFaENq52rY0nM20bq8CMnC13tbDwQAnISEtijwvrVL3Qb4yUAiIUm/fCuW/
f69v4eTrppgXACDQARxhMa8AsXA+SBFIGKbSr+DEDA4G5XCYL4qqQBLFD0YI
hjo3sG1b4YHqnVeH50haNWiXulR+IiDAqw/SlibQkF0ANDrJsNu6KlfKdUsc
6Bjpe20tx4CoCB+l58NzbCNTdQUnABhG+LyKBiwjifQQmxlnaaNwaK5Oj9jo
qltMQXkgP64d5YAZZ9oslyV8NS3Kol3R2eKB4vR4aLR5FCaw+QgkQtPYn7qC
56GT8RAAVylkCF3k8BXQGTx/C8oEdiQMR3tKD3xpsmsLiEFyP0/AUztn57vA
0sA5rluAWFiF4YAeBgN5ZC/Zk8YxfkZDzyj/F6iTDkACAHOQ+k1G1MKHBKt8
i0K07SrAElBdi+czB4HqdFM44kqPWMCaAlqalnaB85sWeGGlS2tyfAqJtZgB
RgGWtYW1bZq6cYAsldmmBRKF59uO6RhgOAFE2jcGdAsIcrUPn3x/ZeEIjWaU
AgN30x9thgcJa734qUNboXatPicKQ1EK1s/R+QXbP2BFmZbQwqCglKo0Cqob
kBtdiwRQNznsiXihsW4Jk+PUiNuzc5qEhwIxHHwQHlg4rjnasChNCBjLi9kM
JgLArkyTg0mFsgQsnpkBEh7B6mCOMoUh1hqb2SUdFhIsmzBn5x69+HGVjCfw
QX7MYVtmwxkYljlkEgBcCSxxiturAuwlPNeqblHcZfVeWTMHEaqKli0I4uPC
yTQo3FsRqmjGCZkQ9eQ5oNfxaKRKHC1MhBIe7A9L28uyDlTtCvD9EPD94gZY
55aQ3tK/sFYlmN6ZRXLBrbyefHexd/liFAQUihrGOAojZ7u8voXl3M7F9253
V+OGCEbAOTEn7hf2mqMoLaZd67VZSvlEETwEVs9AwMB5IfHjBEj/qyq7auqq
+FnYSzgF9vMI9nNWVNfazNHa4u8TDUQyAa0RkAkICkm2wFf9eQmOwjkYN9ZK
PYapJ6jbACVATUjRBaIF6ZC5CwjtBgkX/I25XhZLWxZANFPQT1aM4gQRkWxI
fWYsW2iHV6iAXJ0VRAtEVBbUuZkDM9M0d+AikEhBwvWwQunb1Giaw9MLEJaI
FF4FZM5wOG0XCcBLYoTNi2jST0UllOs5DxhLTQ3bWdMVQe/A5sAzhZ1ZXJm+
xllBJF6zvUVWwi2cgOsQNBBxyuQ/Al8Aj/BszNNAKyB50VgDDq1B7v0cl0Ge
BYZvZJ/R5PA8YVCuukjbSK3MSdusGXAHC1TnpADz2jpiTvio7HI8Wld3TWYD
p4na9OLrGzZFYJuVmbOuqIMN4TmRRqTqBDhSSAE1jRJ6SRYj8wy0a0UTobZq
cRckwSqLBIV6q01UtCL0yngUuKgudLDh8aArkcCyNI4mbTpbyUfKHwOZpyZO
w9MGzQ0ORE9z96zgiiMDaPuSPAc/AhifTTJCnxHTuySDHRz27FrUuEkMVhAi
JdiImwMJemdycrYbCbPkT0W+gsOVkTCcWmDPom5IIaGg8w8CtdzA3lNsCMEy
QgrbkJGrwNQDsuLnYDg/tCb8vYOwsIvaIw3QgkYXwOkUKiLyOpDu2CUINkdC
B3Ts/vN163yMBu7raCA5QEY174DslLoEAK/tSgMtgs907/zbyeW9Ef9Xf/OK
fn/94u/fnr5+cYy/T74+PDsLv/ATCv549e2ZfI+/xZFHr87PX3xzzIPhUz34
6Pzwf+6xgXzv1cXl6atvDs/uMaek9iiigc18UonLxqKwM33Jo58fXej9R0xp
6PcCpTHV7bMdD1Yfm6hoKMufcD4rlHrWNERhZakysyxakPUjXMDBUVQaZQIj
UXB8sdlEZG2KsSnCa25aYAXb3BSZDSIQKAqJggyWqUXiZTLH8bgp2Ooc41NA
wsR3wlneuC4T0mPtjWALfeFgEZv4DXlyCI5O7WbQkWhY1ZVXC2Qz0gRjAlsk
MtEoW7VB3YaFRZjxKLTCKuYbAuMKEJfVqO9oRwB3IugL/K6aEb/w0rgpxorq
Te+hgr3AE6QvpyjsRJTno/60qHsViAh/Rn/vbIN8ABJvTuSTAzjNAtVssiew
vjr065SfleCF/WR2y9aB4Vp0mIJDpPoroRWKe2PJRCAaELB4DOwADE6A9wim
zCZy4YVYFHvS4eWI5WkWF+mhcKrHEsGtgdXfv++R8ATWBgEllHxMQiMl5bf3
JxfH7ynCMgiwiEsoEiYVhSx6pl76yP5Vi+5sAaddLNimrIZCjM26CnXuWE9Q
yweTxxu9qrIsB9H6TWMbMAxxy7oYgWEoxFKMMQ5S6AoYuitznASchq7KvBmP
A8HtRoNIH5VgUumdy6NdPS1aMui+rm/tDRpWbB+gcCZuYw72InoBxlELWiMV
zfAnjVGstUCvgtMFjzs0grqSBICElui0MCgGXIoRWOJf3Nuth9mLYlzMVoJ+
0xL0fZQqVmkYvEhgxFgF6rA3K3KSzSYRBSY8qJoCOSBXBrgNxK1ju/VGkDuk
SvCBBgfaOyFvTYmu5vMqvHDdTKbHCNhEANtGpEqx/1e0YoaS80IHQZipQZDO
r0DYRxEbCYskMAmnWvVFgxDQLHU0IovRWl1Fq7GOrxUKITTmDcbU45g+Uhy5
eoiBeAop/oP023Hge719i/z3fnesDxMjKYcdZm054DCBOAPnFZaAw8PwilO0
Ay9eEhnBrtsMcYRMZXPA+MvihmU4eySkZ29AC/IJMjHx1ntWpBcCQnRI8SP/
HDCtf7Yo2QrHOE6kWAYNpYIjcqTA422dhvd0u1qiVe4ZgM0sMPGQBDtY69Zy
EC6NWKKDsMTzFPUFc/bjTKwnc5TEFbi36GyXLFFXQBgNIBNpHZRCAce8RAWD
USU0bclFIYuQeQA2SV6jbGlFU2+ZQDwMmoeEZt3iZsAHSTYfHBpALqK+NEvS
hoCkkQpmK+HRFmSZxvOP+GSVmUrMrkV2a1otS5H7sPFRDgPznxyBJX2VteRV
VVlRFiaRmuoG9oVWtvieaG0iZrxfhfGIsuwoGuqV0snpy+NzEHIgEOvbZ0r5
5MfO/q4+DD/Pw8+mz8IgFCbnhjN7RPE9uxxRS3J4kYoNv94BrncMP79mPddN
nQ3a2bMZLkzHEld7GHeHa/6Wq5msIT/AD0s1UMpOUzikHHg3AvUIgTo6xv99
NAouPStjTBe9Y4z4bMgKsHnqR5ltUPED/rFD/R/6OfFRsHJJyNOowqszGZ77
UUcw6tiPstf9UTFpsT7+7TN9n+hRUyb6y3sotJ889PajqB5v2N8Di+i04s3v
4/YjMYMkcmQaeeQkAKRHQClmFQAJmrKj0GHwDToJi5hy5QqwQTAWGxgJQ5fL
rlnWKFCAKV2RkyQAKbT/II22hJwVCS6OkrKpTrzvxbzAQqv9TPrgG+J7mZi2
czDYrkRe3QLt92DE+rUTgeJnjSxBshOldt9fSYOfCgkfhT/AmGOugFVdKmYl
8cM2l0xP2QKSbeHMWVDDdF8e+rms42NhqA9H9O1x8q2oTZWoTXZVEkc0cdrC
xkZ6CseIoB+jLe5iDMITEK4m2hTOoWsqMoQGzyER0PmXK0wPnHAQETHwApx4
OC9yT8RMPXlxtOu1YWI1E1aPWbrjIWTgS4MZzDJY4jmHEkXCvY7ix8wqDi0+
MiSIf/xEPqJJxiRlo8sxmmFBFwkEhQu+lagGoIdbtOZ2gkwOZ7Sr2EwOk6Am
9ApFdCrrHgxOdxKFx0QX28/KSPQYDNKWgnzr9PvwY+jXH7dKSDOcbpCyKfV4
iepp2k+QKl+Bg3GGHgmuJMSna++mxA+fc0jEVKuBN4uTkmnQmmtYqsTcgJm1
KCj6kQFF8x7rHaI1dF10vZSoLdiJIDeqXQlBUyIk12KTsRuMWD2bvN6Ix0c9
PI7114hHEH4S0I6iT7EdGJIKHuzUqt6uNDZYrsSCtyI2gv3rqQkOAHz8mkJH
6taKBAI6ImctHuLOEdHd8a5EVAB7mGQLsXfAwkLvcComMaumq/6fBqTybrDc
gjAGEfgRprlX3zHX482+uF1ygyiJMMHcQTFbUcKyK60DHUSohSVdwS4IHRJF
S4MfImaCWJHLROuR0iXLekRiCGxlWpnNd5FkA82Jv8mJ8IRjfTpDPLONiPSX
1YupBJ5pOsrajjiWh2kIJ3DOinknuXHVUrB6zpmNXopEQkhvMA8cYzKU/TCO
ch0OkcSeKMKA07gEVQ2iKvqvpPVyOzOYE0PQOKV5CEzmVq7FtBjSV2Ax79rw
9ikginJUPD4wOfwDRHyUjhzOVdwxkccDMcbadDqVqHQSqThucHhZUqJTUSkR
px5YNPXk4EP0H9e4TJ8f/g/OCEIHtRqAzekNEa1mo4kmakJSrLgzxLB+xKm0
TasE88Jvml0QW6FbLiiiqUm5+JAhPDirJbAEZw6ghCIeJkD/IGL9Mav3XAhK
bGRUFp5wd44HTgfNsQBDiiDqQM1jatpHIoP9Htw0+QCdlWouMVOjZ0XjCPZU
KoBsSdfa3RK5lB3yurYP7nCLnCDABwovvx1Swqzgs7+V2Cv7fZjl41hEyKOR
P4/zGS+E0W/l7JPiPOPS+OwnupnMi461kllgaITR43NsQDjTsnBXDIAk2GRG
SWLVTRJTENUS4spUoObYVqMvmBCrPD1GZaIE8pI49exGkpVkLmcTweQYaAhi
hELoEnGlNVFjVhzJP/duSy+2dDSIoIAajbrKF5YZ4mUfZWVjzuQBtSJ2U52m
kvohn+Xpx2dRkb4wrO54X341DKZHq3ioRwhpQYkkKWMsKamwCi7NOsZ0NMtN
MATQIAt7Yz7kiIUfSTY4RZ7MvKpx1Xii/qxhz/aa4qSXV1g3cJ5iqnBZ50Bg
s7i9RCp93rGRAiKTjFiYc4LltwAaHMQNxxdIdIGqwZj6MTvS9+/L1Hr/WX8m
dMpazqTR92umjD8PjgiRYNoTpMzNcqQzgoOyb6wnyFus+nU2nkU78a8AS2iX
YuZsY65AeceLR8B+qFZMaiRA9876aLy1DcekwCRBk2yKTmGa61EmBie7JVLc
Ppr9B/jPI/znaSeZIgrbwV8USJZajRBFm2EkV3ZBjtLAyWGLMCwgAzPTOZbK
+BkP90Y6Z5RZNY9CWhqfw+kPGA7672AcT+2HattmYyywWiKVI22CflgU8yuS
1TAtDkktlrRIgircfEgNRRdoSBBTC0DziMVkcI+uTB5Q6aN1tAUsnAMxaaWe
BFYg3BISo8CKmPHJrYMYAFN0iqFKA/NUJMNAyVJYOretIT8mTbFjnB70dhY8
NK7sQM+ZBBFbFRRai0ROlpfrkxApACuVdmQPdgQNPfVjQQgcxonh1Cu2nIZx
ZSP8xwNlIzd1kftE1oKq9bzmRdsJHdYkW20o/e29Uha64iaTsMEwIWiTlZjr
Xo/F+LM3yz3TsUsFw+agmxZkjokGSjQPRyCDzPNpilRm6P9iZKQ5r3NO4amQ
m/ABSgoxPdDrP/sbPjvY8NlDP8U+fP0QfKjH+nP9RD/VX/ySz2iSv+39yv/R
LO++A88aju2dPinN3Ol3Wh+Jkjyqc4t/84/gRJ/Zag7k73/e/ZawaP33yxP6
72v+7+sL+Tv9eW0xUQJUMvz5jWHZ+DNBKQNUfhrqPJL18Z/jySeA5ZugURLY
Ah42Ed86Xt55JZlC+wt+PjV2T72TAEJq/0GFubUiALtlR7/u51PvSE5tec2V
DCJv/ig7+tevhOVfv+Esf5QdXZ59p5+D5339/7AjSVgIVUnS4uMUGyYRQBdi
EgMVpKiAEauAUU8BjAaCf4QieoTyeUTSeaTWJeIoiiaKsE30SWFL8QOoWmtW
VFLSabny4uH4QMVEOfvyDd6Bqii0R8N9wJzSGZXcvkADYQ7wj/zkHANyoqzr
RHR68SdG0FoisE4laogLUKrG6Z9tU7NDDN4POtC1uPHLMHqLACs2uBohIAJG
iWSuyGth42YA+kVffhTbarFmGIHWIc+WTMip2MbGLEAy3IP9mRdXpmicOH+U
beQ8URzgLTDOFUU/VswvjFAXmBc/TSt8VFIW1S+WCQEwrgXgyUd6pxjbsfhv
VCMFi6NBhg4CRQrByF3UucT4kqFUVtnEorbUiETsxNIpAWl3FJwjqaSCtRSF
qmRpzsbEhFrfndNYw1litcMVVdmAkZoE9bi+ZtYB4tOQGJbW1LlEdWLCSWJh
7AeESZT42b5wioKBxrUCH0UJaCsjcUQ6l2DOkSEL+y/yEKe+varLiBhySJcS
ZUyvwAAIN8jVNaMt8tJAp80if0vdc/Bd+kVxCJ4DCoeTQY4CwnzVScKjyvsx
YQpsU/VG64kLXR40SjGa7WukKTfRWv6WbzxYzKIgQYXYHeenAMw3fCLoCEhG
1FcsSbkCoVjOVdyk9NgSKh4Wn1GdOO8Za9TXi+EFp8ErlzGc8ax8YeDddXtJ
6OPgrpjJIA4y4oJlJ2ilmhckhZg7a3vhcy5YGPiHHLj55s4aUL1T7Y4xnjPp
FiFQwkXb/oHJLkZ0zs2bYgHPUERnjIHjc5D1ySePwxzup840nBI5TYWohHUn
E1hRDSJ2IMEp4EB3pby4r3wi+HxDZgYrz4GnFYq//pawpMwHr/hQLi4o5bW+
6kNa9VFcte7asuBimDUIRwAePv7YB1SDRPQBAJoC62rouqDU2QxjVoNCVeeJ
IffEgNBwNP+msLcYUuWUk9ymEZ89RaobzMmMwFrZ/sT3wpQXJQG+HfhtV8v9
NNjQSnQwfKy/xHPSe3ryn5PPqt3Pdqq9/V3ttVIhF0Al4hWLBTsnu0a+Lud1
A6yyIMIN4Qnllx8BBjkyBQsh+LSUR60rFgXWfrIWc6OkHrRcKc4Bh41QsPx2
rKXYU8iHmI7v++dU/udsOUO5VNWtipfCsHbBcxpTkb9KhnFR4N/74VLclorb
vpG2NYbxkdP8FcT4K4gx/Pn3BDE2/kR1cmHS6MQWvPyeHORNsIjKOmYpipLq
OemQP+6O8Kenmj8Iyx9iR6n58cfe0UdZSb/nHf0pwzLnF6GQlPX08uPU/R8s
JvPhqIsX61vDFv6WH1dayvhtclRmScs8EkOdIxV8nuTIpa6b2E69vDu5/KCd
aTNjv3hf3MmSC/lwzfyup4JXLpoJ0Zc+VAzPL4ChJ6A8DPLhJ4cBj3qRku16
Tc+/2xMGO/oCg2Pb762Rlwae8CymWrfuplefiMEgsO99vlml5XWc599YPEBk
SnEh+QxdScpi00URTq/aN75nBFXFkeTGujlu1oMlFEkdqit+DoVzlCBXFP2y
obRvJyZVd6XUA+N1rq0pXSuHEGuUmWk4iTxSfhaMvdwWeUvX/R3fuvNTSBkb
Trzh4Y3JaX9xr3d9J9zKga2AU+z85WmX1cvg5Cl/05fPd1D14VvzJATh+wv4
NHSFyGX3CIvrmfrWq9EkkJxmtsOdRCx6MHQR1Sgp4UluTPnrAnSs7JeGVgm9
mmecbw988cWSw3d+Xl8oEAKNQFFY/s07cCz2PK/yBFya0ReedFlqj74d6xMO
cwkWwnloi2VqeAmhGlxsS2Mh2AVBal8xaIHxtZIR6u8ThpBoCinhi8ALN5mx
EE4IxcUmMwy6WpP7EvrEMEfjvesruRhr8hsDxDrnE/FBKZzGHxefKtcAhL1R
8XLvrh4WMzq6acHDA2OSoMl7c1MVA1BNFS9nJ6skwTC8GKG/rUps5uAbHEh5
e4j6EsffFtgMCdeNIewFVZpQwb/c2/K3FfiGG6wcgrpY+73xROXyqhS99EK9
TI/LpqB+QdtLIKo+d/0VOfgrcjCAZePPX5GDT7ijS9FBJyRJxbL5U+zozNy9
oT/IjsQrwV2xZqa08uYAz+9vR39eZ/vw2PvaH1Rqn9zN/j1718G73ChpisSy
61vCwbwTxzJUMUQXc23qlOXvnhnNxbsm5q/6gYENLMhl59Gi3+qyqn+Ty3ro
EkdF0uo8gTw32pAwxxsLQBOOL/ld1SUYkS7k3l4P8v9MRumjREJpEQslkfWE
Ks/zfhONU0aAJDvJU6z1DDsixdIG7DIHLlqu/SU8LtwWNKtoNW+46YbJtFVy
xmb9jFSojPEsM115/OJNMrzchi0ss7rEAt/Tvh+45gQ63qYauPrxIiYizAQC
jU4ZtYYKVwV8vbivw+CLKrQC9WhKGU6ulQ+vjKZ7xC2lDWloMyPdmJZvemGY
YIAqjv7QnMIVh5vRJg03EuwN42WmN1F6SwGLsdN6GR3bylFWfEMnk5Y7Kxu6
dAN+vep5Tn0aEI8vOMzr3h517BjUZvkdFYulyaQShNpM2tkMRKnztfBy1HF6
6RrJZR4zLQ1xI07iYaOflfhuSRk5V5Hf10cgLlZpn1gvd1NZ0Gtr8/Z+wvxK
fW+T7hdpqKDnkm1uWcXzUh84z/e+6YLvhMftYNZ7DJD0OqF97XP9COvdu3/u
dgH8zyYDB9Hwwae4z/aGpz4JXMP+f78XuPDn5eHZRzy1da5PANfh0df6Em96
fakfvDn8fcDluWKTNfeL4Hp3F2h/S57aPt279adOsKhsT/h461NUZ8UCeOHm
2576wIqfAPpXS+l/ikILTfffG1yvOVi2+anT5OrU9rl+E+jv/PlYuid/hcXx
R7eZQYturd0pKDz7xlAHMDJIsLOgkaAtaTyvKeCPZmNHwU1NJzk5EcZSKSfa
gV6rv5RW74ex0/ARWCsVgMXCcwckmm9N//jp52iS+eZR7VVsvktdGAu68N8V
7irc7ZIyTQI3NK8Bi/vV4XkMG09Cg7+0A+5aXy9vh/GbCMgm2YCFUdopcqsW
dclsI4rGS+uWWLobzAa6J0vum7fbUKbuBKH64MGDw11JsfmFN+XVyEZ1MRbd
0o3aGKMekaHkZ5ilQiiRNWxMSe2t23rpuOcPKQ90JmdLW4pDwy77t5sZR4ow
vhO6qT1Lm0no9YYva1Al5bi3tTQrAZoA0eSoWwF13056PxYz37yO+1FxGoIN
euWF2mDfbla25Q3etQ6N0kN33djYVw36UEhrIthtwT4Co5caFJEzZFxSwtk0
RA8qnrF4aGFJBjuULaaJC+R3NewUntdkCKeth9fkguTk6HPgGgUnmJdYusmr
Ii7SVGcx0wP4EoeRbNtvjy/YAcYXxESM4US+mUOo+O4oJzJCTqB6Tt+ukNN9
ai3dFxr7+laB1xVmGyTzRMyVNJ8mN0B5pIkNL8AHW14YSzopSP4unSa8GGHq
mx5654+zMmrt4eR2bUzjUHOFFIKQf2nrcMOgiIgPfRB5xVk/ZyNHYh3f+d2b
ctefPJ5l7OrSb1sm/Rl6Pck19SSfojPms1Cx2whzjfCKJKJ8Z3KhjhisWgt9
sF8kLAmk4bXzK24F0husU7LxHTr7WeE6Orwf9GTkxi/JFw6UJJmuOyWp5+70
vQQjejeDVFRX9laybwn0PQLdld3zSUaZL+zm9ZoSsgx1y8MevyhVcSXOb4cW
vCKl3t4XwdTXDv7rfqdUNiMOIkuGSJEXfEEoBVEpjT2jvGBEnrw4WpNgCsk+
884qhbcqX/aQ2zexSViIIkzOQmemxobh0RIJq0SUcAsrBB4WGP8p84v4D+n+
YHfqNIf47vz5P94RejmNQN/jn6eE5U+c0cCFNhiz/pdBpvHTwoLk8fE/DMv4
F4zY9DP+LdMQzI/erBemRQOeJJ/E7iMp0G/UI5wk98bXFNBbCvZgml1hjkg5
KCBK/st3rQYRsd2YwjFAa7Lx0IfpQ7cbb6yMjSR6KfJAuswGZU0NqrGlceB8
aXKn+kjHiiewZP95x0vrfpA1LzwfXK7LnRKMYxI7J6ncwfA0XQwdLErvQXHt
BwSRTeVQ+AktgmgpuVDi1+EmUDgl3R7qjySLMbbl4Tf8uHjpD/dDnWC8Th2M
5zwBteAOrxmDU11IFzcfnpXTH25Z5HXyWhj2gHw3kHBz62zy2o0Hoy8H129m
1nAHEYAX3wmUp6sPxmKzPQpvo0ble1a9m31jeRkJWkTeFB0N5sBYNNk2Qxz0
/EgwpKh2RlYbzCEhX05fmYxeJTaK5Bw3in95yx3cEnZRcdfykpbkfUpspgwW
Yo0afEIT3TQOuKcWOnyIXfuHsCaWx0QyhAdj6iz7T3kP4w9CmFEq/3IujkIW
t31nP9E1g6APr9irUXtHHNELXIT948tC5WcS0p+P4vbwLZI/SBx/aPOzxRzC
CEgC4e4nM1h4VRelDzB7ZXwnpjX/SFrKLY0Lb2XgpGt06FTPk8LQQ3Sinq/E
/SL2822AUusIMbwsO6cG4gpMMOklH8Qjvzwg8fr6Dh83ZmR3zOcuem9uOKI2
izARvn5kb0NT/MuNF2Y958WG54PUSJGUtckN2/v6AlO22QoT5JQ6E5/07f2L
o8mLI7FYQ8CIFuReZ76r42d14/sOp28Uirk18Wsd9yyS1/Steo/HW4mhwRO9
iXHemFwadi0FzmB+LxZd5TeC74krSuezXAmwnIfyL4NSMGGFqTkEgN7oxMQ3
p+pbvB7qqDY4nC5tbNhOCXza8DaoXp1geGkSS4yKTkiwJfEVwUniIE3p7QVL
23tThW+2J3lJdv/I45035IrXjVofFbrgyZsnY2yNedjjEENO7C0rbLDM7wFj
KoFDaFbLNpZObp5xBNw1l0uWGE2ah1ehRHNH3qhEfUVX/U78/qVO8TVvVJ3M
I7gvqoWn8ZT6dBmiAPxl1ida79WhDB3EwRCK5CU5aqffoxnPz2HbL/ZtDx4/
Tcfgu2nfv9/lqg15fyVXjVNxs0eOxCj4tWlAHOFWMXHSe9Ygm2Fnv72h1req
qsWBRv81PM8vwEm1fmglzQ422ADc/lBjn1K1dnReEXoJT2Kq93KA8MYRq0o7
B7JYJBwnw+T9ai3KUt83kl9xJt1fm6Zb9l9YEtzgEJ/DVmpljiI9PNyL85L4
wHqNtZefxEgNvaTDd2vFUuGsDTd7Rz0mooQvNU/DuuTimt63STG3ggPOylT1
wpQ1vUKNxyTv5+2BJs0zK2r3htlaH9tOXz8bD40qeW1ORtkCeyNzNbcEWRmL
+EIGnB35ogLwSrviWo7Tw28O1+gfy+dZ0wjj08IUwDclvRBvQxB/5+Xe4dHV
Lvkm2PQyNoWgNQZs5FlHIv3dMvfSgbnjwcHnKXfgS6Hfvx/xVL2I1zDaEPsQ
oCEB5xibDNz7mG2odB/3UAThXffVKExyRx7DD73wLU/dPYVv7wYJbjLr31Hx
nSmBd/Uxlfss0/TTpp/XlhyAjO1kSgXJf+764bHpB+xBPj+mOYXQP9DwB+W5
wDwYuOH2ePpDiiC13VLLYiMk20vvwoRqG12iBfMZD0QJwOFEpTaRSjCgUC+A
4MPnQ5+PB3v7B080KO95CO4N5+9hJ6wFZ8RE4i+R/UIaoTe890hEPPwPk0if
OvjEP4I6wm9+NTyNzVGE4bliO9sbomDA0SNGsDQ2IBMT3z7+Iuc3WJXUjhOc
Iut7rGBHTXlFFXgl79+/fXuHJ49fi4EP2hSE1WGGQf7S5nPuiMslex2+o4l8
jupaP7fVj2YB5/DfJu+uSYC8KG9XlT42N0V8RVCB//KbncT6xl/bWVeqxkqn
i34Ul8UllXhS4wsMyPLKcmT/AOMSTGp9VvDfX3fm1srvL8BLKJ+BXviZH/rq
ir4cA+Jk9ASsJvpnakp5G7A+AsfVwJINGNjxBbF+MnBC6OmvMnyMp1L/Bwz6
2q8cgwAA

-->
</rfc>