<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version='1.0' encoding='UTF-8'?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]> "rfc2629-xhtml.ent">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-lpwan-ipv6-static-context-hc-24" category="std">
number="8724" category="std" obsoletes="" updates=""
submissionType="IETF" consensus='true' xml:lang="en" symRefs="true"
sortRefs="true" tocInclude="true" version="3" >
  <!-- xml2rfc v2v3 conversion 2.38.0 -->
  <front>

    <title abbrev="LPWAN SCHC">Static SCHC">SCHC: Generic Framework for Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6</title> Fragmentation</title>
    <seriesInfo name="RFC" value="8724"/>
    <author initials="A." surname="Minaburo" fullname="Ana Minaburo">
      <organization>Acklio</organization>
      <address>
        <postal>
          <street>1137A avenue des Champs Blancs</street>
          <city>35510 Cesson-Sevigne Cedex</city>
          <country>France</country>
        </postal>
        <email>ana@ackl.io</email>
      </address>
    </author>
    <author initials="L." surname="Toutain" fullname="Laurent Toutain">
      <organization>IMT-Atlantique</organization>
      <organization>IMT Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street>
          <street>CS 17607</street>
          <city>35576 Cesson-Sevigne Cedex</city>
          <country>France</country>
        </postal>
        <email>Laurent.Toutain@imt-atlantique.fr</email>
      </address>
    </author>
    <author initials="C." surname="Gomez" fullname="Carles Gomez">
      <organization>Universitat Politècnica Politecnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <street>08860 Castelldefels</street>
          <country>Spain</country>
        </postal>
        <email>carlesgo@entel.upc.edu</email>
      </address>
    </author>
    <author initials="D." surname="Barthel" fullname="Dominique Barthel">
      <organization>Orange Labs</organization>
      <address>
        <postal>
          <street>28 chemin du Vieux Chêne</street> Chene</street>
          <street>38243 Meylan</street>
          <country>France</country>
        </postal>
        <email>dominique.barthel@orange.com</email>
      </address>
    </author>
    <author initials="JC." surname="Zuniga" fullname="Juan Carlos Zuniga">
      <organization>SIGFOX</organization>
      <address>
        <postal>
          <street>425 rue Jean Rostand</street> <street>Labege  31670</street>
          <street>31670 Labege</street>
          <country>France</country>
        </postal>
        <email>JuanCarlos.Zuniga@sigfox.com</email>
      </address>
    </author>
    <date year="2019" month="December" day="05"/> year="2020" month="April"/>
    <workgroup>lpwan Working Group</workgroup>

<keyword>header compression</keyword>
<keyword>compression</keyword>
<keyword>fragmentation</keyword>
<keyword>static context</keyword>
<keyword>rule-based</keyword>
<keyword>LPWAN</keyword>
<keyword>LPWANs</keyword>
<keyword>low power</keyword>
<keyword>low-power</keyword>
<keyword>6LoWPAN</keyword>
<keyword>6lo</keyword>
<keyword>LoWPAN</keyword>
<keyword>LoWPANs</keyword>
<keyword>LLN</keyword>
<keyword>LLNs</keyword>
<keyword>LTN</keyword>
<keyword>LTE</keyword>
<keyword>LTE-M</keyword>
<keyword>Sigfox</keyword>
<keyword>LoRaWAN</keyword>
<keyword>NB-IOT</keyword>
<keyword>5G</keyword>
<keyword>IoT</keyword>
<keyword>Internet of Things</keyword>
<keyword>adaptation layer</keyword>
<keyword>UDP</keyword>
<keyword>IPv6</keyword>
<keyword>WSN</keyword>
<keyword>sensor network</keyword>
<keyword>wireless sensor network</keyword>
<keyword>802.15.4</keyword>
<keyword>constrained network</keyword>
<keyword>constrained node</keyword>
<keyword>constrained-node network</keyword>

    <abstract>
      <t>This document defines the Static Context Header Compression
      and fragmentation (SCHC) framework, which provides both a header compression
      mechanism and an optional fragmentation mechanism. SCHC has been
      designed for Low Power with Low-Power Wide Area Networks (LPWAN).</t> (LPWANs) in mind.</t>

      <t>SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.</t>
      <t>This document also specifies an optional fragmentation and
      reassembly mechanism. It can be used to support the IPv6 MTU
      requirement over the LPWAN technologies. Fragmentation is needed
      for IPv6 datagrams that, after SCHC compression or when such
      compression was not possible, still exceed the layer-2 Layer 2 maximum payload size.</t>
      <t>The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices.
This document standardizes the exchange over the LPWAN between two SCHC entities.
Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents.
Data models for the context and profiles are out of scope.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed for Low Power with Low-Power Wide Area Networks (LPWAN).</t> (LPWANs) in mind.</t>
      <t>LPWAN technologies impose some strict limitations on traffic. For instance, devices sleep most of the time and may only receive data during short periods of time after transmission, in order to preserve battery.
LPWAN technologies are also characterized by a greatly reduced data unit and/or payload size (see <xref target="RFC8376"/>).</t> target="RFC8376" format="default"/>).</t>
      <t>Header compression is needed for efficient Internet connectivity to a node within an LPWAN network. LPWAN. The following properties of LPWAN networks LPWANs can be exploited to get an efficient header compression:</t>

<t><list style="symbols">
  <t>The
      <ul spacing="normal">
        <li>The network topology is star-oriented, which means that all packets between the same source-destination pair follow the same path. For the needs of this document, the architecture can simply be described as Devices (Dev) exchanging information with LPWAN Application Servers (App) (Apps) through a Network Gateway (NGW).</t>
  <t>Because (NGW).</li>
        <li>Because devices embed built-in applications, the traffic flows to be compressed are known in advance. Indeed, new applications are less frequently installed in an LPWAN device, device than they are in a general-purpose computer or smartphone.</t>
</list></t> smartphone.</li>
      </ul>
      <t>SCHC compression uses a Context (a set of Rules) in which information about header fields is stored. This Context is static: the values of the header fields and the actions to do compression/decompression do not change over time. This avoids the need for complex resynchronization mechanisms.
Indeed, a return path may be more restricted/expensive, or may
sometimes be completely unavailable <xref target="RFC8376"/>. target="RFC8376" format="default"/>.
A compression protocol that relies on feedback is not compatible with the characteristics of such LPWANs.</t>
      <t>In most cases, a small Rule identifier is enough to represent the full IPv6/UDP headers. The SCHC header compression mechanism is independent of the specific LPWAN technology over which it is used.</t>
      <t>Furthermore, some LPWAN technologies do not provide a fragmentation functionality; to support the IPv6 MTU requirement of 1280 bytes <xref target="RFC8200"/>, target="RFC8200" format="default"/>, they require a fragmentation protocol at the adaptation layer below IPv6.
Accordingly, this document defines an optional fragmentation/reassembly mechanism for to help LPWAN technologies to support the IPv6 MTU requirement.</t>
      <t>This document defines generic functionality and offers flexibility with regard to parameters parameter settings
and mechanism choices. Technology-specific settings are expected to be grouped into Profiles specified in other documents.</t>
    </section>

    <section anchor="requirements-notation" title="Requirements Notation">

<t>The numbered="true" toc="default">
      <name>Requirements Notation</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="LPWAN-Archi" title="LPWAN Architecture"> numbered="true" toc="default">
      <name>LPWAN Architecture</name>
      <t>LPWAN network architectures are similar among them, but each LPWAN technology names architecture elements differently.
In this document, we use terminology from <xref target="RFC8376"/>, target="RFC8376" format="default"/>,
which identifies the following entities in a typical LPWAN network
      (see <xref target="Fig-LPWANarchi"/>):</t>

<t>o  Devices target="Fig-LPWANarchi" format="default"/>):</t>

      <ul spacing="normal">
      <li>Devices (Dev) are the end-devices or hosts (e.g., sensors, actuators, etc.). There can be a very high density of devices per radio gateway.</t>

<t>o  The Radio Gateway.</li>
      <li>The Radio Gateway (RGW) is the end point endpoint of the constrained link.</t>

<t>o  The link.</li>
      <li>The Network Gateway (NGW) is the interconnection node between the Radio Gateway and the Internet.</t>

<t>o Internet.</li>
      <li>The Application Server (App) is the end point endpoint of the application level application-level protocol on the Internet side.</t> side.</li></ul>
      <figure title="LPWAN Architecture, simplified anchor="Fig-LPWANarchi">
        <name>LPWAN Architecture (Simplified from that shown That Shown in RFC8376" anchor="Fig-LPWANarchi"><artwork><![CDATA[ RFC 8376)</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 ()   ()   ()       |
  ()  () () ()     / \       +---------+
() () () () () () /   \======|    ^    |             +-----------+
 ()  ()   ()     |           | <--|--> |             |Application|
()  ()  ()  ()  / \==========|    v    |=============|   (App)   Server  |
  ()  ()  ()   /   \         +---------+             +-----------+
 Dev            RGWs             NGW

]]></artwork></figure>                      App]]></artwork>
      </figure>
    </section>
    <section anchor="Term" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>This section defines the terminology and acronyms abbreviations used in this document.
It extends the terminology of <xref target="RFC8376"/>.</t> target="RFC8376" format="default"/>.</t>
      <t>The SCHC acronym is pronounced like “sheek” "sheek" in English (or “chic” "chic" in French). Therefore, this document writes “a "a SCHC Packet” Packet" instead of “an "an SCHC Packet”.</t>

<t><list style="symbols">
  <t>App: LPWAN Application, Packet".</t>
      <dl spacing="normal" indent="9">

        <dt>App:</dt><dd>LPWAN Application Server, as defined by <xref target="RFC8376"/>. An target="RFC8376" format="default"/>. It runs an application sending/receiving packets to/from the Dev.</t>
  <t>AppIID: Application Dev.</dd>
        <dt>AppIID:</dt><dd>Application Interface Identifier. The IID that
	identifies the application server interface.</t>
  <t>Bi: Bidirectional. Characterizes a Field Descriptor that applies to headers of packets traveling in either direction (Up and Dw, see this glossary).</t>
  <t>CDA: Compression/Decompression Action. Describes the pair of actions that are performed at the compressor to compress a header field and at the decompressor to recover the original value of the header field.</t>
  <t>Compression Residue. The App interface.</dd>
        <dt>Compression Residue:</dt><dd>The bits that remain to be sent (beyond the Rule ID RuleID itself) after applying the SCHC compression.</t>
  <t>Context: A compression.</dd>
        <dt>Context:</dt><dd>A set of Rules used to compress/decompress headers.</t>
  <t>Dev: Device, headers, or to fragment/reassemble a packet.</dd>
        <dt>Dev:</dt><dd>Device, as defined by <xref target="RFC8376"/>.</t>
  <t>DevIID: Device target="RFC8376" format="default"/>.</dd>
        <dt>DevIID:</dt><dd>Device Interface Identifier. The IID that identifies the Dev interface.</t>
  <t>DI: Direction Indicator. This field tells which direction of packet travel (Up, Dw or Bi) a Field Description applies to. This allows for asymmetric processing, using the same Rule.</t>
  <t>Dw: Downlink direction for compression/decompression, from SCHC C/D in interface.</dd>
        <dt>Downlink:</dt><dd>From the network App to SCHC C/D in the Dev.</t>
  <t>Field Description. A tuple containing identifier, value, matching operator and actions to be applied to a field.</t>
  <t>FID: Field Dev.</dd>
        <dt>IID:</dt><dd>Interface Identifier. This identifies See the protocol and field a Field Description applies to.</t>
  <t>FL: Field Length is IPv6 addressing architecture <xref target="RFC7136" format="default"/>.</dd>
        <dt>L2:</dt><dd>Layer 2. The immediate lower layer that SCHC interfaces with, for example an underlying LPWAN technology. It does not necessarily correspond to the length OSI model definition of the original packet header field. It Layer 2.</dd>
        <dt>L2 Word:</dt><dd>This is expressed as a number of bits for header fields the minimum subdivision of fixed lengths or as a type (e.g., variable, token length, …) for field lengths that are unknown at the time of Rule creation. The length of a header field is defined in the corresponding protocol specification (such as IPv6 or UDP).</t>
  <t>FP: when a Field is expected to appear multiple times in a header, Field Position specifies the occurrence this Field Description applies to
(for example, first uri-path option, second uri-path, etc. in a CoAP header), counting from 1. The value 0 is special and means “don’t care”, see <xref target="PProcessing"/>.</t>
  <t>IID: Interface Identifier. See the IPv6 addressing architecture <xref target="RFC7136"/>.</t>
  <t>L2: Layer two. The immediate lower layer SCHC interfaces with. It is provided by an underlying LPWAN technology. It does not necessarily correspond to the OSI model definition of Layer 2.</t>
  <t>L2 Word: this is the minimum subdivision of payload data payload data that the L2 will carry. In most L2 technologies, the L2 Word is an octet.
In bit-oriented radio technologies, the L2 Word might be a single bit.
The L2 Word size is assumed to be constant over time for each device.</t>
  <t>MO: Matching Operator. An operator used to match a value contained in a header field with a value contained in a Rule.</t>
  <t>Padding (P). Extra device.</dd>

        <dt>Padding:</dt><dd>Extra bits that may be appended by SCHC to a data unit that it passes down to the underlying Layer 2 L2 for transmission.
SCHC itself operates on bits, not bytes, and does not have any alignment prerequisite. See <xref target="Padding"/>.</t>
  <t>Profile: SCHC target="Padding" format="default"/>.</dd>
        <dt>Profile:</dt><dd>SCHC offers variations in the way it is operated, with a number of parameters listed in <xref target="SCHCParams"/>. target="SCHCParams" format="default"/>.
A Profile indicates a particular setting of all these parameters.
Both ends of a SCHC communication must be provisioned with the same Profile information and with the same set of Rules before the communication starts,
so that there is no ambiguity in how they expect to communicate.</t>
  <t>Rule: A set communicate.</dd>
        <dt>Rule:</dt><dd>Part of Field Descriptions.</t>
  <t>Rule ID (Rule Identifier): the Context that describes how a packet is compressed/decompressed or fragmented/reassembled.</dd>
        <dt>RuleID:</dt><dd>Rule Identifier.  An identifier for a Rule. SCHC C/D on both sides share the same Rule ID for Rule.</dd>
        <dt>SCHC:</dt><dd>Static Context Header Compression and fragmentation (SCHC), a given packet. A set of Rule IDs are used to support generic framework.</dd>
        <dt>SCHC C/D:</dt><dd>SCHC Compressor/Decompressor, or SCHC F/R functionality.</t>
  <t>SCHC C/D: Compression/Decompression. The SCHC Compressor/Decompressor. A entity or mechanism used on both sides, at the Dev and at the network, to achieve Compression/Decompression compression/decompression of headers.</t>
  <t>SCHC F/R: headers.</dd>
        <dt>SCHC F/R:</dt><dd>SCHC Fragmenter/Reassembler or SCHC Fragmentation / Reassembly. A Fragmentation/Reassembly. The SCHC entity or mechanism used on both sides, at the Dev and at the network, to achieve Fragmentation / Reassembly fragmentation/reassembly of SCHC Packets.</t>
  <t>SCHC Packet: A Packets.</dd>
        <dt>SCHC Packet:</dt><dd>A packet (e.g., an IPv6 packet) whose header has been compressed as per the header compression mechanism defined in this document. If the header compression process is unable to actually compress the packet header, the packet with the uncompressed header is still called a SCHC Packet (in this case, a Rule ID RuleID is used to indicate that the packet header has not been compressed). See <xref target="SCHComp"/> target="SCHComp" format="default"/> for more details.</t>
  <t>TV: Target value. A value contained in a Rule that will be matched with the value of a header field.</t>
  <t>Up: Uplink direction for compression/decompression, from details.</dd>
        <dt>Uplink:</dt><dd>From the Dev SCHC C/D to the network SCHC C/D.</t>
</list></t> App.</dd>
      </dl>
      <t>Additional terminology for the optional SCHC Fragmentation / Reassembly mechanism (SCHC F/R) F/R is found in <xref target="FragTools" format="default"/>.</t>
      <t>Additional terminology for SCHC C/D is found in <xref target="FragTools"/>.</t> target="schc-cd-rules" format="default"/>.</t>
    </section>
    <section anchor="Overview" title="SCHC overview"> numbered="true" toc="default">
      <name>SCHC Overview</name>
      <t>SCHC can be characterized as an adaptation layer between an upper layer (typically, (for example, IPv6) and an underlying layer (typically, (for example, an LPWAN technology).
SCHC comprises two sublayers (i.e. (i.e., the Compression sublayer and the Fragmentation sublayer), as shown in <xref target="Fig-IntroLayers"/>.</t> target="Fig-IntroLayers" format="default"/>.</t>
      <figure title="Protocol stack comprising anchor="Fig-IntroLayers">
        <name>Example of Protocol Stack Comprising IPv6, SCHC SCHC, and an LPWAN technology" anchor="Fig-IntroLayers"><artwork><![CDATA[ Technology</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
             +----------------+
             |      IPv6      |
          +- +----------------+
          |  |   Compression  |
    SCHC <   +----------------+
          |  |  Fragmentation |
          +- +----------------+
             |LPWAN technology|
             +----------------+

]]></artwork></figure>
             +----------------+]]></artwork>
      </figure>
      <t>Before an upper layer packet (e.g., an IPv6 packet) is transmitted to the underlying layer, header compression is first attempted. The resulting packet is called a SCHC Packet, "SCHC Packet", whether or not any compression is performed.
If needed by the underlying layer, the optional SCHC Fragmentation MAY fragmentation <bcp14>MAY</bcp14> be applied to the SCHC Packet.
The inverse operations take place at the receiver. This process is illustrated in <xref target="Fig-Operations"/>.</t> target="Fig-Operations" format="default"/>.</t>
      <figure title="SCHC operations anchor="Fig-Operations">
        <name>SCHC Operations at the Sender and the Receiver" anchor="Fig-Operations"><artwork><![CDATA[ Receiver</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
A packet (e.g., an IPv6 packet)
         |                                           ^
         v                                           |
+------------------+                      +--------------------+
| SCHC Compression |                      | SCHC Decompression |
+------------------+                      +--------------------+
         |                                           ^
         |   If no fragmentation (*)                 |
         +-------------- SCHC Packet  -------------->|
         |                                           |
         v                                           |
+--------------------+                       +-----------------+
| SCHC Fragmentation |                       | SCHC Reassembly |
+--------------------+                       +-----------------+
      |     ^                                     |     ^
      |     |                                     |     |
      |     +---------- SCHC ACK (+) -------------+     |
      |                                                 |
      +-------------- SCHC Fragments -------------------+

        Sender                                    Receiver

*: the decision to not to use SCHC Fragmentation fragmentation is left to each Profile. Profile
+: optional, depends on Fragmentation mode.

]]></artwork></figure> mode]]></artwork>
      </figure>
      <section anchor="schc-packet-format" title="SCHC numbered="true" toc="default">
        <name>SCHC Packet format"> Format</name>
        <t>The SCHC Packet is composed of the Compressed Header followed by the payload from the original packet (see <xref target="Fig-SCHCpckt"/>). target="Fig-SCHCpckt" format="default"/>).
The Compressed Header itself is composed of the Rule ID RuleID and a Compression Residue, which is the output of compressing the packet header with that the Rule identified by that RuleID (see <xref target="SCHComp"/>). target="SCHComp" format="default"/>).
The Compression Residue may be empty. Both the Rule ID RuleID and the Compression Residue potentially have a variable size, and are not necessarily a multiple of bytes in size.</t>
        <figure title="SCHC Packet" anchor="Fig-SCHCpckt"><artwork><![CDATA[ anchor="Fig-SCHCpckt">
          <name>SCHC Packet</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
|------- Compressed Header -------|
+---------------------------------+--------------------+
|  Rule ID  RuleID  |  Compression Residue |      Payload       |
+---------------------------------+--------------------+

]]></artwork></figure>
+---------------------------------+--------------------+]]></artwork>
        </figure>
      </section>
      <section anchor="FunctionalMapping" title="Functional mapping"> numbered="true" toc="default">
        <name>Functional Mapping</name>
        <t><xref target="Fig-archi"/> target="Fig-archi" format="default"/> maps the
	functional elements of <xref target="Fig-Operations"/> target="Fig-Operations"
	format="default"/> onto the LPWAN architecture elements of
	<xref target="Fig-LPWANarchi"/>.</t> target="Fig-LPWANarchi" format="default"/>.</t>

        <figure title="Architecture" anchor="Fig-archi"><artwork><![CDATA[ anchor="Fig-archi">
          <name>Architectural Mapping</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
        Dev                                               App
+----------------+                               +----+ +----+ +----+
| App1 App2 App3 |                               |App1| |App2| |App3|
|                |                               |    | |    | |    |
|       UDP      |                               |UDP | |UDP | |UDP |
|      IPv6      |                               |IPv6| |IPv6| |IPv6|
|                |                               |    | |    | |    |
|SCHC C/D and F/R|                               |    | |    | |    |
+--------+-------+                               +----+ +----+ +----+
         |  +---+     +---+    +----+    +----+    .      .      .
         +~ |RGW| === |NGW| == |SCHC| == |SCHC|...... |SCHC|..... Internet ....
            +---+     +---+    |F/R |    |C/D |
                               +----+    +----+
]]></artwork></figure>    +----+]]></artwork>
        </figure>
        <t>SCHC C/D and SCHC F/R are located on both sides of the LPWAN transmission, hereafter called “the Dev side” the "Dev side" and “the Network infrastructure side”.</t> the "Network Infrastructure side".</t>
        <t>The operation in the Uplink direction is as follows. The Device application uses IPv6 or IPv6/UDP protocols. Before sending the packets, the Dev compresses their headers using SCHC C/D and, C/D;
if the SCHC Packet resulting from the compression needs to be fragmented by SCHC, SCHC F/R is performed (see <xref target="Frag"/>). target="Frag" format="default"/>).
The resulting SCHC Fragments are sent to an LPWAN Radio Gateway (RGW) (RGW), which forwards them to a Network Gateway (NGW).
The NGW sends the data to a SCHC F/R for re-assembly reassembly (if needed) and then to the SCHC C/D for decompression.
After decompression, the packet can be sent over the Internet
to one or several LPWAN Application Servers (App).</t> Apps.</t>
        <t>The SCHC F/R and SCHC C/D on the Network infrastructure Infrastructure side can
	be part of the NGW, NGW or located in the Internet as long as a
	tunnel is established between them and the NGW.

For some LPWAN technologies, it may be suitable to locate the SCHC F/R
functionality nearer the NGW, in order to better deal with time constraints of such technologies.</t>
        <t>The SCHC C/Ds on both sides MUST <bcp14>MUST</bcp14> share the same set of Rules.
So MUST <bcp14>MUST</bcp14> the SCHC F/Rs on both sides.</t>
        <t>The operation in the Downlink direction is similar to that in the Uplink direction, only reversing the order in which the architecture elements are traversed.</t>
      </section>
    </section>
    <section anchor="RuleID" title="Rule ID">

<t>Rule IDs numbered="true" toc="default">
      <name>RuleID</name>
      <t>RuleIDs identify the Rules used for Compression/Decompression compression/decompression or
for Fragmentation/Reassembly.</t> fragmentation/reassembly.</t>
      <t>The scope of the Rule ID RuleID of a Compression/Decompression compression/decompression Rule is the link between the SCHC C/D in a given Dev and the corresponding SCHC C/D in the Network infrastructure Infrastructure side.
The scope of the Rule ID RuleID of a Fragmentation/Reassembly fragmentation/reassembly Rule is the link between the SCHC F/R in a given Dev and the corresponding SCHC F/R in the Network infrastructure Infrastructure side.
If such a link is bidirectional, the scope includes both directions.</t>
      <t>The RuleIDs are therefore specific to the Context related to one Dev. Hence, multiple Dev instances, which refer to different Contexts, <bcp14>MAY</bcp14> reuse the same RuleID for different Rules.
      On the Network Infrastructure side, in order to identify the correct Rule to be applied to Uplink traffic, the SCHC C/D or SCHC F/R needs to associate the RuleID with the Dev identifier.
      Similarly, for Downlink traffic, the SCHC C/D or SCHC F/R on the Network Infrastructure side first needs to identify the destination Dev before looking for the appropriate Rule (and associated RuleID) in the Context of that Dev.</t>
      <t>Inside their scopes, Rules for Compression/Decompression compression/decompression and Rules for Fragmentation/Reassembly fragmentation/reassembly share the same Rule ID RuleID space.</t>
      <t>The size of the Rule IDs RuleIDs is not specified in this document,
      as it is implementation-specific and can vary according to the
      LPWAN technology and the number of Rules, among others. other things. It is defined in Profiles.</t>
      <t>The Rule IDs RuleIDs are used:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>For SCHC C/D, to identify the Rule (i.e., the set of Field Descriptions) that is used to compress a packet header.  <list style="symbols">
      <t>At  </t>
          <ul spacing="normal">
            <li>At least one Rule ID MUST RuleID <bcp14>MUST</bcp14> be allocated to tagging packets for which SCHC compression was not possible (i.e., no matching compression Rule was found).</t>
    </list></t> found).</li>
          </ul>
        </li>
        <li>
          <t>In SCHC F/R, to identify the specific mode and settings of F/R fragmentation/reassembly for one direction of data traffic (Up (Uplink or Dw).  <list style="symbols">
      <t>When Downlink).  </t>
          <ul spacing="normal">
            <li>When SCHC F/R is used for both communication directions, at least two Rule ID RuleID values are needed for F/R, fragmentation/reassembly: one per direction of data traffic.
This is because F/R fragmentation/reassembly may entail control messages flowing in the reverse direction compared to data traffic.</t>
    </list></t>
</list></t> traffic.</li>
          </ul>
        </li>
      </ul>
    </section>
    <section anchor="SCHComp" title="Compression/Decompression"> numbered="true" toc="default">
      <name>Compression/Decompression</name>
      <t>Compression with SCHC
is based on using a set of Rules, called which constitutes the Context, Context of SCHC C/D, to compress or
      decompress headers. SCHC avoids Context synchronization traffic,
      which consumes considerable bandwidth in other header
      compression mechanisms such as RoHC RObust Header Compression (RoHC)
      <xref target="RFC5795"/>. target="RFC5795" format="default"/>. Since the content of
      packets is highly predictable in LPWAN networks, LPWANs, static Contexts
      can be stored beforehand. The Contexts MUST <bcp14>MUST</bcp14> be
      stored at both ends, and they can be learned by a provisioning protocol or
      protocol, by out of band out-of-band means, or they can be pre-provisioned. by pre-provisioning. The way the Contexts are provisioned is out of the scope of this document.</t>
      <section anchor="schc-cd-rules" title="SCHC numbered="true" toc="default">
        <name>SCHC C/D Rules"> Rules</name>
        <t>The main idea of the SCHC compression scheme is to transmit the Rule ID RuleID to the other end instead of sending known field values. This Rule ID RuleID identifies a Rule that matches the original packet values. Hence, when a value is known by both ends, it is only necessary to send the corresponding Rule ID RuleID over the LPWAN network. LPWAN.
The manner by which Rules are generated is out of the scope of this document. The Rules MAY <bcp14>MAY</bcp14> be changed at run-time run-time, but the mechanism is out of scope of this document.</t>
        <t>The SCHC C/D Context is a set of Rules.
See <xref target="Fig-ctxt"/> target="Fig-ctxt" format="default"/> for a high level, high-level, abstract representation of the Context.
The formal specification of the representation of the Rules is outside the scope of this document.</t>
        <t>Each Rule itself contains a list of Field Descriptions Descriptors composed of a Field Identifier (FID), a Field Length (FL), a Field Position (FP), a Direction Indicator (DI), a Target Value (TV), a Matching Operator (MO) (MO), and a Compression/Decompression Action (CDA).</t>
        <figure title="A Compression/Decompression Context" anchor="Fig-ctxt"><artwork><![CDATA[ anchor="Fig-ctxt">
          <name>A SCHC C/D Context</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  /-----------------------------------------------------------------\
  |                         Rule N                                  |
 /-----------------------------------------------------------------\|
 |                       Rule i                                    ||
/-----------------------------------------------------------------\||
|  (FID)            Rule 1                                        |||
|+-------+--+--+--+------------+-----------------+---------------+|||
||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||||
|+-------+--+--+--+------------+-----------------+---------------+|||
||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||||
|+-------+--+--+--+------------+-----------------+---------------+|||
||...    |..|..|..|   ...      | ...             | ...           ||||
|+-------+--+--+--+------------+-----------------+---------------+||/
||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||
|+-------+--+--+--+------------+-----------------+---------------+|/
|                                                                 |
\-----------------------------------------------------------------/

]]></artwork></figure>
\-----------------------------------------------------------------/]]></artwork>
        </figure>
        <t>A Rule does not describe how the compressor parses a packet header to find and identify each field (e.g., the IPv6 Source Address, the UDP Destination Port Port, or a CoAP URI path option).
It is assumed that there is a protocol parser alongside SCHC that is able to identify
all the fields encountered in the headers to be compressed,
and to label them with a Field ID.
Rules only describe the compression/decompression behavior for each header field, after it has been identified.</t>
        <t>In a Rule, the Field Descriptions Descriptors are listed in the order in which the fields appear in the packet header.
The Field Descriptions Descriptors describe the header fields with the following entries:</t>

<t><list style="symbols">
  <t>Field ID
        <ul spacing="normal">
          <li>Field Identifier (FID) designates a protocol and field (e.g., UDP Destination Port), unambiguously among all protocols that a SCHC compressor processes. In the presence of protocol nesting, the Field ID also identifies the nesting.</t>
  <t>Field nesting.</li>
          <li>Field Length (FL) represents the length of the original field. It can be either a fixed value (in bits) if the length is known when the Rule is created or a type if the length is variable. The length of a header field is defined by its own protocol specification (e.g., IPv6 or UDP). If the length is variable, the type defines the process to compute the length and its unit (bits, bytes…).</t>
  <t>Field bytes...).</li>
          <li>Field Position (FP): most often, a field only occurs once in a packet header.
However, some fields may occur multiple times. An example is the uri-path of CoAP.
FP indicates which occurrence this Field Description Descriptor applies to.
If FP is not specified in the Field Description, it takes the
The default value of is 1.
The value 1 designates the first occurrence.
The value 0 is special. It means “don’t care”, "don't care", see <xref target="PProcessing"/>.</t> target="PProcessing" format="default"/>.</li>
          <li>
            <t>A Direction Indicator (DI) indicates the packet direction(s) this Field Description Descriptor applies to. Three values are It allows for asymmetric processing, using the same Rule. Three values are possible:  <list style="symbols">
      <t>UPLINK (Up): this  </t>
            <dl spacing="normal" newline="false">
              <dt>Up:</dt><dd>this Field Description Descriptor is only applicable to packets sent by the Dev to the App,</t>
      <t>DOWNLINK (Dw): this traveling Uplink.</dd>
              <dt>Dw:</dt><dd>this Field Description Descriptor is only applicable to packets sent from the App to the Dev,</t>
      <t>BIDIRECTIONAL (Bi): this traveling Downlink.</dd>
              <dt>Bi:</dt><dd>this Field Description Descriptor is applicable to packets traveling both Up and Dw.</t>
    </list></t>
  <t>Target Uplink or Downlink.</dd>
            </dl>
          </li>
          <li>Target Value (TV) is the value used to match against the packet header field. The Target Value can be a scalar value of any type (integer, strings, etc.) or a more complex structure (array, list, etc.). The types and representations are out of scope for this document.</t>
  <t>Matching document.</li>
          <li>Matching Operator (MO) is the operator used to match the Field Value field value and the Target Value. The Matching Operator may require some parameters. MO is only used during the compression phase. The set of MOs defined in this document can be found in <xref target="chap-MO"/>.</t>
  <t>Compression Decompression target="chap-MO" format="default"/>.</li>
          <li>Compression/Decompression Action (CDA) describes the compression pair of actions that are performed at the compressor to compress a header field and decompression processes at the decompressor to be performed after recover the MO is applied. original value of the header field. Some CDAs might use parameter values for their operation. CDAs are used in both the compression and the decompression functions. The set of CDAs defined in this document can be found in <xref target="chap-CDA"/>.</t>
</list></t>

</section>
<section anchor="IDComp" title="Rule ID for SCHC C/D">

<t>Rule IDs are sent by the compression function in one side and are received for the decompression function in the other side.
In SCHC C/D, the Rule IDs are specific to the Context related to one Dev. Hence, multiple Dev instances, which refer to different header compression Contexts, MAY reuse the same Rule ID for different Rules.
On the Network infrastructure side, in order to identify the correct Rule to be applied, the SCHC Decompressor needs to associate the Rule ID with the Dev identifier.
Similarly, the SCHC Compressor on the Network infrastructure side first identifies the destination Dev before looking for the appropriate compression Rule (and associated Rule ID) in the Context of that Dev.</t> target="chap-CDA" format="default"/>.</li>
        </ul>
      </section>

      <section anchor="PProcessing" title="Packet processing"> numbered="true" toc="default">
        <name>Packet Processing</name>
        <t>The compression/decompression process follows several phases:</t>

<t><list style="symbols">
  <t>Compression
        <dl spacing="normal">

            <dt>Compression Rule selection: the selection:</dt><dd><t>the general idea is to browse the Rule set to find a Rule that has a matching
Field Descriptor (given the DI and FP) for all and only those header fields that appear in the packet being compressed.
The detailed algorithm is the following:  <list style="symbols">
      <t>The </t>
            <ul spacing="normal">
              <li>The first step is to check the Field Identifiers (FID). FIDs.
If any header field of the packet being examined cannot be matched with a Field Description Descriptor with the correct FID, the Rule MUST <bcp14>MUST</bcp14> be disregarded.
If any Field Description Descriptor in the Rule has a FID that cannot be matched to one of the header fields of the packet being examined, the Rule MUST <bcp14>MUST</bcp14> be disregarded.</t>
      <t>The disregarded.</li>
              <li>The next step is to match the Field Descriptions Descriptors by their direction, using the Direction Indicator (DI). DI. If any field of the packet header cannot be matched with a Field Description Descriptor with the correct FID and DI, the Rule MUST <bcp14>MUST</bcp14> be disregarded.</t>
      <t>Then disregarded.</li>
              <li>
                <t>Then, the Field Descriptions Descriptors are further selected according to Field Position (FP). FP. If any field of the packet header cannot be matched with a Field Description Descriptor with the correct FID, DI and FP, the Rule MUST <bcp14>MUST</bcp14> be disregarded.      <vspace blankLines='1'/>      </t>
                <t>
The value 0 for FP means “don’t care”, i.e. "don't care", i.e., the comparison of this Field Description’s Descriptor's FP with
the position of the field of the packet header being compressed
returns True, whatever that position.  FP=0 can be useful to build compression Rules for protocols protocol headers in which
some fields order is irrelevant. An example could be uri-queries in CoAP.
Care needs to be exercised when writing Rules containing FP=0 values.
Indeed, it may result in decompressed packets having fields ordered differently compared to the original packet.</t>
              </li>
              <li>
                <t>Once each header field has been associated with a Field Description Descriptor with matching FID, DI DI, and FP, each packet field’s field's value is then compared to the corresponding Target Value (TV) TV stored in the Rule for that specific field, using the matching operator (MO). MO.
If every field in the packet header satisfies the corresponding matching operators (MO) MOs of a Rule (i.e. (i.e., all MO results are True), that Rule is valid for use to compress the header.
Otherwise, the Rule MUST <bcp14>MUST</bcp14> be disregarded.      <vspace blankLines='1'/>      </t>
                <t>
This specification does not prevent multiple Rules from matching the above steps and therefore and, therefore, being valid for use.
Which Rule to use among multiple valid Rules is left to the implementation.
As long as the same Rule set is installed at both ends, this degree of freedom does not constitute an interoperability issue.</t>
      <t>If
              </li>
              <li>If no valid compression Rule is found, then the packet MUST <bcp14>MUST</bcp14> be sent uncompressed
using the Rule ID RuleID dedicated to this purpose (see <xref target="RuleID"/>). target="RuleID" format="default"/>).
The entire packet header is the Compression Residue (see <xref target="Fig-SCHCpckt"/>). target="Fig-SCHCpckt" format="default"/>).
Sending an uncompressed header is likely to require SCHC F/R.</t>
    </list></t>
  <t>Compression: if F/R.</li>
            </ul></dd>

          <dt>Compression:</dt><dd>if a valid Rule was is found, each field of the header is compressed according to the Compression/Decompression Actions (CDAs) CDAs of the Rule.
The fields are compressed in the order that the Field Descriptions Descriptors appear in the Rule.
The compression of each field results in a residue, which may be empty.
The Compression Residue for the packet header is the concatenation of the non-empty residues for each field of the header, in the order the Field Descriptions Descriptors appear in the Rule.
The order in which the Field Descriptions Descriptors appear in the Rule is therefore semantically important.</t>
</list></t> important.</dd>
        </dl>
        <figure title="Compression anchor="Fig-CompRes">
          <name>Compression Residue structure" anchor="Fig-CompRes"><artwork><![CDATA[ Structure</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
    |------------------- Compression Residue -------------------|
    +-----------------+-----------------+-----+-----------------+
    | field 1 residue | field 2 residue | ... | field N residue |
    +-----------------+-----------------+-----+-----------------+

]]></artwork></figure>

<t><list style="symbols">
  <t>Sending: The Rule ID
    +-----------------+-----------------+-----+-----------------+]]></artwork>
        </figure>
        <dl spacing="normal">
          <dt>Sending:</dt><dd>The RuleID is sent to the other end followed by jointly with the Compression Residue (which could be empty) or the uncompressed header, and directly followed by the payload (see <xref target="Fig-SCHCpckt"/>). target="Fig-SCHCpckt" format="default"/>).
The way the Rule ID RuleID is sent will be specified in the Profile and is out of the scope of the present document.
For example, it could be included in an L2 header or sent as part of the L2 payload.</t>
  <t>Decompression: when payload.</dd>

            <dt>Decompression:</dt><dd><t>when decompressing, on the Network infrastructure side Infrastructure side, the SCHC C/D needs to find the correct Rule based on the L2 address of the Dev; in this way, it can use the DevIID and the Rule ID. Dev.&nbsp; On the Dev side, only the Rule ID RuleID is needed to identify the correct Rule since the Dev typically only holds Rules that apply to itself.  <vspace blankLines='1'/>  </t>
            <t>
This Rule describes the compressed header format. From this, the decompressor determines the order of the residues, the fixed-sized fixed-size or variable-sized variable-size nature of each residue (see <xref target="var-length-field"/>), target="var-length-field" format="default"/>),
and the size of the fixed-sized fixed-size residues.  <vspace blankLines='1'/>
From  </t>
            <t>
Therefore, from the received compressed header, it can therefore retrieve all the residue values and associate them to the corresponding header fields.  <vspace blankLines='1'/>  </t>
            <t>
For each field in the header, the receiver applies the CDA action associated to with that field in order to reconstruct the original header field value. The CDA application order can be different from the order in which the fields are listed in the Rule. In particular, Compute-* MUST <bcp14>MUST</bcp14> be applied after the application of the CDAs of all the fields it computes on.</t>
</list></t>
          </dd>
        </dl>
      </section>
      <section anchor="chap-MO" title="Matching operators">

<t>Matching Operators (MOs) numbered="true" toc="default">
        <name>Matching Operators</name>
        <t>MOs are functions used by both at the compression side of SCHC C/D endpoints. C/D. They are not typed and can be applied to integer, string or any other data type. The result of the operation can either be True or False. The following MOs are defined as follows:</t>

<t><list style="symbols">
  <t>equal: The defined:</t>
        <dl spacing="normal">
          <dt>equal:</dt><dd>The match result is True if the field value in the packet matches the TV.</t>
  <t>ignore: No TV.</dd>
          <dt>ignore:</dt><dd>No matching is attempted between the
	  field value in the packet and the TV in the Rule. The result
	  is always true.</t>
  <t>MSB(x): A True.</dd>

          <dt>MSB(x):</dt><dd>A match is obtained if the most significant (leftmost) x bits of the packet header field value are equal to the TV in the Rule. The x parameter of the MSB MO indicates how many bits are involved in the comparison. If the FL is described as variable, the x parameter must be a multiple of the FL unit. For example, x must be multiple of 8 if the unit of the variable length is bytes.</t>
  <t>match-mapping: With bytes.</dd>
          <dt>match-mapping:</dt><dd>With match-mapping, the Target Value TV is a list of values. Each value of the list is identified by an index. Compression is achieved by sending the index instead of the original header field value. This operator matches if the header field value is equal to one of the values in the target list.</t>
</list></t> list.</dd>
        </dl>
      </section>
      <section anchor="chap-CDA" title="Compression Decompression numbered="true" toc="default">
        <name>Compression/Decompression Actions (CDA)"> (CDA)</name>
        <t>The Compression Decompression Action (CDA) describes CDA specifies the actions taken during the compression of header fields and the inverse action taken by the decompressor to restore the original value.</t>

<texttable title="Compression value.
        The CDAs defined by this document are described in detail in <xref target="NotSentCDA" format="default"/> to <xref target="compute-" format="default"/>.
        They are summarized in <xref target="Fig-function" format="default"/>.</t>
        <table anchor="Fig-function" align="center">
          <name>Compression and Decompression Actions" anchor="Fig-function">
      <ttcol align='left'>Action</ttcol>
      <ttcol align='left'>Compression</ttcol>
      <ttcol align='left'>Decompression</ttcol>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>not-sent</c>
      <c>elided</c>
      <c>use Actions</name>
          <thead>
            <tr>
              <th align="left">Action</th>
              <th align="left">Compression</th>
              <th align="left">Decompression</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">not-sent</td>
              <td align="left">elided</td>
              <td align="left">use TV stored in Rule</c>
      <c>value-sent</c>
      <c>send</c>
      <c>use Rule</td>
            </tr>
            <tr>
              <td align="left">value-sent</td>
              <td align="left">send</td>
              <td align="left">use received value</c>
      <c>mapping-sent</c>
      <c>send index</c>
      <c>retrieve value</td>
            </tr>
            <tr>
              <td align="left">mapping-sent</td>
              <td align="left">send index</td>
              <td align="left">retrieve value from TV list</c>
      <c>LSB</c>
      <c>send LSB</c>
      <c>concat. list</td>
            </tr>
            <tr>
              <td align="left">LSB</td>
              <td align="left">send least significant bits (LSB)</td>
              <td align="left">concatenate TV and received value</c>
      <c>compute-*</c>
      <c>elided</c>
      <c>recompute value</td>
            </tr>
            <tr>
              <td align="left">compute-*</td>
              <td align="left">elided</td>
              <td align="left">recompute at decompressor</c>
      <c>DevIID</c>
      <c>elided</c>
      <c>build decompressor</td>
            </tr>
            <tr>
              <td align="left">DevIID</td>
              <td align="left">elided</td>
              <td align="left">build IID from L2 Dev addr</c>
      <c>AppIID</c>
      <c>elided</c>
      <c>build addr</td>
            </tr>
            <tr>
              <td align="left">AppIID</td>
              <td align="left">elided</td>
              <td align="left">build IID from L2 App addr</c>
</texttable>

<t><xref target="Fig-function"/> summarizes the basic actions that can be used to compress and decompress a field. The addr</td>
            </tr>
          </tbody>
        </table>
        <t>The first column shows the action’s action's name. The second and third columns show the compression and decompression behaviors for each action.</t>
        <section anchor="fixed-length-field" title="processing fixed-length fields"> numbered="true" toc="default">
          <name>Processing Fixed-Length Fields</name>
          <t>If the field is identified in the Field Description Descriptor as being of fixed length, then applying the CDA to compress this field results in a fixed amount of bits.
The residue for that field is simply the bits resulting from applying the CDA to the field.
This value may be empty (e.g., not-sent CDA), in which case the field residue is absent from the Compression Residue.</t>
          <figure title="fixed sized field residue structure" anchor="Fig-FieldResFixLength"><artwork><![CDATA[ anchor="Fig-FieldResFixLength">
            <name>Fixed-Size Field Residue Structure</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
|- field residue -|
+-----------------+
|      value      |
+-----------------+

]]></artwork></figure>
+-----------------+]]></artwork>
          </figure>
        </section>
        <section anchor="var-length-field" title="processing variable-length fields"> numbered="true" toc="default">
          <name>Processing Variable-Length Fields</name>
          <t>If the field is identified in the Field Description Descriptor as being of variable length,
then applying the CDA to compress this field may result in a value of fixed size
(e.g., not-sent or mapping-sent)
or of variable size (e.g., value-sent or LSB).
In the latter case, the residue for that field is the bits that result from applying the CDA to the field, preceded with the size of the value.
The most significant bit of the size is stored to the left (leftmost bit of the residue field).</t>
          <figure title="variable sized field residue structure" anchor="Fig-FieldResVarLength"><artwork><![CDATA[ anchor="Fig-FieldResVarLength">
            <name>Variable-Size Field Residue Structure</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
|--- field residue ---|
+-------+-------------+
|  size |    value    |
+-------+-------------+

]]></artwork></figure>
+-------+-------------+]]></artwork>
          </figure>
          <t>The size (using the unit defined in the FL) is encoded on 4, 12 12, or 28 bits as follows:</t>

<t><list style="symbols">
  <t>If
          <ul spacing="normal">
            <li>If the size is between 0 and 14, it is encoded as a 4 bits 4-bit unsigned integer.</t>
  <t>Sizes integer.</li>
            <li>Sizes between 15 and 254 are encoded as 0b1111 followed by the 8 bits 8-bit unsigned integer.</t>
  <t>Larger integer.</li>
            <li>Larger sizes are encoded as 0xfff followed by the 16 bits 16-bit unsigned integer.</t>
</list></t> integer.</li>
          </ul>
          <t>If the field is identified in the Field Description Descriptor as being of variable length and this field is not present in the packet header being compressed, size 0 MUST <bcp14>MUST</bcp14> be sent to denote its absence.</t>
        </section>
        <section anchor="NotSentCDA" title="not-sent CDA"> numbered="true" toc="default">
          <name>Not-Sent CDA</name>
          <t>The not-sent action can be used when the field value is
	  specified in a Rule and therefore and, therefore, known by both the
	  Compressor and the Decompressor. This action SHOULD
	  <bcp14>SHOULD</bcp14> be used with the “equal” "equal" MO. If MO is “ignore”,
	  "ignore", there is a risk to have of having a decompressed field
	  value that is different from the original field that was compressed.</t>
          <t>The compressor does not send any residue for a field on which not-sent compression is applied.</t>
          <t>The decompressor restores the field value with the Target Value TV stored in the matched Rule identified by the received Rule ID.</t> RuleID.</t>
        </section>
        <section anchor="value-sent-cda" title="value-sent CDA"> numbered="true" toc="default">
          <name>Value-Sent CDA</name>
          <t>The value-sent action can be used when the field value is not known by both the Compressor and the Decompressor. The field is sent in its entirety, using the same bit order as in the original packet header.</t>
          <t>If this action is performed on a variable length variable-length field, the size of the residue value (using the units defined in FL) MUST <bcp14>MUST</bcp14> be sent as described in <xref target="var-length-field"/>.</t> target="var-length-field" format="default"/>.</t>
          <t>This action is generally used with the “ignore” "ignore" MO.</t>
        </section>
        <section anchor="mapping-sent-cda" title="mapping-sent CDA"> numbered="true" toc="default">
          <name>Mapping-Sent CDA</name>
          <t>The mapping-sent action is used to send an index (the index into the Target Value TV list of values) instead of the original value. This action is used together with the “match-mapping” "match-mapping" MO.</t>
          <t>On the compressor side, the match-mapping Matching Operator MO searches the TV for a match with the header field value. The mapping-sent CDA then sends the corresponding index as the field residue.
The most significant bit of the index is stored to the left (leftmost bit of the residue field).</t>
          <t>On the decompressor side, the CDA uses the received index to restore the field value by looking up the list in the TV.</t>
          <t>The number of bits sent is the minimal size for coding all the possible indices.</t>
          <t>The first element in the list MUST <bcp14>MUST</bcp14> be represented by index value 0, and successive elements in the list MUST <bcp14>MUST</bcp14> have indices incremented by 1.</t>
        </section>
        <section anchor="lsb-cda" title="LSB CDA"> numbered="true" toc="default">
          <name>LSB CDA</name>
          <t>The LSB action is used together with the “MSB(x)” "MSB(x)" MO to avoid sending the most significant part of the packet field if that part is already known by the receiving end.</t>
          <t>The compressor sends the Least Significant Bits LSBs as the field residue value.
The number of bits sent is the original header field length minus the length specified in the MSB(x) MO.
The bits appear in the residue in the same bit order as in the original packet header.</t>
          <t>The decompressor concatenates the x most significant bits
	  of Target Value the TV and the received residue value.</t>
          <t>If this action is performed on a variable length variable-length field, the size of the residue value (using the units defined in FL) MUST <bcp14>MUST</bcp14> be sent as described in <xref target="var-length-field"/>.</t> target="var-length-field" format="default"/>.</t>
        </section>
        <section anchor="deviid-appiid-cda" title="DevIID, numbered="true" toc="default">
          <name>DevIID, AppIID CDA"> CDA</name>
          <t>These actions are used to process respectively the Dev and the App Interface Identifiers (DevIID DevIID and AppIID) AppIID of the IPv6 addresses. addresses, respectively. AppIID CDA is less common since most current LPWAN technologies frames contain a single L2 address, which is the Dev’s Dev's address.</t>
          <t>The IID DevIID value MAY <bcp14>MAY</bcp14> be computed from the Device Dev ID present in the L2 header, or from some other stable identifier. The computation is specific to each Profile and MAY <bcp14>MAY</bcp14> depend on the Device Dev ID size.</t>
          <t>In the downlink direction (Dw), Downlink direction, at the compressor, the DevIID CDA may be used to generate the L2 addresses on the LPWAN, based on the packet’s packet's Destination Address.</t>
        </section>
        <section anchor="compute-" title="Compute-*"> numbered="true" toc="default">
          <name>Compute-*</name>
          <t>Some fields can be elided at the compressor and recomputed locally at the decompressor.</t>
          <t>Because the field is uniquely identified by its Field ID FID (e.g., UDP IPv6 length), the relevant protocol specification unambiguously defines the algorithm for such computation.</t>

<t>Examples
          <t>An example of fields a field that know knows how to recompute themselves are UDP length, itself is IPv6 length and UDP checksum.</t> length.</t>
        </section>
      </section>
    </section>
    <section anchor="Frag" title="Fragmentation/Reassembly"> numbered="true" toc="default">
      <name>Fragmentation/Reassembly</name>
      <section anchor="overview" title="Overview"> numbered="true" toc="default">
        <name>Overview</name>
        <t>In LPWAN technologies, the L2 MTU typically ranges from tens to hundreds of bytes.
Some of these technologies do not have an internal fragmentation/reassembly mechanism.</t>
        <t>The optional SCHC Fragmentation/Reassembly (SCHC F/R) F/R functionality enables such LPWAN technologies to comply with the IPv6 MTU requirement of 1280 bytes <xref target="RFC8200"/>. target="RFC8200" format="default"/>.
It is OPTIONAL <bcp14>OPTIONAL</bcp14> to implement per this specification, but Profiles may specify that it is REQUIRED.</t> <bcp14>REQUIRED</bcp14>.</t>
        <t>This specification includes several SCHC F/R modes, which allow for a range of reliability options such as optional SCHC Fragment retransmission.
More modes may be defined in the future.</t>
        <t>The same SCHC F/R mode MUST <bcp14>MUST</bcp14> be used for all SCHC Fragments of a given SCHC Packet.
This document does not specify which mode(s) must be implemented and used over a specific LPWAN technology. That information will be given in Profiles.</t>
        <t>SCHC allows transmitting non-fragmented SCHC Packet concurrently with fragmented SCHC Packets.
In addition, SCHC F/R provides protocol elements that allow transmitting several fragmented SCHC Packets concurrently, i.e. i.e., interleaving the transmission of fragments from different fragmented SCHC Packets.
A Profile MAY <bcp14>MAY</bcp14> restrict the latter behavior.</t>
        <t>The L2 Word size (see <xref target="Term"/>) target="Term" format="default"/>) determines the encoding of some messages.
SCHC F/R usually generates SCHC Fragments and SCHC ACKs that are multiples of L2 Words.</t>
      </section>
      <section anchor="FragTools" title="SCHC numbered="true" toc="default">
        <name>SCHC F/R Protocol Elements"> Elements</name>
        <t>This subsection describes the different elements that are used to enable the SCHC F/R functionality defined in this document.
These elements include the SCHC F/R messages, tiles, windows, bitmaps, counters, timers timers, and header fields.</t>
        <t>The elements are described here in a generic manner. Their application to each SCHC F/R mode is found in <xref target="FragModes"/>.</t> target="FragModes" format="default"/>.</t>
        <section anchor="messages" title="Messages"> numbered="true" toc="default">
          <name>Messages</name>
          <t>SCHC F/R defines the following messages:</t>

<t><list style="symbols">
  <t>SCHC Fragment: A
          <dl spacing="normal">
            <dt>SCHC Fragment:</dt><dd>A message that carries part of a SCHC Packet from the sender to the receiver.</t>
  <t>SCHC ACK: An receiver.</dd>
            <dt>SCHC ACK:</dt><dd>An acknowledgement for fragmentation, by the receiver to the sender.
This message is used to indicate whether or not the reception of pieces of,
or the whole of of, the fragmented SCHC Packet, Packet was successful.</t>
  <t>SCHC successful.</dd>
            <dt>SCHC ACK REQ: A REQ:</dt><dd>A request by the sender for a SCHC ACK from the receiver.</t>
  <t>SCHC Sender-Abort: A receiver.</dd>
            <dt>SCHC Sender-Abort:</dt><dd>A message by the sender telling the receiver that it has aborted the transmission of a fragmented SCHC Packet.</t>
  <t>SCHC Receiver-Abort: A Packet.</dd>
            <dt>SCHC Receiver-Abort:</dt><dd>A message by the receiver to tell the sender to abort the transmission of a fragmented SCHC Packet.</t>
</list></t> Packet.</dd>
          </dl>
          <t>The format of these messages is provided in <xref target="Fragfor"/>.</t> target="Fragfor" format="default"/>.</t>
        </section>
        <section anchor="OtherTools" title="Tiles, numbered="true" toc="default">
          <name>Tiles, Windows, Bitmaps, Timers, Counters"> Counters</name>
          <section anchor="tiles" title="Tiles"> numbered="true" toc="default">
            <name>Tiles</name>
            <t>The SCHC Packet is fragmented into pieces, hereafter called tiles. "tiles".
The tiles MUST <bcp14>MUST</bcp14> be non-empty and pairwise disjoint.
Their union MUST <bcp14>MUST</bcp14> be equal to the SCHC Packet.</t>
            <t>See <xref target="Fig-TilesExample"/> target="Fig-TilesExample" format="default"/> for an example.</t>
            <figure title="a SCHC anchor="Fig-TilesExample">
              <name>SCHC Packet fragmented Fragmented in tiles" anchor="Fig-TilesExample"><artwork><![CDATA[ Tiles</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
                                SCHC Packet
       +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+
        +----+--+-----+---+----+-+---+-----+...-----+----+---+------+
Tiles   |    |  |     |   |    | |   |     |        |    |   |      |      |
       +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+

]]></artwork></figure>
        +----+--+-----+---+----+-+---+-----+...-----+----+---+------+]]></artwork>
            </figure>
            <t>Modes (see <xref target="FragModes"/>) MAY target="FragModes" format="default"/>) <bcp14>MAY</bcp14> place additional constraints on tile sizes.</t>
            <t>Each SCHC Fragment message carries at least one tile in its Payload, if the Payload field is present.</t>
          </section>
          <section anchor="Windows" title="Windows"> numbered="true" toc="default">
            <name>Windows</name>
            <t>Some SCHC F/R modes may handle successive tiles in groups, called windows.</t>
            <t>If windows are used</t>

<t><list style="symbols">
  <t>all used:</t>
            <ul spacing="normal">
              <li>all the windows of a SCHC Packet, except the last one, MUST <bcp14>MUST</bcp14> contain the same number of tiles.
This number is WINDOW_SIZE.</t>
  <t>WINDOW_SIZE MUST WINDOW_SIZE.</li>
              <li>WINDOW_SIZE <bcp14>MUST</bcp14> be specified in a Profile.</t>
  <t>the Profile.</li>
              <li>the windows are numbered.</t>
  <t>their numbered.</li>
              <li>their numbers MUST <bcp14>MUST</bcp14> increment by 1 from 0 upward, from the start of the SCHC Packet to its end.</t>
  <t>the end.</li>
              <li>the last window MUST <bcp14>MUST</bcp14> contain WINDOW_SIZE tiles or less.</t>
  <t>tiles less.</li>
              <li>tiles are numbered within each window.</t>
  <t>the window.</li>
              <li>the tile indices MUST <bcp14>MUST</bcp14> decrement by 1 from WINDOW_SIZE - 1 downward, looking from the start of the SCHC Packet toward its end.</t>
  <t>each end.</li>
              <li>therefore, each tile of a SCHC Packet is therefore uniquely identified by a window number and a tile index within this window.</t>
</list></t> window.</li>
            </ul>
            <t>See <xref target="Fig-WindowsExample"/> target="Fig-WindowsExample" format="default"/> for an example.</t>
            <figure title="a SCHC anchor="Fig-WindowsExample">
              <name>SCHC Packet fragmented Fragmented in tiles grouped Tiles Grouped in 29 windows, Windows, with WINDOW_SIZE = 5" anchor="Fig-WindowsExample"><artwork><![CDATA[
         +---------------------------------------------...-------------+ 5</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
        +---------------------------------------------...-----------+
        |                       SCHC Packet                         |
         +---------------------------------------------...-------------+

Tile #
        +---------------------------------------------...-----------+

Tile#   | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 |     | 0 | 4 | 3 |
Window # |3|
Window# |-------- 0 --------|-------- 1 --------|- 2  ... 27 -|-- 28 -|

]]></artwork></figure> -|- 28-|]]></artwork>
            </figure>
            <t><xref target="MultWinSizes"/> target="MultWinSizes" format="default"/> discusses the benefits of selecting one among multiple window sizes depending on the size of the SCHC Packet to be fragmented.</t>
            <t>When windows are used</t>

<t><list style="symbols">
  <t>Bitmaps used:</t>
            <ul spacing="normal">
              <li>Bitmaps (see <xref target="Bitmap"/>) MAY target="Bitmap" format="default"/>) <bcp14>MAY</bcp14> be sent back by the receiver to the sender in a SCHC ACK message.</t>
  <t>A message.</li>
              <li>A Bitmap corresponds to exactly one Window.</t>
</list></t> Window.</li>
            </ul>
          </section>
          <section anchor="Bitmap" title="Bitmaps"> numbered="true" toc="default">
            <name>Bitmaps</name>
            <t>Each bit in the Bitmap for a window corresponds to a tile in the window.
Each
Therefore, each Bitmap has therefore WINDOW_SIZE bits.
The bit at the left-most leftmost position corresponds to the tile numbered WINDOW_SIZE - 1.
Consecutive bits, going right, correspond to sequentially decreasing tile indices.
In Bitmaps for windows that are not the last one of a SCHC Packet,
the bit at the right-most rightmost position corresponds to the tile numbered 0.
In the Bitmap for the last window,
the bit at the right-most rightmost position corresponds either to the tile numbered 0 or to a tile that is sent/received as “the "the last one of the SCHC Packet” Packet" without explicitly stating its number (see <xref target="LastFrag"/>).</t> target="LastFrag" format="default"/>).</t>
            <t>At the receiver</t>

<t><list style="symbols">
  <t>a receiver:</t>
            <ul spacing="normal">
              <li>a bit set to 1 in the Bitmap indicates that a tile associated with that bit position has been correctly received for that window.</t>
  <t>a window.</li>
              <li>a bit set to 0 in the Bitmap indicates that there has been no tile correctly received, associated with that bit position, for that window.
Possible reasons include that the tile was not sent at all, not received, or received with errors.</t>
</list></t> errors.</li>
            </ul>
          </section>
          <section anchor="MiscTools" title="Timers numbered="true" toc="default">
            <name>Timers and counters"> Counters</name>
            <t>Some SCHC F/R modes can use the following timers and counters</t>

<t><list style="symbols">
  <t>Inactivity Timer: a counters:</t>
            <dl spacing="normal">
              <dt>Inactivity Timer:</dt><dd>a SCHC Fragment receiver uses this timer to abort waiting for a SCHC F/R message.</t>
  <t>Retransmission Timer: a message.</dd>
              <dt>Retransmission Timer:</dt><dd>a SCHC Fragment sender uses this timer to abort waiting for an expected SCHC ACK.</t>
  <t>Attempts: this ACK.</dd>
              <dt>Attempts:</dt><dd>this counter counts the requests for SCHC ACKs, up to MAX_ACK_REQUESTS.</t>
</list></t> MAX_ACK_REQUESTS.</dd>
            </dl>
          </section>
        </section>
        <section anchor="IntegrityChecking" title="Integrity Checking"> numbered="true" toc="default">
          <name>Integrity Checking</name>
          <t>The integrity of the fragmentation-reassembly process of a SCHC Packet MUST <bcp14>MUST</bcp14> be checked at the receive end.
A Profile MUST <bcp14>MUST</bcp14> specify how integrity checking is performed.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that integrity checking be performed by computing a Reassembly Check Sequence (RCS)
based on the SCHC Packet at the sender side
and transmitting it to the receiver for comparison with the RCS locally computed after reassembly.</t>
          <t>The RCS supports UDP checksum elision by SCHC C/D (see <xref target="UDPchecksum"/>).</t> target="UDPchecksum" format="default"/>).</t>
          <t>The CRC32 polynomial 0xEDB88320 (i.e., the reversed polynomial representation, which is
used in the Ethernet standard <xref target="ETHERNET"/>) target="ETHERNET" format="default"/>) is RECOMMENDED <bcp14>RECOMMENDED</bcp14> as the default algorithm for computing the
RCS.</t>
          <t>The RCS MUST <bcp14>MUST</bcp14> be computed on the full SCHC Packet concatenated with the padding bits, if any, of the SCHC Fragment carrying the last tile.
The rationale is that the SCHC reassembler has no way of knowing the boundary between the last tile and the padding bits.
Indeed, this requires decompressing the SCHC Packet, which is out of the scope of the SCHC reassembler.</t>
          <t>The concatenation of the complete SCHC Packet and any padding bits, if present, of the last SCHC Fragment does not
generally constitute an integer number of bytes.
CRC libraries are usually byte-oriented. byte oriented.
It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the concatenation of the
complete SCHC Packet and any last fragment padding bits be zero-extended to the next byte boundary and
that the RCS be computed on that byte array.</t>
        </section>
        <section anchor="HeaderFields" title="Header Fields"> numbered="true" toc="default">
          <name>Header Fields</name>
          <t>The SCHC F/R messages contain the following fields (see the formats in <xref target="Fragfor"/>):</t>

<t><list style="symbols">
  <t>Rule ID: this target="Fragfor" format="default"/>):</t>
          <dl spacing="normal">

              <dt>RuleID:</dt><dd><t>this field is present in all the SCHC F/R messages. The Rule identifies  <list style="symbols">
      <t>that identifies:</t>
              <ul spacing="normal">
                <li>that a SCHC F/R message is being carried, as opposed to an unfragmented SCHC Packet,</t>
      <t>which Packet,</li>
                <li>which SCHC F/R mode is used</t>
      <t>in used,</li>
                <li>in case this mode uses windows, what the value of
		WINDOW_SIZE is,</t>
      <t>what is, and</li>
                <li>what other optional fields are present and what the field sizes are.</t>
    </list> are.</li>
              </ul>
              <t>
The Rule tells apart a non-fragmented SCHC Packet from SCHC Fragments.
It will also tell apart SCHC Fragments of fragmented SCHC Packets that use different SCHC F/R modes or different parameters.
Interleaved
Therefore, interleaved transmission of these is therefore possible.  <vspace blankLines='1'/>  </t>
              <t>
All SCHC F/R messages pertaining to the same SCHC Packet MUST <bcp14>MUST</bcp14> bear the same Rule ID.</t>
  <t>Datagram RuleID.</t>
            </dd>

              <dt>Datagram Tag (DTag).
This (DTag):</dt><dd><t>This field allows differentiating SCHC F/R messages belonging to different SCHC Packets
that may be using the same Rule ID RuleID simultaneously.
Hence, it allows interleaving fragments of a new SCHC Packet with fragments of a previous SCHC Packet under the same Rule ID.  <vspace blankLines='1'/> RuleID.  </t>
              <t>
The size of the DTag field (called T, "T", in bits) is defined by each Profile for each Rule ID. RuleID.
When T is 0, the DTag field does not appear in the SCHC F/R messages and the DTag value is defined as 0.  <vspace blankLines='1'/>  </t>
              <t>
When T is 0, there can be no more than one fragmented SCHC Packet in transit for each fragmentation Rule ID.  <vspace blankLines='1'/> RuleID.  </t>
              <t>
	      If T is not 0, DTag  <list style="symbols">
      <t>MUST DTag:  </t>

              <ul spacing="normal">
                <li><bcp14>MUST</bcp14> be set to the same value for all the SCHC F/R messages related to the same fragmented SCHC Packet,</t>
      <t>MUST Packet, and</li>
                <li><bcp14>MUST</bcp14> be set to different values for SCHC F/R messages related to different SCHC Packets that are being fragmented under the same Rule ID, RuleID and whose transmission may overlap.</t>
    </list></t>
  <t>W: The overlap.</li>
              </ul>
            </dd>

              <dt>W:</dt><dd><t>The W field is optional. It is only present if windows are used.
Its presence and size (called M, "M", in bits) is defined by each SCHC F/R mode and each Profile for each Rule ID.  <vspace blankLines='1'/> RuleID.  </t>
              <t>
This field carries information pertaining to the window a SCHC F/R message relates to.
If present, W MUST <bcp14>MUST</bcp14> carry the same value for all the SCHC F/R messages related to the same window.
Depending on the mode and Profile, W may carry the full window number, or just the least significant bit LSB or any other partial representation of the window number.</t>
  <t>Fragment
            </dd>

              <dt>Fragment Compressed Number (FCN). The (FCN):</dt><dd><t>The FCN field is present in the SCHC Fragment Header.
Its size (called N, "N", in bits) is defined by each Profile for each Rule ID.  <vspace blankLines='1'/> RuleID.  </t>
              <t>
This field conveys information about the progress in the sequence of tiles being transmitted by SCHC Fragment messages.
For example, it can contain a partial, efficient representation of a larger-sized tile index.
The description of the exact use of the FCN field is left to each SCHC F/R mode.
However, two values are reserved for special purposes. They help control the SCHC F/R process:  <list style="symbols">
      <t>The  </t>
              <ul spacing="normal">
                <li>The FCN value with all the bits equal to 1 (called All-1) "All-1") signals that the very last tile of a SCHC Packet has been transmitted.
By extension, if windows are used, the last window of a packet is called the All-1 window.</t>
      <t>If "All-1" window.</li>
                <li>If windows are used, the FCN value with all the bits equal to 0 (called All-0) "All-0") signals
the last tile of a window that is not the last one of the SCHC packet.
By extension, such a window is called an All-0 window.</t>
    </list></t>
  <t>Reassembly "All-0 window".</li>
              </ul>
            </dd>

              <dt>Reassembly Check Sequence (RCS).
This (RCS):</dt><dd><t>This field only appears in the All-1 SCHC Fragments.
Its size (called U, "U", in bits) is defined by each Profile for each Rule ID.  <vspace blankLines='1'/> RuleID.  </t>
              <t>
See <xref target="IntegrityChecking"/> target="IntegrityChecking" format="default"/> for the RCS default size, default polynomial and details on RCS computation.</t>
  <t>C
            </dd>

              <dt>C (integrity Check): C Check):</dt><dd><t>C is a 1-bit field.
This field is used in the SCHC ACK message to report on the reassembled SCHC Packet integrity check (see <xref target="IntegrityChecking"/>).  <vspace blankLines='1'/> target="IntegrityChecking" format="default"/>).  </t>
              <t>
A value of 1 tells that the integrity check was performed and is successful.
A value of 0 tells that the integrity check was not performed, performed or that is it was a failure.</t>
  <t>Compressed Bitmap. The
            </dd>

              <dt>Compressed Bitmap:</dt><dd><t>The Compressed Bitmap is used together with windows and Bitmaps (see <xref target="Bitmap"/>). target="Bitmap" format="default"/>).
Its presence and size is defined for each SCHC F/R mode for each Rule ID.  <vspace blankLines='1'/> RuleID.  </t>
              <t>
This field appears in the SCHC ACK message to report on the receiver Bitmap (see <xref target="BitmapTrunc"/>).</t>
</list></t> target="BitmapTrunc" format="default"/>).</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="Fragfor" title="SCHC numbered="true" toc="default">
        <name>SCHC F/R Message Formats"> Formats</name>
        <t>This section defines the SCHC Fragment formats, the SCHC ACK format, the SCHC ACK REQ format and the SCHC Abort formats.</t>
        <section anchor="schc-fragment-format" title="SCHC numbered="true" toc="default">
          <name>SCHC Fragment format"> Format</name>
          <t>A SCHC Fragment conforms to the general format shown in <xref target="Fig-FragFormat"/>. target="Fig-FragFormat" format="default"/>.
It comprises a SCHC Fragment Header and a SCHC Fragment Payload.
The SCHC Fragment Payload carries one or several tile(s).</t>
          <figure title="SCHC anchor="Fig-FragFormat">
            <name>SCHC Fragment general format" anchor="Fig-FragFormat"><artwork><![CDATA[ General Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
| Fragment Header |   Fragment Payload      | padding (as needed)
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
]]></artwork></figure>
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~]]></artwork>
          </figure>

          <section anchor="NotLastFrag" title="Regular numbered="true" toc="default">
            <name>Regular SCHC Fragment"> Fragment</name>
            <t>The Regular SCHC Fragment format is shown in <xref target="Fig-NotLastFrag"/>. target="Fig-NotLastFrag" format="default"/>.
Regular SCHC Fragments are generally used to carry tiles that are not the last one of a SCHC Packet.
The DTag field and the W field are OPTIONAL, <bcp14>OPTIONAL</bcp14>, their presence is specified by each mode and Profile.</t>
            <figure title="Detailed anchor="Fig-NotLastFrag">
              <name>Detailed Header Format for Regular SCHC Fragments" anchor="Fig-NotLastFrag"><artwork><![CDATA[
 |--- Fragments</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
|-- SCHC Fragment Header ----|
         |-- T --|-M-|-- N --|
+-- ... --+- -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ -+--------...-------+~~~~~~~~~~~~~~~~~~~~
| Rule ID RuleID | DTag  | W |  FCN  | Fragment Payload | padding (as needed)
+-- ... --+- -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~
]]></artwork></figure> -+--------...-------+~~~~~~~~~~~~~~~~~~~~]]></artwork>
            </figure>
            <t>The FCN field MUST NOT <bcp14>MUST NOT</bcp14> contain all bits set to 1.</t>
            <t>Profiles MUST <bcp14>MUST</bcp14> ensure that
a SCHC Fragment with FCN equal to 0 (called an All-0 "All-0 SCHC Fragment) Fragment") is distinguishable by size,
even in the presence of padding,
from a SCHC ACK REQ message (see <xref target="ACKREQ"/>) target="ACKREQ" format="default"/>) with the same Rule ID RuleID value and with the same T, M M, and N values.
This condition is met if the Payload is at least the size of an L2 Word.
This condition is also met if the SCHC Fragment Header is a multiple of L2 Words.</t>
          </section>
          <section anchor="LastFrag" title="All-1 numbered="true" toc="default">
            <name>All-1 SCHC Fragment"> Fragment</name>
            <t>The All-1 SCHC Fragment format is shown in <xref target="Fig-LastFrag"/>. target="Fig-LastFrag" format="default"/>.
The sender uses the All-1 SCHC Fragment format for the message that completes the emission of a fragmented SCHC Packet.
The DTag field, the W field, the RCS field and the Payload are OPTIONAL, <bcp14>OPTIONAL</bcp14>, their presence is specified by each mode and Profile.
At least one of RCS field or Fragment Payload MUST <bcp14>MUST</bcp14> be present.
The FCN field is all ones.</t>
            <figure title="Detailed anchor="Fig-LastFrag">
              <name>Detailed Header Format for the All-1 SCHC Fragment" anchor="Fig-LastFrag"><artwork><![CDATA[
|-------- Fragment</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
|------- SCHC Fragment Header -------|
         |-- T --|-M-|-- N --|-- U --|
+-- ... --+- -+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ -+-----...-----+~~~~~~~~~~~~~~~~~
| Rule ID RuleID | DTag  | W | 11..1 |  RCS  | Frag Payload FragPayload | pad. (as needed)
+-- ... --+- -+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~
                        (FCN)
]]></artwork></figure> -+-----...-----+~~~~~~~~~~~~~~~~~
                       (FCN)]]></artwork>
            </figure>
            <t>Profiles MUST <bcp14>MUST</bcp14> ensure that
an All-1 SCHC Fragment message is distinguishable by size,
even in the presence of padding,
from a SCHC Sender-Abort message (see <xref target="SenderAbort"/>) target="SenderAbort" format="default"/>) with the same Rule ID RuleID value and with the same T, M M, and N values.
This condition is met if the RCS is present and is at least the size of an L2 Word, Word
or if the Payload is present and is at least the size an L2 Word.
This condition is also met if the SCHC Sender-Abort Header is a multiple of L2 Words.</t>
          </section>
        </section>
        <section anchor="ACK" title="SCHC numbered="true" toc="default">
          <name>SCHC ACK format"> Format</name>
          <t>The SCHC ACK message is shown in <xref target="Fig-ACK-Format"/>. target="Fig-ACK-Format" format="default"/>.
The DTag field and the W field are OPTIONAL, <bcp14>OPTIONAL</bcp14>, their presence is specified by each mode and Profile.
The Compressed Bitmap field MUST <bcp14>MUST</bcp14> be present in SCHC F/R modes that use windows, windows and MUST NOT <bcp14>MUST NOT</bcp14> be present in other modes.</t>
          <figure title="Format anchor="Fig-ACK-Format">
            <name>Format of the SCHC ACK message" anchor="Fig-ACK-Format"><artwork><![CDATA[
|---- Message</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|
         |-- T --|-M-| 1 |
+---
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
| Rule ID RuleID |  DTag | W |C=1| padding as needed                (success)
+---
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~

+---

+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
| Rule ID RuleID |  DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
+---
+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~

]]></artwork></figure> ------+~~~~~~~~~~~~~~~]]></artwork>
          </figure>
          <t>The SCHC ACK Header contains a C bit (see <xref target="HeaderFields"/>).</t> target="HeaderFields" format="default"/>).</t>
          <t>If the C bit is set to 1 (integrity check successful),
no Bitmap is carried.</t>
          <t>If the C bit is set to 0 (integrity check not performed or failed) and if windows are used,
a Compressed Bitmap for the window referred to by the W field is transmitted
as specified in <xref target="BitmapTrunc"/>.</t> target="BitmapTrunc" format="default"/>.</t>
          <section anchor="BitmapTrunc" title="Bitmap Compression"> numbered="true" toc="default">
            <name>Bitmap Compression</name>
            <t>For transmission, the Compressed Bitmap in the SCHC ACK message is defined by the following algorithm (see <xref target="Fig-Localbitmap"/> target="Fig-Localbitmap" format="default"/> for a follow-along example):</t>

<t><list style="symbols">
  <t>Build
            <ul spacing="normal">
              <li>Build a temporary SCHC ACK message that contains the Header followed by the original Bitmap
 (see <xref target="Bitmap"/> target="Bitmap" format="default"/> for a description of Bitmaps).</t>
  <t>Position Bitmaps).</li>
              <li>Position scissors at the end of the Bitmap, after
	      its last bit.</t>
  <t>While bit.</li>

              <li>While the bit on the left of the scissors is 1 and belongs to the Bitmap, keep moving left, then stop. When this is done,</t>
  <t>While stop.</li>
              <li>Then, while the scissors are not on an L2 Word boundary of the SCHC ACK message and there is a Bitmap bit on the right of the scissors, keep moving right, then stop.</t>
  <t>At stop.</li>
              <li>At this point, cut and drop off any bits to the right of the scissors</t>
</list></t> scissors.</li>
            </ul>
            <t>When one or more bits have effectively been dropped off as a result of the above algorithm, the SCHC ACK message is a multiple of L2 Words, Words; no padding bits will be appended.</t>
            <t>Because the SCHC Fragment sender knows the size of the original Bitmap, it can reconstruct the original Bitmap from the Compressed Bitmap received in the SCH SCHC ACK message.</t>
            <t><xref target="Fig-Localbitmap"/> target="Fig-Localbitmap" format="default"/> shows an example where L2 Words are actually bytes and where the original Bitmap contains 17 bits, the last 15 of which are all set to 1.</t>
            <figure title="SCHC anchor="Fig-Localbitmap">
              <name>SCHC ACK Header plus uncompressed Bitmap" anchor="Fig-Localbitmap"><artwork><![CDATA[
|---- Plus Uncompressed Bitmap</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|--------      Bitmap     --------|
         |-- T --|-M-| 1 |
+---
+-- ... -+- ... -+---+---+---------------------------------+
| Rule ID RuleID |  DTag | W |C=0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+---
+-- ... -+- ... -+---+---+---------------------------------+
       next L2 Word boundary ->|
]]></artwork></figure> ->|]]></artwork>
            </figure>
            <t><xref target="Fig-transmittedbitmap"/> target="Fig-transmittedbitmap" format="default"/> shows that the last 14 bits are not sent.</t>
            <figure title="Resulting anchor="Fig-transmittedbitmap">
              <name>Resulting SCHC ACK message Message with Compressed Bitmap" anchor="Fig-transmittedbitmap"><artwork><![CDATA[
|---- Bitmap</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|CpBmp|
         |-- T --|-M-| 1 |
+---
+-- ... -+- ... -+---+---+-----+
| Rule ID RuleID |  DTag | W |C=0|1 0 1|
+---
+-- ... -+- ... -+---+---+-----+
       next L2 Word boundary ->|
]]></artwork></figure> ->|]]></artwork>
            </figure>
            <t><xref target="Fig-Bitmap-Win"/> target="Fig-Bitmap-Win" format="default"/> shows an example of a SCHC ACK with tile indices ranging from 6 down to 0, where the Bitmap indicates that the second and the fourth tile of the window have not been correctly received.</t>
            <figure title="Example anchor="Fig-Bitmap-Win">
              <name>Example of a SCHC ACK message, missing tiles" anchor="Fig-Bitmap-Win"><artwork><![CDATA[
|---- Message, Missing Tiles</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|--- Bitmap --|
         |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
+---------+-------+---+---+-------------+
+--------+-------+---+---+-------------+
| Rule ID RuleID |  DTag | W |C=0|1 0 1 0 1 1 1|     uncompressed Bitmap
+---------+-------+---+---+-------------+
+--------+-------+---+---+-------------+
   next L2 Word boundary ->|<-- L2 Word -->|

+---------+-------+---+---+-------------+~~~+ --->|

+--------+-------+---+---+-------------+~~~~+
| Rule ID RuleID |  DTag | W |C=0|1 0 1 0 1 1 1|Pad| 1|pad.| transmitted SCHC ACK
+---------+-------+---+---+-------------+~~~+
+--------+-------+---+---+-------------+~~~~+
   next L2 Word boundary ->|<-- L2 Word -->|
]]></artwork></figure> --->|]]></artwork>
            </figure>
            <t><xref target="Fig-Bitmap-lastWin"/> target="Fig-Bitmap-lastWin" format="default"/> shows an example of a SCHC ACK with FCN tile indices ranging from 6 down to 0, where integrity check has not been performed or has failed and the Bitmap indicates that there is no missing tile in that window.</t>
            <figure title="Example anchor="Fig-Bitmap-lastWin">
              <name>Example of a SCHC ACK message, no missing tile" anchor="Fig-Bitmap-lastWin"><artwork><![CDATA[
|---- Message, No Missing Tile</name>
              <artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|--- Bitmap --|
         |-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
+---------+-------+---+---+-------------+
+--------+-------+---+---+-------------+
| Rule ID RuleID |  DTag | W |C=0|1 1 1 1 1 1 1|  with uncompressed Bitmap
+---------+-------+---+---+-------------+
+--------+-------+---+---+-------------+
   next L2 Word boundary ->|

+---

+-- ... -+- ... -+---+---+-+
| Rule ID RuleID |  DTag | W |C=0|1|                  transmitted SCHC ACK
+---
+-- ... -+- ... -+---+---+-+
   next L2 Word boundary ->|
]]></artwork></figure> ->|]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="ACKREQ" title="SCHC numbered="true" toc="default">
          <name>SCHC ACK REQ format"> Format</name>
          <t>The SCHC ACK REQ is used by a sender to request a SCHC ACK from the receiver.
Its format is shown in <xref target="Fig-ACKREQ"/>. target="Fig-ACKREQ" format="default"/>.
The DTag field and the W field are OPTIONAL, <bcp14>OPTIONAL</bcp14>, their presence is specified by each mode and Profile.
The FCN field is all zero.</t>
          <figure title="SCHC anchor="Fig-ACKREQ">
            <name>SCHC ACK REQ format" anchor="Fig-ACKREQ"><artwork><![CDATA[
|---- Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK REQ Header ----|
         |-- T --|-M-|-- N --|
+-- ... --+- -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| Rule ID RuleID | DTag  | W |  0..0 | padding (as needed)      (no payload)
+-- ... --+- -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
]]></artwork></figure> -+~~~~~~~~~~~~~~~~~~~~~]]></artwork>
          </figure>
        </section>
        <section anchor="SenderAbort" title="SCHC numbered="true" toc="default">
          <name>SCHC Sender-Abort format"> Format</name>
          <t>When a SCHC Fragment sender needs to abort an on-going ongoing fragmented SCHC Packet transmission, it sends a SCHC Sender-Abort message to the SCHC Fragment receiver.</t>
          <t>The SCHC Sender-Abort format is shown in <xref target="Fig-SenderAbort"/>. target="Fig-SenderAbort" format="default"/>.
The DTag field and the W field are OPTIONAL, <bcp14>OPTIONAL</bcp14>, their presence is specified by each mode and Profile.
The FCN field is all ones.</t>
          <figure title="SCHC anchor="Fig-SenderAbort">
            <name>SCHC Sender-Abort format" anchor="Fig-SenderAbort"><artwork><![CDATA[
|---- Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
|--- Sender-Abort Header ----|
         |-- T --|-M-|-- N --|
+-- ... --+- -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| Rule ID RuleID | DTag  | W | 11..1 | padding (as needed)
+-- ... --+- -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
]]></artwork></figure> -+~~~~~~~~~~~~~~~~~~~~~]]></artwork>
          </figure>
          <t>If the W field is present,</t>

<t><list style="symbols">
  <t>the present:</t>
          <ul spacing="normal">
            <li>the fragment sender MUST <bcp14>MUST</bcp14> set it to all ones.
Other values are RESERVED.</t>
  <t>the RESERVED.</li>
            <li>the fragment receiver MUST <bcp14>MUST</bcp14> check its value.
If the value is different from all ones, the message MUST <bcp14>MUST</bcp14> be ignored.</t>
</list></t> ignored.</li>
          </ul>
          <t>The SCHC Sender-Abort MUST NOT <bcp14>MUST NOT</bcp14> be acknowledged.</t>
        </section>
        <section anchor="schc-receiver-abort-format" title="SCHC numbered="true" toc="default">
          <name>SCHC Receiver-Abort format"> Format</name>
          <t>When a SCHC Fragment receiver needs to abort an on-going ongoing fragmented SCHC Packet transmission, it transmits a SCHC Receiver-Abort message to the SCHC Fragment sender.</t>
          <t>The SCHC Receiver-Abort format is shown in <xref target="Fig-ReceiverAbort"/>. target="Fig-ReceiverAbort" format="default"/>.
The DTag field and the W field are OPTIONAL, <bcp14>OPTIONAL</bcp14>, their presence is specified by each mode and Profile.</t>
          <figure title="SCHC anchor="Fig-ReceiverAbort">
            <name>SCHC Receiver-Abort format" anchor="Fig-ReceiverAbort"><artwork><![CDATA[
|--- Format</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
|-- Receiver-Abort Header ---|
           |--- T ---|-M-| 1 |
+--- ... ---+-- --+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
|  Rule ID  RuleID  |   DTag  | W |C=1| 1..1|      1..1     |
+--- ... ---+-- --+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
           next L2 Word boundary ->|<-- L2 Word -->|
]]></artwork></figure> -->|]]></artwork>
          </figure>
          <t>If the W field is present,</t>

<t><list style="symbols">
  <t>the present:</t>
          <ul spacing="normal">
            <li>the fragment receiver MUST <bcp14>MUST</bcp14> set it to all ones.
Other values are RESERVED.</t>
  <t>if RESERVED.</li>
            <li>if the value is different from all ones, the fragment sender MUST <bcp14>MUST</bcp14> ignore the message.</t>
</list></t> message.</li>
          </ul>
          <t>The SCHC Receiver-Abort has the same header as a SCHC ACK message.
The bits that follow the SCHC Receiver-Abort Header MUST <bcp14>MUST</bcp14> be as follows</t>

<t><list style="symbols">
  <t>if follows:</t>
          <ul spacing="normal">
            <li>if the Header does not end at an L2 Word boundary, append bits set to 1 as needed to reach the next L2 Word boundary</t>
  <t>append boundary.</li>
            <li>append exactly one more L2 Word with bits all set to ones</t>
</list></t> ones.</li>
          </ul>
          <t>Such a bit pattern never occurs in a legitimate SCHC ACK. This is how the fragment sender recognizes a SCHC Receiver-Abort.</t>
          <t>The SCHC Receiver-Abort MUST NOT <bcp14>MUST NOT</bcp14> be acknowledged.</t>
        </section>
      </section>
      <section anchor="FragModes" title="SCHC numbered="true" toc="default">
        <name>SCHC F/R modes"> Modes</name>
        <t>This specification includes several SCHC F/R modes, which</t>

<t><list style="symbols">
  <t>allow modes that:</t>
        <ul spacing="normal">
          <li>allow for a range of reliability options, such as optional SCHC Fragment retransmission</t>
  <t>support retransmission.</li>
          <li>support various LPWAN characteristics, such as links with variable MTU or unidirectional links.</t>
</list></t> links.</li>
        </ul>
        <t>More modes may be defined in the future.</t>
        <t><xref target="FragExamples"/> target="FragExamples" format="default"/> provides examples of fragmentation sessions based on the modes described hereafter.</t>
        <t><xref target="FSM"/> target="FSM" format="default"/> provides examples of Finite State Machines implementing the SCHC F/R modes described hereafter.</t>
        <section anchor="No-ACK-subsection" title="No-ACK mode"> numbered="true" toc="default">
          <name>No-ACK Mode</name>
          <t>The No-ACK mode has been designed under the assumption that data unit out-of-sequence delivery does not occur between the entity performing fragmentation and the entity performing reassembly.
This mode supports LPWAN L2 technologies that have a variable MTU.</t>
          <t>In No-ACK mode, there is no communication from the fragment receiver to the fragment sender.
The sender transmits all the SCHC Fragments without expecting any acknowledgement.
Therefore, No-ACK does not require bidirectional links: unidirectional links are just fine.</t>
          <t>In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. The other SCHC Fragments are intrinsically aligned to L2 Words.</t>
          <t>The tile sizes are not required to be uniform.
Windows are not used.
The Retransmission Timer is not used.
The Attempts counter is not used.</t>
          <t>Each Profile MUST <bcp14>MUST</bcp14> specify which Rule ID RuleID value(s) correspond corresponds to SCHC F/R messages operating in this mode.</t>
          <t>The W field MUST NOT <bcp14>MUST NOT</bcp14> be present in the SCHC F/R messages.
SCHC ACK MUST NOT <bcp14>MUST NOT</bcp14> be sent.
SCHC ACK REQ MUST NOT <bcp14>MUST NOT</bcp14> be sent.
SCHC Sender-Abort MAY <bcp14>MAY</bcp14> be sent.
SCHC Receiver-Abort MUST NOT <bcp14>MUST NOT</bcp14> be sent.</t>
          <t>The value of N (size of the FCN field) is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to be 1.</t>
          <t>Each Profile, for each Rule ID RuleID value, MUST define</t>

<t><list style="symbols">
  <t>the <bcp14>MUST</bcp14> define:</t>
          <ul spacing="normal">
            <li>the size of the DTag field,</t>
  <t>the field,</li>
            <li>the size and algorithm for the RCS field,</t>
  <t>the field, and</li>
            <li>the expiration time of the Inactivity Timer</t>
</list></t> Timer.</li>
          </ul>
          <t>Each Profile, for each Rule ID RuleID value, MAY <bcp14>MAY</bcp14> define</t>

<t><list style="symbols">
  <t>a
          <ul spacing="normal">
            <li>a value of N different from the recommended one,</t>
  <t>the one, and</li>
            <li>the meaning of values sent in the FCN field, for values different from the All-1 value.</t>
</list></t> value.</li>
          </ul>
          <t>For each active pair of Rule ID RuleID and DTag values, the receiver MUST <bcp14>MUST</bcp14> maintain an Inactivity Timer.
If the receiver is under-resourced to do this, it MUST <bcp14>MUST</bcp14> silently drop the related messages.</t>
          <section anchor="sender-behavior" title="Sender behavior"> numbered="true" toc="default">
            <name>Sender Behavior</name>
            <t>At the beginning of the fragmentation of a new SCHC Packet, the fragment sender MUST <bcp14>MUST</bcp14> select a Rule ID RuleID and DTag value pair for this SCHC Packet.</t>
            <t>Each SCHC Fragment MUST <bcp14>MUST</bcp14> contain exactly one tile in its Payload.
The tile MUST <bcp14>MUST</bcp14> be at least the size of an L2 Word.
The sender MUST <bcp14>MUST</bcp14> transmit the SCHC Fragments messages in the order that the tiles appear in the SCHC Packet.
Except for the last tile of a SCHC Packet, each tile MUST <bcp14>MUST</bcp14> be of a size
that complements the SCHC Fragment Header so
that the SCHC Fragment is a multiple of L2 Words without the need for padding bits.
Except for the last one, the SCHC Fragments MUST <bcp14>MUST</bcp14> use the Regular SCHC Fragment format specified in <xref target="NotLastFrag"/>. target="NotLastFrag" format="default"/>.
The SCHC Fragment that carries the last tile MUST <bcp14>MUST</bcp14> be an All-1 SCHC Fragment, described in <xref target="LastFrag"/>.</t> target="LastFrag" format="default"/>.</t>
            <t>The sender MAY <bcp14>MAY</bcp14> transmit a SCHC Sender-Abort.</t>
            <t><xref target="Fig-NoACKModeSnd"/> target="Fig-NoACKModeSnd" format="default"/> shows an example of a corresponding state machine.</t>
          </section>
          <section anchor="receiver-behavior" title="Receiver behavior"> numbered="true" toc="default">
            <name>Receiver Behavior</name>
            <t>Upon receiving each Regular SCHC Fragment,</t>

<t><list style="symbols">
  <t>the Fragment:</t>
            <ul spacing="normal">
              <li>the receiver MUST <bcp14>MUST</bcp14> reset the Inactivity Timer,</t>
  <t>the Timer.</li>
              <li>the receiver assembles the payloads of the SCHC Fragments</t>
</list></t> Fragments.</li>
            </ul>
            <t>On receiving an All-1 SCHC Fragment,</t>

<t><list style="symbols">
  <t>the Fragment:</t>
            <ul spacing="normal">
              <li>the receiver MUST <bcp14>MUST</bcp14> append the All-1 SCHC Fragment Payload and the padding bits to the
previously received SCHC Fragment Payloads for this SCHC Packet</t>
  <t>the Packet.</li>
              <li>the receiver MUST <bcp14>MUST</bcp14> perform the integrity check</t>
  <t>if check.</li>
              <li>if integrity checking fails,
  the receiver MUST <bcp14>MUST</bcp14> drop the reassembled SCHC Packet</t>
  <t>the Packet.</li>
              <li>the reassembly operation concludes.</t>
</list></t> concludes.</li>
            </ul>
            <t>On expiration of the Inactivity Timer,
the receiver MUST <bcp14>MUST</bcp14> drop the SCHC Packet being reassembled.</t>
            <t>On receiving a SCHC Sender-Abort,
the receiver MAY <bcp14>MAY</bcp14> drop the SCHC Packet being reassembled.</t>
            <t><xref target="Fig-NoACKModeRcv"/> target="Fig-NoACKModeRcv" format="default"/> shows an example of a corresponding state machine.</t>
          </section>
        </section>
        <section anchor="ACK-Always-subsection" title="ACK-Always mode"> numbered="true" toc="default">
          <name>ACK-Always Mode</name>
          <t>The ACK-Always mode has been designed under the following assumptions</t>

<t><list style="symbols">
  <t>Data assumptions:</t>
          <ul spacing="normal">
            <li>Data unit out-of-sequence delivery does not occur between the entity performing fragmentation and the entity performing reassembly</t>
  <t>The reassembly,</li>
            <li>The L2 MTU value does not change while the fragments of a SCHC Packet are being transmitted.</t>
  <t>There transmitted, and</li>
            <li>There is a feedback path from the reassembler to the fragmenter.
See <xref target="AsymLinks"/> target="AsymLinks" format="default"/> for a discussion on using ACK-Always mode on quasi-bidirectional links.</t>
</list></t> links.</li>
          </ul>
          <t>In ACK-Always mode, windows are used.
An acknowledgement, positive or negative, is transmitted by the fragment receiver to the fragment sender at the end of the transmission of each window of SCHC Fragments.</t>
          <t>The tiles are not required to be of uniform size. In ACK-Always mode, only the All-1 SCHC Fragment is padded as needed. The other SCHC Fragments are intrinsically aligned to L2 Words.</t>
          <t>Briefly, the algorithm is as follows: after a first blind transmission of all the tiles of a window, the fragment sender iterates retransmitting the tiles that are reported missing until the fragment receiver reports that all the tiles belonging to the window have been correctly received, received or until too many attempts were made.
The fragment sender only advances to the next window of tiles when it has ascertained that all the tiles belonging to the current window have been fully and correctly received. This results in a per-window lock-step behavior between the sender and the receiver.</t>
          <t>Each Profile MUST <bcp14>MUST</bcp14> specify which Rule ID RuleID value(s) correspond to SCHC F/R messages operating in this mode.</t>
          <t>The W field MUST <bcp14>MUST</bcp14> be present and its size M MUST <bcp14>MUST</bcp14> be 1 bit.</t>
          <t>Each Profile, for each Rule ID RuleID value, MUST define</t>

<t><list style="symbols">
  <t>the <bcp14>MUST</bcp14> define:</t>
          <ul spacing="normal">
            <li>the value of N (size of the FCN field),</t>
  <t>the N,</li>
            <li>the value of WINDOW_SIZE, which MUST <bcp14>MUST</bcp14> be strictly less than 2^N,</t>
  <t>the 2^N,</li>
            <li>the size and algorithm for the RCS field,</t>
  <t>the size field,</li>
            <li>the value of the DTag field,</t>
  <t>the T,</li>
            <li>the value of MAX_ACK_REQUESTS,</t>
  <t>the MAX_ACK_REQUESTS,</li>
            <li>the expiration time of the Retransmission Timer</t>
  <t>the Timer, and</li>
            <li>the expiration time of the Inactivity Timer</t>
</list></t> Timer.</li>
          </ul>
          <t>For each active pair of Rule ID RuleID and DTag values, the sender MUST maintain</t>

<t><list style="symbols">
  <t>one <bcp14>MUST</bcp14> maintain:</t>
          <ul spacing="normal">
            <li>one Attempts counter</t>
  <t>one counter</li>
            <li>one Retransmission Timer</t>
</list></t> Timer</li>
          </ul>
          <t>For each active pair of Rule ID RuleID and DTag values, the receiver MUST <bcp14>MUST</bcp14> maintain</t>

<t><list style="symbols">
  <t>one
          <ul spacing="normal">
            <li>one Inactivity Timer</t>
  <t>one Timer, and</li>
            <li>one Attempts counter</t>
</list></t> counter.</li>
          </ul>
          <section anchor="sender-behavior-1" title="Sender behavior"> numbered="true" toc="default">
            <name>Sender Behavior</name>
            <t>At the beginning of the fragmentation of a new SCHC Packet, the fragment sender MUST <bcp14>MUST</bcp14> select a Rule ID RuleID and DTag value pair for this SCHC Packet.</t>
            <t>Each SCHC Fragment MUST <bcp14>MUST</bcp14> contain exactly one tile in its Payload.
All tiles with the index 0, as well as the last tile, MUST <bcp14>MUST</bcp14> be at least the size of an L2 Word.</t>
            <t>In all SCHC Fragment messages, the W field MUST <bcp14>MUST</bcp14> be filled with the least significant bit LSB of the window number that the sender is currently processing.</t>
            <t>For a SCHC Fragment that carries a tile other than the last one of the SCHC Packet,</t>

<t><list style="symbols">
  <t>the Packet:</t>
            <ul spacing="normal">
              <li>the Fragment MUST <bcp14>MUST</bcp14> be of the Regular type specified in <xref target="NotLastFrag"/></t>
  <t>the target="NotLastFrag" format="default"/>.</li>
              <li>the FCN field MUST <bcp14>MUST</bcp14> contain the tile index</t>
  <t>each index.</li>
              <li>each tile MUST <bcp14>MUST</bcp14> be of a size
that complements the SCHC Fragment Header so
that the SCHC Fragment is a multiple of L2 Words without the need for padding bits.</t>
</list></t> bits.</li>
            </ul>
            <t>The SCHC Fragment that carries the last tile MUST <bcp14>MUST</bcp14> be an All-1 SCHC Fragment, described in <xref target="LastFrag"/>.</t> target="LastFrag" format="default"/>.</t>
            <t>The fragment sender MUST <bcp14>MUST</bcp14> start by transmitting the window numbered 0.</t>
            <t>All message receptions being discussed in the rest of this section are to be understood as
“matching
"matching the RuleID and DTag pair being processed”, processed", even if not spelled out, for brevity.</t>
            <t>The sender starts by a “blind transmission” "blind transmission" phase, in which it MUST <bcp14>MUST</bcp14> transmit all the tiles composing the window, in decreasing tile index order.</t>
            <t>Then, it enters a “retransmission phase” "retransmission phase" in which
it MUST <bcp14>MUST</bcp14> initialize an Attempts counter to 0,
it MUST <bcp14>MUST</bcp14> start a Retransmission Timer
and it MUST <bcp14>MUST</bcp14> await a SCHC ACK. Then,</t>

<t><list style="symbols">
  <t>upon </t>
            <ul spacing="normal">
              <li>
                <t>Then, upon receiving a SCHC ACK,  <list style="symbols">
      <t>if ACK:</t>
                <ul spacing="normal">
                  <li>if the SCHC ACK indicates that some tiles are missing at the receiver, then
the sender MUST <bcp14>MUST</bcp14> transmit all the tiles that have been reported missing,
it MUST <bcp14>MUST</bcp14> increment Attempts,
it MUST <bcp14>MUST</bcp14> reset the Retransmission Timer Timer,
and MUST <bcp14>MUST</bcp14> await the next SCHC ACK.</t>
      <t>if ACK.</li>
                  <li>if the current window is not the last one and the SCHC ACK indicates that all tiles were correctly received,
the sender MUST <bcp14>MUST</bcp14> stop the Retransmission Timer,
it MUST <bcp14>MUST</bcp14> advance to the next fragmentation window window,
and it MUST <bcp14>MUST</bcp14> start a blind transmission phase as described above.</t>
      <t>if above.</li>
                  <li>if the current window is the last one and the SCHC ACK indicates that more tiles were received than the sender sent,
the fragment sender MUST <bcp14>MUST</bcp14> send a SCHC Sender-Abort,
and it MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
      <t>if condition.</li>
                  <li>if the current window is the last one and the
		  SCHC ACK indicates that all tiles were correctly received
		  received, yet the integrity check was a failure,
the fragment sender MUST <bcp14>MUST</bcp14> send a SCHC Sender-Abort,
and it MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
      <t>if condition.</li>
                  <li>if the current window is the last one and the SCHC ACK indicates that integrity checking was successful,
the sender exits successfully.</t>
    </list></t> successfully.</li>
                </ul>
              </li>
              <li>
                <t>on Retransmission Timer expiration,  <list style="symbols">
      <t>if expiration:  </t>
                <ul spacing="normal">
                  <li>if Attempts is strictly less that MAX_ACK_REQUESTS,
the fragment sender MUST <bcp14>MUST</bcp14> send a SCHC ACK REQ
and MUST <bcp14>MUST</bcp14> increment the Attempts counter.</t>
      <t>otherwise counter.</li>
                  <li>otherwise,
the fragment sender MUST <bcp14>MUST</bcp14> send a SCHC Sender-Abort,
and it MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
    </list></t>
</list></t> condition.</li>
                </ul>
              </li>
            </ul>
            <t>At any time,</t>

<t><list style="symbols">
  <t>on time:</t>
            <ul spacing="normal">
              <li>on receiving a SCHC Receiver-Abort, the fragment sender MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
  <t>on condition.</li>
              <li>on receiving a SCHC ACK that bears a W value different from the W value that it currently uses, the fragment sender MUST <bcp14>MUST</bcp14> silently discard and ignore that SCHC ACK.</t>
</list></t> ACK.</li>
            </ul>
            <t><xref target="Fig-ACKAlwaysSnd"/> target="Fig-ACKAlwaysSnd" format="default"/> shows an example of a corresponding state machine.</t>
          </section>
          <section anchor="receiver-behavior-1" title="Receiver behavior"> numbered="true" toc="default">
            <name>Receiver Behavior</name>
            <t>On receiving a SCHC Fragment with a Rule ID RuleID and DTag pair not being processed at that time</t>

<t><list style="symbols">
  <t>the time:</t>
            <ul spacing="normal">
              <li>the receiver SHOULD <bcp14>SHOULD</bcp14> check if the DTag value has not recently been used for that Rule ID RuleID value,
thereby ensuring that the received SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission.
The initial value of the Inactivity Timer is the RECOMMENDED <bcp14>RECOMMENDED</bcp14> lifetime for the DTag value at the receiver.
If the SCHC Fragment is determined to be such a remnant, the receiver MAY <bcp14>MAY</bcp14> silently ignore it and discard it.</t>
  <t>the it.</li>
              <li>the receiver MUST <bcp14>MUST</bcp14> start a process to assemble a new SCHC Packet with that Rule ID RuleID and DTag value pair.</t>
  <t>the pair.</li>
              <li>the receiver MUST <bcp14>MUST</bcp14> start an Inactivity Timer for that RuleID and DTag pair.
It MUST <bcp14>MUST</bcp14> initialize an Attempts counter to 0 for that RuleID and DTag pair.
It MUST <bcp14>MUST</bcp14> initialize a window counter to 0.
If the receiver is under-resourced to do this, it MUST <bcp14>MUST</bcp14> respond to the sender with a SCHC Receiver Abort.</t>
</list></t> Receiver-Abort.</li>
            </ul>
            <t>In the rest of this section, “local "local W bit” bit" means the least significant bit of the window counter of the receiver.</t>
            <t>On reception of any SCHC F/R message for the RuleID and DTag pair being processed, the receiver MUST <bcp14>MUST</bcp14> reset the Inactivity Timer pertaining to that RuleID and DTag pair.</t>
            <t>All message receptions being discussed in the rest of this section are to be understood as
“matching
"matching the RuleID and DTag pair being processed”, processed", even if not spelled out, for brevity.</t>
            <t>The receiver MUST <bcp14>MUST</bcp14> first initialize an empty Bitmap for the first window, window then
enter an “acceptance phase”, "acceptance phase", in which</t>

<t><list style="symbols">
  <t>on which:</t>
            <ul spacing="normal">
              <li>on receiving a SCHC Fragment or a SCHC ACK REQ, either one having the W bit different from the local W bit,
the receiver MUST <bcp14>MUST</bcp14> silently ignore and discard that message.</t>
  <t>on message.</li>
              <li>on receiving a SCHC ACK REQ with the W bit equal to the local W bit,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK for this window.</t> window.</li>
              <li>
                <t>on receiving a SCHC Fragment with the W bit equal to the local W bit,
the receiver MUST <bcp14>MUST</bcp14> assemble the received tile based on the window counter and on the FCN field in the SCHC Fragment Fragment,
and it MUST <bcp14>MUST</bcp14> update the Bitmap.
  <list style="symbols">
      <t>if
                </t>
                <ul spacing="normal">
                  <li>if the SCHC Fragment received is an All-0 SCHC Fragment,
the current window is determined to be a not-last window,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK for this window
and it MUST <bcp14>MUST</bcp14> enter the “retransmission phase” "retransmission phase" for this window.</t> window.</li>
<li>

                    <t>if the SCHC Fragment received is an All-1 SCHC Fragment,
the current window is determined to be the last window,
the padding bits of the All-1 SCHC Fragment MUST <bcp14>MUST</bcp14> be assembled after the received tile,
the current window is determined to be the last window,
the receiver MUST <bcp14>MUST</bcp14> perform the integrity check
and it MUST <bcp14>MUST</bcp14> send a SCHC ACK for this window. Then,      <list style="symbols">
          <t>If Then:      </t>
                    <ul spacing="normal">
                      <li>If the integrity check indicates that the full SCHC Packet has been correctly reassembled,
the receiver MUST <bcp14>MUST</bcp14> enter the “clean-up phase” "clean-up phase" for this window.</t>
          <t>If window.</li>
                      <li>If the integrity check indicates that the full SCHC Packet has not been correctly reassembled,
the receiver enters the “retransmission phase” "retransmission phase" for this window.</t>
        </list></t>
    </list></t>
</list></t> window.</li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
            <t>In the “retransmission phase”:</t>

<t><list style="symbols"> "retransmission phase":</t>
            <ul spacing="normal">
              <li>
                <t>if the window is a not-last window  <list style="symbols">
      <t>on window:</t>
                <ul spacing="normal">
                  <li>on receiving a SCHC Fragment that is not All-0 or All-1 and that has a W bit different from the local W bit,
the receiver MUST <bcp14>MUST</bcp14> increment its window counter and allocate a fresh Bitmap,
it MUST <bcp14>MUST</bcp14> assemble the tile received and update the Bitmap Bitmap,
and it MUST <bcp14>MUST</bcp14> enter the “acceptance phase” "acceptance phase" for that new window.</t>
      <t>on window.</li>
                  <li>on receiving a SCHC ACK REQ with a W bit different from the local W bit,
the receiver MUST <bcp14>MUST</bcp14> increment its window counter and allocate a fresh Bitmap,
it MUST <bcp14>MUST</bcp14> send a SCHC ACK for that new window window,
and it MUST <bcp14>MUST</bcp14> enter the “acceptance phase” "acceptance phase" for that new window.</t>
      <t>on window.</li>
                  <li>on receiving a SCHC All-0 Fragment with a W bit different from the local W bit,
the receiver MUST <bcp14>MUST</bcp14> increment its window counter and allocate a fresh Bitmap,
it MUST <bcp14>MUST</bcp14> assemble the tile received and update the Bitmap,
it MUST <bcp14>MUST</bcp14> send a SCHC ACK for that new window window,
and it MUST <bcp14>MUST</bcp14> stay in the “retransmission phase” "retransmission phase" for that new window.</t> window.</li>
                  <li>
                    <t>on receiving a SCHC All-1 Fragment with a W bit different from the local W bit,
the receiver MUST <bcp14>MUST</bcp14> increment its window counter and allocate a fresh Bitmap, Bitmap;
it MUST <bcp14>MUST</bcp14> assemble the tile received,
including the padding bits, bits;
it MUST <bcp14>MUST</bcp14> update the Bitmap and perform the integrity check, check;
it MUST <bcp14>MUST</bcp14> send a SCHC ACK for the new window,
which is determined to be the last window. Then,      <list style="symbols">
          <t>If Then:</t>
                    <ul spacing="normal">
                      <li>If the integrity check indicates that the full SCHC Packet has been correctly reassembled,
the receiver MUST <bcp14>MUST</bcp14> enter the “clean-up phase” "clean-up phase" for that new window.</t>
          <t>If window.</li>
                      <li>If the integrity check indicates that the full SCHC Packet has not been correctly reassembled,
the receiver enters the “retransmission phase” "retransmission phase" for that new window.</t>
        </list></t> window.</li>
                    </ul>
                  </li>
                  <li>
                    <t>on receiving a SCHC Fragment with a W bit equal to the local W bit,      <list style="symbols">
          <t>if bit:</t>
                    <ul spacing="normal">
                      <li>if the SCHC Fragment received is an All-1 SCHC Fragment,
the receiver MUST <bcp14>MUST</bcp14> silently ignore it and discard it.</t>
          <t>otherwise, it.</li>
                      <li>otherwise,
the receiver MUST <bcp14>MUST</bcp14> assemble the tile received and update the Bitmap.
If the Bitmap becomes fully populated with 1’s 1's or if the SCHC Fragment is an All-0,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK for this window.</t>
        </list></t>
      <t>on window.</li>
                    </ul>
                  </li>
                  <li>on receiving a SCHC ACK REQ with the W bit equal to the local W bit,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK for this window.</t>
    </list></t> window.</li>
                </ul>
              </li>
              <li>
                <t>if the window is the last window  <list style="symbols">
      <t>on window:</t>
                <ul spacing="normal">
                  <li>on receiving a SCHC Fragment or a SCHC ACK REQ, either one having a W bit different from the local W bit,
the receiver MUST <bcp14>MUST</bcp14> silently ignore and discard that message.</t>
      <t>on message.</li>
                  <li>on receiving a SCHC ACK REQ with the W bit equal to the local W bit,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK for this window.</t> window.</li>
                  <li>
                    <t>on receiving a SCHC Fragment with a W bit equal to the local W bit,      <list style="symbols">
          <t>if bit:</t>
                    <ul spacing="normal">
                      <li>if the SCHC Fragment received is an All-0 SCHC Fragment,
the receiver MUST <bcp14>MUST</bcp14> silently ignore it and discard it.</t> it.</li>
                      <li>
                        <t>otherwise, the receiver MUST <bcp14>MUST</bcp14> update the Bitmap Bitmap,
and it MUST <bcp14>MUST</bcp14> assemble the tile received.
If the SCHC Fragment received is an All-1 SCHC Fragment,
the receiver MUST <bcp14>MUST</bcp14> assemble the padding bits of the All-1 SCHC Fragment after the received tile,
it MUST <bcp14>MUST</bcp14> perform the integrity check and          <list style="symbols">
              <t>if and:</t>
                        <ul spacing="normal">
                          <li>if the integrity check indicates that the full SCHC Packet has been correctly reassembled,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK
and it enters the “clean-up phase”.</t> "clean-up phase".</li>
                          <li>
                            <t>if the integrity check indicates that the full SCHC Packet has not been correctly reassembled,
              <list style="symbols">
                  <t>if reassembled:
                            </t>
                            <ul spacing="normal">
                              <li>if the SCHC Fragment received was an All-1 SCHC Fragment, the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK for this window.</t>
                </list></t>
            </list></t>
        </list></t>
    </list></t>
</list></t> window.</li>
                            </ul>
                          </li>
                        </ul>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
            <t>In the “clean-up phase”:</t>

<t><list style="symbols">
  <t>On "clean-up phase":</t>
            <ul spacing="normal">
              <li>On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, either one having the W bit equal to the local W bit, the receiver MUST <bcp14>MUST</bcp14> send a SCHC ACK.</t>
  <t>Any ACK.</li>
              <li>Any other SCHC Fragment received MUST <bcp14>MUST</bcp14> be silently ignored and discarded.</t>
</list></t> discarded.</li>
            </ul>
            <t>At any time,
on sending a SCHC ACK,
the receiver MUST <bcp14>MUST</bcp14> increment the Attempts counter.</t>
            <t>At any time,
on incrementing its window counter,
the receiver MUST <bcp14>MUST</bcp14> reset the Attempts counter.</t>
            <t>At any time,
on expiration of the Inactivity Timer,
on receiving a SCHC Sender-Abort or
when Attempts reaches MAX_ACK_REQUESTS,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC Receiver-Abort Receiver-Abort,
and it MAY <bcp14>MAY</bcp14> exit the receive process for that SCHC Packet.</t>
            <t><xref target="Fig-ACKAlwaysRcv"/> target="Fig-ACKAlwaysRcv" format="default"/> shows an example of a corresponding state machine.</t>
          </section>
        </section>
        <section anchor="ACK-on-Error-subsection" title="ACK-on-Error mode"> numbered="true" toc="default">
          <name>ACK-on-Error Mode</name>
          <t>The ACK-on-Error mode supports LPWAN L2 technologies that have variable MTU and out-of-order delivery.
It operates with links requires an L2 that provide provides a feedback path from the reassembler to the fragmenter.
See <xref target="AsymLinks"/> target="AsymLinks" format="default"/> for a discussion on using ACK-on-Error mode on quasi-bidirectional links.</t>
          <t>In ACK-on-Error mode, windows are used.</t>
          <t>All tiles, but tiles except the last one and the penultimate one, MUST one <bcp14>MUST</bcp14> be of equal size, hereafter called “regular”. "regular".
The size of the last tile MUST <bcp14>MUST</bcp14> be smaller than or equal to the regular tile size.
Regarding the penultimate tile, a Profile MUST <bcp14>MUST</bcp14> pick one of the following two options:</t>

<t><list style="symbols">
  <t>The
          <ul spacing="normal">
            <li>The penultimate tile size MUST <bcp14>MUST</bcp14> be the
	    regular tile size</t>
  <t>or the size, or</li>
            <li>the penultimate tile size MUST <bcp14>MUST</bcp14> be either the regular tile size or the regular tile size minus one L2 Word.</t>
</list></t> Word.</li>
          </ul>
          <t>A SCHC Fragment message carries one or several contiguous tiles, which may span multiple windows.
A SCHC ACK reports on the reception of exactly one window of tiles.</t>
          <t>See <xref target="Fig-TilesACKonError"/> target="Fig-TilesACKonError" format="default"/> for an example.</t>
          <figure title="a SCHC anchor="Fig-TilesACKonError">
            <name>SCHC Packet fragmented Fragmented in tiles, Tiles, ACK-on-Error mode" anchor="Fig-TilesACKonError"><artwork><![CDATA[ Mode</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
        +---------------------------------------------...-----------+
        |                       SCHC Packet                         |
        +---------------------------------------------...-----------+

Tile #

Tile#   | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 |     | 0 | 4 |3|
Window #
Window# |-------- 0 --------|-------- 1 --------|- 2  ... 27 -|- 28-|

SCHC Fragment msg    |-----------|
]]></artwork></figure>   |-----------|]]></artwork>
          </figure>
          <t>The W field is wide enough that it unambiguously represents an absolute window number.
The fragment receiver sends SCHC ACKs to the fragment sender about windows for which tiles are missing.
No SCHC ACK is sent by the fragment receiver for windows that it knows have been fully received.</t>
          <t>The fragment sender retransmits SCHC Fragments for tiles that are reported missing.
It can advance to next windows even before it has ascertained that all tiles belonging to previous windows have been correctly received,
and it can still later retransmit SCHC Fragments with tiles belonging to previous windows.
Therefore, the sender and the receiver may operate in a decoupled fashion.
The fragmented SCHC Packet transmission concludes when</t>

<t><list style="symbols">
  <t>integrity when:</t>
          <ul spacing="normal">
            <li>integrity checking shows that the fragmented SCHC Packet has been correctly reassembled at the receive end,
and this information has been conveyed back to the sender,</t>
  <t>or too sender, or</li>
            <li>too many retransmission attempts were made,</t>
  <t>or the made, or</li>
            <li>the receiver determines that the transmission of this fragmented SCHC Packet has been inactive for too long.</t>
</list></t> long.</li>
          </ul>
          <t>Each Profile MUST <bcp14>MUST</bcp14> specify which Rule ID RuleID value(s) correspond corresponds to SCHC F/R messages operating in this mode.</t>
          <t>The W field MUST <bcp14>MUST</bcp14> be present in the SCHC F/R messages.</t>
          <t>Each Profile, for each Rule ID RuleID value, MUST define</t>

<t><list style="symbols">
  <t>the <bcp14>MUST</bcp14> define:</t>
          <ul spacing="normal">
            <li>the tile size (a tile does not need to be multiple of an L2 Word, but it MUST <bcp14>MUST</bcp14> be at least the size of an L2 Word)</t>
  <t>the Word),</li>
            <li>the value of M (size of the W field),</t>
  <t>the M,</li>
            <li>the value of N (size of the FCN field),</t>
  <t>the N,</li>
            <li>the value of WINDOW_SIZE, which MUST <bcp14>MUST</bcp14> be strictly less than 2^N,</t>
  <t>the 2^N,</li>
            <li>the size and algorithm for the RCS field,</t>
  <t>the size field,</li>
            <li>the value of the DTag field,</t>
  <t>the T,</li>
            <li>the value of MAX_ACK_REQUESTS,</t>
  <t>the MAX_ACK_REQUESTS,</li>
            <li>the expiration time of the Retransmission Timer</t>
  <t>the Timer,</li>
            <li>the expiration time of the Inactivity Timer</t>
  <t>whether Timer,</li>
            <li>if the last tile is carried in a Regular SCHC Fragment or an All-1 SCHC Fragment (see <xref target="ACK-on-Error-sender"/>)</t>
  <t>if target="ACK-on-Error-sender" format="default"/>), and</li>
            <li>if the penultimate tile MAY <bcp14>MAY</bcp14> be one L2 Word smaller than the regular tile size. In this case, the regular tile size MUST <bcp14>MUST</bcp14> be at least twice the L2 Word size.</t>
</list></t> size.</li>
          </ul>
          <t>For each active pair of Rule ID RuleID and DTag values, the sender MUST maintain</t>

<t><list style="symbols">
  <t>one <bcp14>MUST</bcp14> maintain:</t>
          <ul spacing="normal">
            <li>one Attempts counter</t>
  <t>one counter, and</li>
            <li>one Retransmission Timer</t>
</list></t> Timer.</li>
          </ul>
          <t>For each active pair of Rule ID RuleID and DTag values, the receiver MUST maintain</t>

<t><list style="symbols">
  <t>one <bcp14>MUST</bcp14> maintain:</t>
          <ul spacing="normal">
            <li>one Inactivity Timer</t>
  <t>one Timer, and</li>
            <li>one Attempts counter</t>
</list></t> counter.</li>
          </ul>
          <section anchor="ACK-on-Error-sender" title="Sender behavior"> numbered="true" toc="default">
            <name>Sender Behavior</name>
            <t>At the beginning of the fragmentation of a new SCHC Packet,</t>

<t><list style="symbols">
  <t>the Packet:</t>
            <ul spacing="normal">
              <li>the fragment sender MUST <bcp14>MUST</bcp14> select a Rule ID RuleID and DTag value pair for this SCHC Packet.
A Rule MUST NOT <bcp14>MUST NOT</bcp14> be selected if the values of M and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot be fragmented in (2^M) * WINDOW_SIZE tiles or less.</t>
  <t>the less.</li>
              <li>the fragment sender MUST <bcp14>MUST</bcp14> initialize the Attempts counter to 0 for that Rule ID RuleID and DTag value pair.</t>
</list></t> pair.</li>
            </ul>
            <t>A Regular SCHC Fragment message carries in its payload one or more tiles.
If more than one tile is carried in one Regular SCHC Fragment</t>

<t><list style="symbols">
  <t>the Fragment:</t>
            <ul spacing="normal">
              <li>the selected tiles MUST <bcp14>MUST</bcp14> be contiguous in the original SCHC Packet</t>
  <t>they MUST Packet, and</li>
              <li>they <bcp14>MUST</bcp14> be placed in the SCHC Fragment Payload adjacent to one another, in the order they appear in the SCHC Packet, from the start of the SCHC Packet toward its end.</t>
</list></t> end.</li>
            </ul>
            <t>Tiles that are not the last one MUST <bcp14>MUST</bcp14> be sent in Regular SCHC Fragments specified in <xref target="NotLastFrag"/>. target="NotLastFrag" format="default"/>.
The FCN field MUST <bcp14>MUST</bcp14> contain the tile index of the first tile sent in that SCHC Fragment.</t>
            <t>In a Regular SCHC Fragment message, the sender MUST <bcp14>MUST</bcp14> fill the W field with the window number of the first tile sent in that SCHC Fragment.</t>

<t>Depending on the Profile,
            <t>A Profile <bcp14>MUST</bcp14> define if the last tile of a SCHC Packet MUST be sent either</t>

<t><list style="symbols">
  <t>in is sent:</t>
            <ul spacing="normal">
              <li>in a Regular SCHC Fragment, alone or as part of a multi-tiles Payload</t>
  <t>alone Payload,</li>
              <li>alone in an All-1 SCHC Fragment</t>
</list></t> Fragment, or</li>
              <li>with any of the above two methods.</li>
            </ul>
            <t>In an All-1 SCHC Fragment message, the sender MUST <bcp14>MUST</bcp14> fill the W field with the window number of the last tile of the SCHC Packet.</t>
            <t>The fragment sender MUST <bcp14>MUST</bcp14> send SCHC Fragments such that, all together, they contain all the tiles of the fragmented SCHC Packet.</t>
            <t>The fragment sender MUST <bcp14>MUST</bcp14> send at least one All-1 SCHC Fragment.</t>
            <t>In doing the two items above, the sender <bcp14>MUST</bcp14> ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.</t>
            <t>The fragment sender MUST <bcp14>MUST</bcp14> listen for SCHC ACK messages after having sent</t>

<t><list style="symbols">
  <t>an sent:</t>
            <ul spacing="normal">
              <li>an All-1 SCHC Fragment</t>
  <t>or a Fragment, or</li>
              <li>a SCHC ACK REQ.</t>
</list></t> REQ.</li>
            </ul>
            <t>A Profile MAY <bcp14>MAY</bcp14> specify other times at which the fragment sender MUST <bcp14>MUST</bcp14> listen for SCHC ACK messages.
For example, this could be after sending a complete window of tiles.</t>
            <t>Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC ACK REQ,</t>

<t><list style="symbols">
  <t>it MUST REQ:</t>
            <ul spacing="normal">
              <li>it <bcp14>MUST</bcp14> increment the Attempts counter</t>
  <t>it MUST counter, and</li>
              <li>it <bcp14>MUST</bcp14> reset the Retransmission Timer</t>
</list></t> Timer.</li>
            </ul>
            <t>On Retransmission Timer expiration</t>

<t><list style="symbols">
  <t>if expiration:</t>
            <ul spacing="normal">
              <li>if the Attempts counter is strictly less than MAX_ACK_REQUESTS,
the fragment sender MUST <bcp14>MUST</bcp14> send
either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window,</t>
  <t>otherwise window,</li>
              <li>otherwise, the fragment sender MUST <bcp14>MUST</bcp14> send a SCHC Sender-Abort Sender-Abort, and
it MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
</list></t> condition.</li>
            </ul>
            <t>All message receptions being discussed in the rest of this section are to be understood as
“matching
"matching the RuleID and DTag pair being processed”, processed", even if not spelled out, for brevity.</t>
            <t>On receiving a SCHC ACK,</t>

<t><list style="symbols"> ACK:</t>
            <ul spacing="normal">
              <li>
                <t>if the W field in the SCHC ACK corresponds to the last window of the SCHC Packet,  <list style="symbols">
      <t>if Packet:</t>
                <ul spacing="normal">
                  <li>if the C bit is set, the sender MAY <bcp14>MAY</bcp14> exit successfully</t>
      <t>otherwise,      <list style="symbols"> successfully.</li>
                  <li>
                    <t>otherwise:      </t>
                    <ul spacing="normal">
                      <li>
                        <t>if the Profile mandates that the last tile be sent in an All-1 SCHC Fragment,          <list style="symbols"> Fragment:</t>
                        <ul spacing="normal">
                          <li>
                            <t>if the SCHC ACK shows no missing tile at the receiver, the sender              <list style="symbols">
                  <t>MUST sender:</t>
                            <ul spacing="normal">
                              <li><bcp14>MUST</bcp14> send a SCHC Sender-Abort</t>
                  <t>MAY Sender-Abort, and</li>
                              <li><bcp14>MAY</bcp14> exit with an error condition</t>
                </list></t>
              <t>otherwise              <list style="symbols">
                  <t>the condition.</li>
                            </ul>
                          </li>
                          <li>
                            <t>otherwise:</t>
                            <ul spacing="normal">
                              <li>the fragment sender MUST <bcp14>MUST</bcp14> send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC ACK.</t>
                  <t>if ACK.</li>
                              <li>if the last of these SCHC Fragment messages is not an All-1 SCHC Fragment,
then the fragment sender MUST <bcp14>MUST</bcp14> in addition send after it a SCHC ACK REQ with the W field corresponding to the last window.</t>
                </list></t>
            </list></t>
          <t>otherwise,          <list style="symbols">
              <t>if window.</li>
                              <li>in doing the two items above, the sender <bcp14>MUST</bcp14> ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.</li>
                            </ul>
                          </li>
                        </ul>
                      </li>
                      <li>
                        <t>otherwise:</t>
                        <ul spacing="normal">
                          <li>if the SCHC ACK shows no missing tile at the receiver, the sender
MUST
<bcp14>MUST</bcp14> send the All-1 SCHC Fragment</t>
              <t>otherwise              <list style="symbols">
                  <t>the Fragment</li>
                          <li>
                            <t>otherwise:</t>
                            <ul spacing="normal">
                              <li>the fragment sender MUST <bcp14>MUST</bcp14> send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC ACK.</t>
                  <t>the ACK.</li>
                              <li>the fragment sender MUST <bcp14>MUST</bcp14> then send
either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window.</t>
                </list></t>
            </list></t>
        </list></t>
    </list></t> window.</li>
                            </ul>
                          </li>
                        </ul>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li>
                <t>otherwise, the fragment sender  <list style="symbols">
      <t>MUST sender:</t>
                <ul spacing="normal">
                  <li><bcp14>MUST</bcp14> send SCHC Fragment messages containing the tiles that are reported missing in the SCHC ACK</t>
      <t>then ACK.</li>
                  <li>then, it MAY <bcp14>MAY</bcp14> send a SCHC ACK REQ with the W field corresponding to the last window</t>
    </list></t>
</list></t> window.</li>
                </ul>
              </li>
            </ul>
            <t>See <xref target="Fig-ACKonerrorSnd"/> target="Fig-ACKonerrorSnd" format="default"/> for one among several possible examples of a Finite State Machine implementing a sender behavior obeying this specification.</t>
          </section>
          <section anchor="ACK-on-Error-receiver" title="Receiver behavior"> numbered="true" toc="default">
            <name>Receiver Behavior</name>
            <t>On receiving a SCHC Fragment with a Rule ID RuleID and DTag pair not being processed at that time</t>

<t><list style="symbols">
  <t>the time:</t>
            <ul spacing="normal">
              <li>the receiver SHOULD <bcp14>SHOULD</bcp14> check if the DTag value has not recently been used for that Rule ID RuleID value,
thereby ensuring that the received SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission.
The initial value of the Inactivity Timer is the RECOMMENDED <bcp14>RECOMMENDED</bcp14> lifetime for the DTag value at the receiver.
If the SCHC Fragment is determined to be such a remnant, the receiver MAY <bcp14>MAY</bcp14> silently ignore it and discard it.</t>
  <t>the it.</li>
              <li>the receiver MUST <bcp14>MUST</bcp14> start a process to assemble a new SCHC Packet with that Rule ID RuleID and DTag value pair.
The receiver MUST <bcp14>MUST</bcp14> start an Inactivity Timer for that Rule ID RuleID and DTag value pair.
It MUST <bcp14>MUST</bcp14> initialize an Attempts counter to 0 for that Rule ID RuleID and DTag value pair.
If the receiver is under-resourced to do this, it MUST <bcp14>MUST</bcp14> respond to the sender with a SCHC Receiver Abort.</t>
</list></t> Receiver-Abort.</li>
            </ul>
            <t>On reception of any SCHC F/R message for the RuleID and DTag pair being processed, the receiver MUST <bcp14>MUST</bcp14> reset the Inactivity Timer pertaining to that RuleID and DTag pair.</t>
            <t>All message receptions being discussed in the rest of this section are to be understood as
“matching
"matching the RuleID and DTag pair being processed”, processed", even if not spelled out, for brevity.</t>
            <t>On receiving a SCHC Fragment message,
the receiver determines what tiles were received, based on the payload length and on the W and FCN fields of the SCHC Fragment.</t>

<t><list style="symbols">
  <t>if
            <ul spacing="normal">
              <li>if the FCN is All-1, if a Payload is present, the full SCHC Fragment Payload MUST <bcp14>MUST</bcp14> be assembled including the padding bits.
This is because the size of the last tile is not known by the receiver,
therefore receiver;
therefore, padding bits are indistinguishable from the tile data bits, at this stage.
They will be removed by the SCHC C/D sublayer.
If the size of the SCHC Fragment Payload exceeds or equals
the size of one regular tile plus the size of an L2 Word, this SHOULD <bcp14>SHOULD</bcp14> raise an error flag.</t> flag.</li>
              <li>
                <t>otherwise, tiles MUST <bcp14>MUST</bcp14> be assembled based on the a priori known tile size.
  <list style="symbols">
      <t>If
                </t>
                <ul spacing="normal">
                  <li>If allowed by the Profile, the end of the payload MAY <bcp14>MAY</bcp14> contain the last tile, which may be shorter. Padding bits are indistinguishable from the tile data bits, at this stage.</t>
      <t>the stage.</li>
                  <li>The payload may contain the penultimate tile that, if allowed by the Profile, MAY <bcp14>MAY</bcp14> be exactly one L2 Word shorter than the regular tile size.</t> size.</li>
                  <li>
                    <t>Otherwise, padding bits MUST <bcp14>MUST</bcp14> be discarded.
The latter
This is possible because      <list style="symbols">
          <t>the because:</t>
                    <ul spacing="normal">
                      <li>the size of the tiles is known a priori,</t>
          <t>tiles priori,</li>
                      <li>tiles are larger than an L2 Word</t>
          <t>padding Word, and</li>
                      <li>padding bits are always strictly less than an L2 Word</t>
        </list></t>
    </list></t>
</list></t> Word.</li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
            <t>On receiving a SCHC ACK REQ or an All-1 SCHC Fragment,</t>

<t><list style="symbols">
  <t>if Fragment:</t>
            <ul spacing="normal">
              <li>if the receiver knows of any windows with missing tiles for the packet being reassembled, it
MUST
<bcp14>MUST</bcp14> return a SCHC ACK for the lowest-numbered such window,</t>
  <t>otherwise,
  <list style="symbols">
      <t>if window:</li>
              <li>
                <t>otherwise:
                </t>
                <ul spacing="normal">
                  <li>if it has received at least one tile, it MUST <bcp14>MUST</bcp14> return a SCHC ACK for the highest-numbered window it currently has tiles for</t>
      <t>otherwise for,</li>
                  <li>otherwise, it MUST <bcp14>MUST</bcp14> return a SCHC ACK for window numbered 0</t>
    </list></t>
</list></t> 0.</li>
                </ul>
              </li>
            </ul>
            <t>A Profile MAY <bcp14>MAY</bcp14> specify other times and circumstances at which
a receiver sends a SCHC ACK,
and which window the SCHC ACK reports about in these circumstances.</t>
            <t>Upon sending a SCHC ACK, the receiver MUST <bcp14>MUST</bcp14> increase the Attempts counter.</t>
            <t>After receiving an All-1 SCHC Fragment,
a receiver MUST <bcp14>MUST</bcp14> check the integrity of the reassembled SCHC Packet at least every time
it prepares for sending a SCHC ACK for the last window.</t>
            <t>Upon receiving a SCHC Sender-Abort,
the receiver MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
            <t>Upon expiration of the Inactivity Timer,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC Receiver-Abort Receiver-Abort,
and it MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
            <t>On the Attempts counter exceeding MAX_ACK_REQUESTS,
the receiver MUST <bcp14>MUST</bcp14> send a SCHC Receiver-Abort Receiver-Abort,
and it MAY <bcp14>MAY</bcp14> exit with an error condition.</t>
            <t>Reassembly of the SCHC Packet concludes when</t>

<t><list style="symbols">
  <t>a when:</t>
            <ul spacing="normal">
              <li>a Sender-Abort has been received</t>
  <t>or the received, or</li>
              <li>the Inactivity Timer has expired</t>
  <t>or the expired, or</li>
              <li>the Attempts counter has exceeded MAX_ACK_REQUESTS</t>
  <t>or when at MAX_ACK_REQUESTS, or</li>
              <li>at least an All-1 SCHC Fragment has been received and integrity checking of the reassembled SCHC Packet is successful.</t>
</list></t> successful.</li>
            </ul>

            <t>See <xref target="Fig-ACKonerrorRcv"/> target="Fig-ACKonerrorRcv" format="default"/> for one among several possible examples of a Finite State Machine implementing a receiver behavior obeying this specification,
and that specification. The example provided is meant to match the sender Finite State Machine of <xref target="Fig-ACKonerrorSnd"/>.</t> target="Fig-ACKonerrorSnd" format="default"/>.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="Padding" title="Padding management"> numbered="true" toc="default">
      <name>Padding Management</name>
      <t>SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does not have any alignment prerequisite.
The size of SCHC Packets can be any number of bits.</t>
      <t>If the layer below SCHC L2 constrains the payload to align to some boundary, called L2 Words coarser boundaries (for example, bytes),
the SCHC messages MUST <bcp14>MUST</bcp14> be padded.
When padding occurs, the number of appended bits MUST <bcp14>MUST</bcp14> be strictly less than the L2 Word size.</t>
      <t>If a SCHC Packet is sent unfragmented (see <xref target="Fig-Operations-Pad"/>), target="Fig-Operations-Pad" format="default"/>), it is padded as needed for transmission.</t>
      <t>If a SCHC Packet needs to be fragmented for transmission, it is not padded in itself. Only the SCHC F/R messages are padded as needed for transmission.
Some SCHC F/R messages are intrinsically aligned to L2 Words.</t>
      <figure title="SCHC operations, including padding anchor="Fig-Operations-Pad">
        <name>SCHC Operations, Including Padding as needed" anchor="Fig-Operations-Pad"><artwork><![CDATA[ Needed</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
A packet (e.g., an IPv6 packet)
         |                                           ^ (padding bits
         v                                           |       dropped)
+------------------+                      +--------------------+
| SCHC Compression |                      | SCHC Decompression |
+------------------+                      +--------------------+
         |                                           ^
         |   If no fragmentation fragmentation,                    |
         +---- SCHC Packet + padding as needed ----->|
         |                                           | (integrity
         v                                           |  checked)
+--------------------+                       +-----------------+
| SCHC Fragmentation |                       | SCHC Reassembly |
+--------------------+                       +-----------------+
     |       ^                                   |       ^
     |       |                                   |       |
     |       +--- SCHC ACK + padding as needed --+       |
     |                                                   |
     +------- SCHC Fragments + padding as needed---------+

        Sender                                    Receiver

]]></artwork></figure>                                    Receiver]]></artwork>
      </figure>
      <t>Each Profile MUST <bcp14>MUST</bcp14> specify the size of the L2 Word.
The L2 Word might actually be a single bit, in which case no padding will take place at all.</t>
      <t>A Profile MAY <bcp14>MUST</bcp14> define the value of the padding bits. bits if the L2 Word is wider than a single bit. The RECOMMENDED <bcp14>RECOMMENDED</bcp14> value is 0.</t>
    </section>
    <section anchor="schc-compression-for-ipv6-and-udp-headers" title="SCHC numbered="true" toc="default">
      <name>SCHC Compression for IPv6 and UDP headers"> Headers</name>
      <t>This section lists the IPv6 and UDP header fields and describes how they can be compressed.
An example of a set of Rules for UDP/IPv6 header compression is provided in <xref target="compressIPv6"/>.</t> target="compressIPv6" format="default"/>.</t>
      <section anchor="ipv6-version-field" title="IPv6 version field"> numbered="true" toc="default">
        <name>IPv6 Version Field</name>
        <t>The IPv6 version field is labeled by the protocol parser as being the “version” "version" field of the IPv6 protocol.
Therefore, it only exists for IPv6 packets.
In the Rule, TV is set to 6, MO to “ignore” "ignore"
and CDA to “not-sent”.</t> "not-sent".</t>
      </section>
      <section anchor="ipv6-traffic-class-field" title="IPv6 numbered="true" toc="default">
        <name>IPv6 Traffic class field"> Class Field</name>

        <t>If the DiffServ Diffserv field does not vary and is known by both sides, the Field Descriptor in the Rule SHOULD <bcp14>SHOULD</bcp14> contain a TV with
this well-known value, an “equal” MO "equal" MO, and a “not-sent” "not-sent" CDA.</t>
        <t>Otherwise (e.g., ECN bits are to be transmitted), two possibilities can be considered depending on the variability of the value:</t>

<t><list style="symbols">
  <t>One
        <ul spacing="normal">
          <li>One possibility is to not compress the field and send the original value. In the Rule, TV is not set to any particular value, MO is set to “ignore” "ignore", and CDA is set to “value-sent”.</t> "value-sent".</li>
          <li>
            <t>If some upper bits in the field are constant and known, a better option is to only send the LSBs. In the Rule, TV is set to a value with the stable known upper part, MO is set to MSB(x) MSB(x), and CDA to LSB.  <vspace blankLines='1'/>  </t>
            <t>
ECN functionality depends on both bits of the ECN field, which
are the 2 LSBs of this field, hence field; hence, sending only a single
LSB of this field is NOT RECOMMENDED.</t>
</list></t> <bcp14>NOT RECOMMENDED</bcp14>.</t>
          </li>
        </ul>
      </section>
      <section anchor="flow-label-field" title="Flow label field"> numbered="true" toc="default">
        <name>Flow Label Field</name>
        <t>If the flow label is not set, i.e. i.e., its value is zero, the Field Descriptor in the Rule SHOULD <bcp14>SHOULD</bcp14> contain a TV set to zero, an “equal” MO "equal" MO, and a “not-sent” "not-sent" CDA.</t>
        <t>If the flow label is set to a pseudo-random pseudorandom value according to <xref target="RFC6437"/>, target="RFC6437" format="default"/>, in the Rule, TV is not set to any particular value, MO is set to “ignore” "ignore", and CDA is set to “value-sent”.</t> "value-sent".</t>
        <t>If the flow label is set according to some prior agreement, i.e. i.e., by a flow state establishment method as allowed by <xref target="RFC6437"/>, target="RFC6437" format="default"/>,
the Field Descriptor in the Rule SHOULD <bcp14>SHOULD</bcp14> contain a TV with this agreed-upon value, an “equal” MO "equal" MO, and a “not-sent” "not-sent" CDA.</t>
      </section>
      <section anchor="payload-length-field" title="Payload numbered="true" toc="default">
        <name>Payload Length field"> Field</name>
        <t>This field can be elided for the transmission on the LPWAN network. LPWAN. The SCHC C/D recomputes the original payload length value. In the Field Descriptor, TV is not set, MO is set to “ignore” "ignore", and CDA is “compute-*”.</t> "compute-*".</t>
      </section>
      <section anchor="next-header-field" title="Next numbered="true" toc="default">
        <name>Next Header field"> Field</name>
        <t>If the Next Header field does not vary and is known by both sides, the Field Descriptor in the Rule SHOULD <bcp14>SHOULD</bcp14> contain a TV with
this Next Header value, the MO SHOULD <bcp14>SHOULD</bcp14> be “equal” "equal", and the CDA SHOULD <bcp14>SHOULD</bcp14> be “not-sent”.</t> "not-sent".</t>
        <t>Otherwise, TV is not set in the Field Descriptor, MO is set to “ignore” "ignore", and CDA is set to “value-sent”. "value-sent". Alternatively, a matching-list MAY <bcp14>MAY</bcp14> also be used.</t>
      </section>
      <section anchor="hop-limit-field" title="Hop numbered="true" toc="default">
        <name>Hop Limit field"> Field</name>
        <t>The field behavior for this field is different for uplink (Up) Uplink and downlink (Dw). Downlink.
In Up, Uplink, since there is no IP forwarding between the Dev and the SCHC C/D, the value is relatively constant.
On the other hand, the Dw Downlink value depends on Internet routing and can change more frequently.
The Direction Indicator (DI) DI can be used to distinguish both directions:</t>

<t><list style="symbols">
  <t>in the Up,
        <ul spacing="normal">
          <li>in an Up Field Descriptor, elide the field: the TV in the Field Descriptor is set to the known constant value, the MO is set to “equal” "equal" and the CDA is set to “not-sent”.</t>
  <t>in the Dw, "not-sent".</li>
          <li>in a Dw Field Descriptor, the Hop Limit is elided for transmission and forced to 1 at the receiver, by setting TV to 1, MO to “ignore” "ignore" and CDA to “not-sent”. "not-sent". This prevents any further forwarding.</t>
</list></t> forwarding.</li>
        </ul>
      </section>
      <section anchor="ipv6-addresses-fields" title="IPv6 addresses fields"> numbered="true" toc="default">
        <name>IPv6 Addresses Fields</name>
        <t>As in 6LoWPAN <xref target="RFC4944"/>, target="RFC4944" format="default"/>, IPv6 addresses are split into two 64-bit long 64-bit-long fields; one for the prefix and one for the Interface Identifier (IID). These fields SHOULD <bcp14>SHOULD</bcp14> be compressed. To allow for a single Rule being used for both directions, these values are identified by their role (Dev or App) and not by their position in the header (source or destination).</t>
        <section anchor="ipv6-source-and-destination-prefixes" title="IPv6 source numbered="true" toc="default">
          <name>IPv6 Source and destination prefixes"> Destination Prefixes</name>
          <t>Both ends MUST <bcp14>MUST</bcp14> be configured with the appropriate prefixes. For a specific flow, the source and destination prefixes can be unique and stored in the Context.
In that case, the TV for the
source and destination prefixes contain the values, the MO is set to “equal” "equal" and the CDA is set to “not-sent”.</t> "not-sent".</t>
          <t>If the Rule is intended to compress packets with different prefix values, match-mapping SHOULD <bcp14>SHOULD</bcp14> be used. The different prefixes are listed in the TV, the MO is set to “match-mapping” "match-mapping" and the CDA is set to “mapping-sent”. "mapping-sent". See <xref target="Fig-fields"/>.</t> target="Fig-fields" format="default"/>.</t>
          <t>Otherwise, the TV is not set, the MO is set to “ignore” "ignore", and the CDA is set to “value-sent”.</t> "value-sent".</t>
        </section>
        <section anchor="ipv6-source-and-destination-iid" title="IPv6 source numbered="true" toc="default">
          <name>IPv6 Source and destination IID"> Destination IID</name>
          <t>If the Dev or App IID are based on an LPWAN L2 address, then the IID can be reconstructed with information coming from the LPWAN L2 header. In that case, the TV is not set, the MO is set to “ignore” "ignore" and the CDA is set to “DevIID” "DevIID" or “AppIID”. "AppIID".
On LPWAN technologies where the frames carry a single identifier (corresponding to the Dev.), Dev), AppIID cannot be used.</t>
          <t>As described in <xref target="RFC8065"/>, target="RFC8065" format="default"/>, it may be undesirable to build the Dev IPv6 IID out of the Dev address. Another static value is used instead.
In that case, the TV contains the static value, the MO operator is set to “equal” "equal" and the CDA is set to “not-sent”.</t> "not-sent".</t>
          <t>If several IIDs are possible, then the TV contains the list of possible IIDs, the MO is set to “match-mapping” "match-mapping" and the CDA is set to “mapping-sent”.</t> "mapping-sent".</t>
          <t>It may also happen that the IID variability only expresses itself on a few bytes. In that case, the TV is set to the stable part of the IID, the MO is set to “MSB” "MSB" and the CDA is set to “LSB”.</t> "LSB".</t>
          <t>Finally, the IID can be sent in its entirety on the LPWAN. L2. In that case, the TV is not set, the MO is set to “ignore” "ignore", and the CDA is set to “value-sent”.</t> "value-sent".</t>
        </section>
      </section>
      <section anchor="ipv6-extension-headers" title="IPv6 extension headers"> numbered="true" toc="default">
        <name>IPv6 Extension Headers</name>
        <t>This document does not provide recommendations on how to compress IPv6 extension headers.</t>
      </section>
      <section anchor="udp-source-and-destination-ports" title="UDP source numbered="true" toc="default">
        <name>UDP Source and destination ports"> Destination Ports</name>
        <t>To allow for a single Rule being used for both directions, the UDP port values are identified by their role (Dev or App) and not by their position in the header (source or destination). The SCHC C/D MUST <bcp14>MUST</bcp14> be aware of the traffic direction (Uplink, Downlink) to select the appropriate field. The following Rules apply for Dev and App port numbers.</t>
        <t>If both ends know the port number, it can be elided. The TV
	contains the port number, the MO is set to “equal” "equal", and the CDA is set to “not-sent”.</t> "not-sent".</t>
        <t>If the port variation is on few bits, the TV contains the stable part of the port number, the MO is set to “MSB” "MSB", and the CDA is set to “LSB”.</t> "LSB".</t>
        <t>If some well-known values are used,  the TV can contain the list of these values, the MO is set to “match-mapping” "match-mapping", and the CDA is set to “mapping-sent”.</t>

<t>Otherwise "mapping-sent".</t>
        <t>Otherwise, the port numbers are sent over the LPWAN. L2. The TV is not set, the MO is set to “ignore” "ignore" and the CDA is set to “value-sent”.</t> "value-sent".</t>
      </section>
      <section anchor="udp-length-field" title="UDP length field"> numbered="true" toc="default">
        <name>UDP Length Field</name>
        <t>The parser MUST NOT label this field unless the UDP length can be computed Length value
matches the Payload Length value from the received data. IPv6 header.
The TV is not set, the MO is set to “ignore” "ignore", and the CDA is set to “compute-*”.</t>
"compute-*”.</t>
      </section>
      <section anchor="UDPchecksum" title="UDP numbered="true" toc="default">
        <name>UDP Checksum field"> Field</name>
        <t>The UDP checksum operation is mandatory with IPv6 for most
packets
packets, but there are exceptions <xref target="RFC8200"></xref>.</t> target="RFC8200" format="default"/>.</t>
        <t>For instance, protocols that use UDP as a tunnel encapsulation may
enable zero-checksum mode for a specific port (or set of ports) for
sending and/or receiving. <xref target="RFC8200"></xref> target="RFC8200" format="default"/> requires any node
implementing zero-checksum mode to follow the requirements specified
in “Applicability "Applicability Statement for the Use of IPv6 UDP Datagrams with
Zero Checksums” Checksums" <xref target="RFC6936"></xref>.</t> target="RFC6936" format="default"/>.</t>
        <t>6LoWPAN Header Compression <xref target="RFC6282"></xref> target="RFC6282" format="default"/> also specifies that a UDP
checksum can be elided by the compressor and re-computed recomputed by the decompressor when an upper
layer guarantees the integrity of the UDP payload and pseudo-header.
A specific example of this is
when a message integrity check protects the compressed message
between the compressor that elides the UDP checksum and the decompressor
that computes it,
with a strength that is identical or better to
the UDP checksum.</t>
        <t>Similarly, a SCHC compressor MAY <bcp14>MAY</bcp14>
elide the UDP checksum when another layer guarantees at least equal
integrity protection for the UDP payload and the pseudo-header.
In this case, the TV is not set, the MO is set to “ignore” "ignore", and the CDA is set to “compute-*”.</t> "compute-*".</t>
        <t>In particular, when SCHC fragmentation is used, a fragmentation RCS
of 2 bytes or more provides equal or better protection than the UDP
checksum; in that case, if the compressor is collocated with the
fragmentation point and the decompressor is collocated with the
packet reassembly point,
and if the SCHC Packet is fragmented even when it would fit unfragmented in the L2 MTU,
then the compressor MAY <bcp14>MAY</bcp14> verify and then elide the UDP checksum.
Whether and when the UDP Checksum is elided is to be specified in the
Profile.</t>
        <t>Since the compression happens before the fragmentation, implementers
should understand the risks when dealing with unprotected data below
the transport layer and take special care when manipulating that data.</t>
        <t>In other cases, the checksum SHOULD <bcp14>SHOULD</bcp14> be explicitly sent. The TV is not set, the MO is set to “ignore” "ignore" and the CDA is set to “value-sent”.</t> "value-sent".</t>
      </section>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no request to IANA.</t> IANA actions.</t>
    </section>
    <section anchor="SecConsiderations" title="Security considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>As explained in <xref target="Overview"/>, target="Overview" format="default"/>, SCHC is expected to be implemented on top of LPWAN technologies,
which are expected to implement security measures.</t>
      <t>In this section, we analyze the potential security threats that could be introduced
into an LPWAN by adding the SCHC functionalities.</t>
      <section anchor="security-considerations-for-schc-compressiondecompression" title="Security considerations numbered="true" toc="default">
        <name>Security Considerations for SCHC Compression/Decompression"> Compression/Decompression</name>
        <section anchor="forged-schc-packet" title="Forged numbered="true" toc="default">
          <name>Forged SCHC Packet">
<t>Let’s Packet</name>
          <t>Let's assume that an attacker is able to send a forged SCHC Packet to a SCHC Decompressor.</t>

<t>Let’s decompressor.</t>
          <t>Let's first consider the case where the Rule ID RuleID contained in that forged SCHC Packet does not correspond to a Rule allocated in the Rule table.
An implementation should detect that the Rule ID RuleID is invalid and should silently drop the offending SCHC Packet.</t>

<t>Let’s
          <t>Let's now consider that the Rule ID RuleID corresponds to a Rule in the table. With the CDAs defined in this document, the reconstructed packet is is, at most most, a constant number of bits bigger than the SCHC Packet that was received.
This assumes that the compute-* decompression actions produce a bounded number of bits, irrespective of the incoming SCHC Packet. This property is true for IPv6 Length, UDP Length Length, and UDP Checksum, for which the compute-* CDA is recommended by this document.</t>
          <t>As a consequence, SCHC Decompression decompression does not amplify attacks, beyond adding a bounded number of bits to the SCHC Packet received. This bound is determined by the Rule stored in the receiving device.</t>
          <t>As a general safety measure, a SCHC Decompressor decompressor should never re-construct reconstruct a packet larger than MAX_PACKET_SIZE (defined in a Profile, with 1500 bytes as generic default).</t>
        </section>
        <section anchor="compressed-packet-size-as-a-side-channel-to-guess-a-secret-token" title="Compressed packet size numbered="true" toc="default">
          <name>Compressed Packet Size as a side channel Side Channel to guess Guess a secret token"> Secret Token</name>
          <t>Some packet compression methods are known to be susceptible to attacks, such as BREACH and CRIME.
The attack involves injecting arbitrary data into the packet and observing the resulting compressed packet size. The observed size potentially reflects correlation between the arbitrary data and some content that was meant to remain secret, such as a security token, thereby allowing the attacker to get at the secret.</t>
          <t>By contrast, SCHC Compression compression takes place header field by header field,
with the SCHC Packet being a mere concatenation of the compression residues of each of the individual field.
Any correlation between header fields does not result in a change in the SCHC Packet size compressed under the same Rule.</t>
          <t>If SCHC C/D is used to compress packets that include a secret information field, such as a token,
the Rule set should be designed so that the size of the compression residue for the field to remain secret
is the same irrespective of the value of the secret information.
This is achieved by by, e.g., sending this field in extenso with the “ignore” "ignore" MO and the “value-sent” "value-sent" CDA.
This recommendation is disputable if it is ascertained that the Rule set itself will remain secret.</t>
        </section>
        <section anchor="decompressed-packet-different-from-the-original-packet" title="Decompressed packet different numbered="true" toc="default">
          <name>Decompressed Packet Different from the original packet"> Original Packet</name>
          <t>As explained in <xref target="PProcessing"/>, target="PProcessing" format="default"/>, using FPs with value 0 in Field Descriptors in a Rule may result in header fields
appearing in the decompressed packet in an order different from that in the original packet.
Likewise, as stated in <xref target="NotSentCDA"/>, target="NotSentCDA" format="default"/>, using an “ignore” "ignore" MO together with a “not-sent” "not-sent" CDA will
result in the header field taking the TV value, which is likely to be different from the original value.</t>
          <t>Depending on the protocol, the order of header fields in
	  the packet may or may not be functionally significant or not.</t> significant.</t>
          <t>Furthermore, if the packet is protected by a checksum or a similar integrity protection mechanism,
and if the checksum is transmitted instead of being recomputed as part of the decompression,
these situations may result in the packet being considered corrupt and dropped.</t>
        </section>
      </section>
      <section anchor="security-considerations-for-schc-fragmentationreassembly" title="Security considerations numbered="true" toc="default">
        <name>Security Considerations for SCHC Fragmentation/Reassembly"> Fragmentation/Reassembly</name>
        <section anchor="buffer-reservation-attack" title="Buffer reservation attack">
<t>Let’s numbered="true" toc="default">
          <name>Buffer Reservation Attack</name>
          <t>Let's assume that an attacker is able to send a forged SCHC Fragment to a SCHC Reassembler.</t> reassembler.</t>
          <t>A node can perform a buffer reservation attack: the receiver will reserve buffer space for the SCHC Packet. If the implementation has only one buffer, other incoming fragmented SCHC Packets will be dropped while the reassembly buffer is occupied during the reassembly timeout. Once that timeout expires, the attacker can repeat the same procedure, and iterate, thus thus, creating a denial of service denial-of-service attack.
An implementation may have multiple reassembly buffers. The cost to mount this attack is linear with the number of buffers at the target node.
Better, the cost for an attacker can be increased if individual
fragments of multiple SCHC Packets can be stored in the reassembly
buffer. The finer grained the reassembly buffer (downto (down to the smallest tile size), the higher the cost of the attack.
If buffer overload does occur, a smart receiver could selectively discard SCHC Packets being reassembled based on the sender behavior, which may help identify which SCHC Fragments have been sent by the attacker.
Another mild counter-measure countermeasure is for the target to abort the fragmentation/reassembly session as early as it detects a non-identical SCHC Fragment duplicate, anticipating for an eventual corrupt SCHC Packet, so as to save the sender the hassle of sending the rest of the fragments for this SCHC Packet.</t>
        </section>
        <section anchor="corrupt-fragment-attack" title="Corrupt numbered="true" toc="default">
          <name>Corrupt Fragment attack">
<t>Let’s Attack</name>
          <t>Let's assume that an attacker is able to send a forged SCHC Fragment to a SCHC Reassembler. reassembler.
The malicious node is additionally assumed to be able to hear an incoming communication destined to the target node.</t>
          <t>It can then send a forged SCHC Fragment that looks like it belongs to a SCHC Packet already being reassembled at the target node.
This can cause the SCHC Packet to be considered corrupt and to be dropped by the receiver.
The amplification happens here by a single spoofed SCHC Fragment rendering a full sequence of legit legitimate SCHC Fragments useless.
If the target uses ACK-Always or ACK-on-Error mode, such a malicious node can also interfere with
the acknowledgement and repetition algorithm of SCHC F/R.
A single spoofed ACK, with all bitmap Bitmap bits set to 0, will trigger the repetition of WINDOW_SIZE tiles. This protocol loop amplification depletes the energy source of the target node and consumes the channel bandwidth.
Similarly, a spoofed ACK REQ will trigger the sending of a SCHC ACK,
which may be much larger than the ACK REQ if WINDOW_SIZE is large.
These consequences should be borne in mind when defining profiles for SCHC over specific LPWAN technologies.</t>
        </section>
        <section anchor="fragmentation-as-a-way-to-bypass-network-inspection" title="Fragmentation numbered="true" toc="default">
          <name>Fragmentation as a way Way to bypass Bypass Network Inspection"> Inspection</name>
          <t>Fragmentation is known for potentially allowing one to force through a Network Inspection device (e.g., firewall) packets that would be rejected if unfragmented.
This involves sending overlapping fragments to rewrite fields whose initial value led the Network Inspection device to allow the flow to go through.</t>
          <t>SCHC F/R is expected to be used over one LPWAN link, where no Network Inspection device is expected to sit.
As described in <xref target="FunctionalMapping"/>, target="FunctionalMapping" format="default"/>, even if the SCHC F/R on the Network infrastructure Infrastructure side is located
in the Internet, a tunnel is to be established between it and the NGW.</t>
        </section>
        <section anchor="privacy-issues-associated-with-schc-header-fields" title="Privacy issues associated numbered="true" toc="default">
          <name>Privacy Issues Associated with SCHC header fields"> Header Fields</name>
          <t>SCHC F/R allocates a DTag value to fragments belonging to the same SCHC Packet.
Concerns were raised that, if DTag is a wide counter that is incremented in a predictable fashion for each new fragmented SCHC Packet,
it might lead to a privacy issue, such as enabling tracking of a device across LPWANs.</t>
          <t>However, SCHC F/R is expected to be used over exactly one LPWAN link.
As described in <xref target="FunctionalMapping"/>, target="FunctionalMapping" format="default"/>, even if the SCHC F/R on the Network infrastructure Infrastructure side is located
in the Internet, a tunnel is to be established between it and the NGW.
Therefore, assuming the tunnel provides confidentiality, neither the DTag field nor any other SCHC-introduced field is visible over the Internet.</t>

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

<t>Thanks to (in alphabetical order)
Sergio Aguilar Romero,
David Black,
Carsten Bormann,
Deborah Brungard,
Brian Carpenter,
Philippe Clavier,
Alissa Cooper,
Roman Danyliw,
Daniel Ducuara Beltran,
Diego Dujovne,
Eduardo Ingles Sanchez,
Rahul Jadhav,
Benjamin Kaduk,
Arunprabhu Kandasamy,
Suresh Krishnan,
Mirja Kuehlewind,
Barry Leiba,
Sergio Lopez Bernal,
Antoni Markovski,
Alexey Melnikov,
Georgios Papadopoulos,
Alexander Pelov,
Charles Perkins,
Edgar Ramos,
Alvaro Retana,
Adam Roach,
Shoichi Sakane,
Joseph Salowey,
Pascal Thubert,
and Eric Vyncke
for useful design considerations, reviews and comments.</t>

<t>Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336, and by the ERDF and the Spanish Government through project TEC2016-79988-P.  Part of his contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge.</t>

</section>

  </middle>

  <back>

    <references title='Normative References'>

<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="RFC6936" target='https://www.rfc-editor.org/info/rfc6936'>
<front>
<title>Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums</title>
<author initials='G.' surname='Fairhurst' fullname='G. Fairhurst'><organization /></author>
<author initials='M.' surname='Westerlund' fullname='M. Westerlund'><organization /></author>
<date year='2013' month='April' />
<abstract><t>This document provides an applicability statement for the use of UDP transport checksums with IPv6.  It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum.  It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum.  The document also identifies issues and constraints for deployment on network paths that include middleboxes.  An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.</t></abstract>
</front>
<seriesInfo name='RFC' value='6936'/>
<seriesInfo name='DOI' value='10.17487/RFC6936'/>
</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="RFC8200" target='https://www.rfc-editor.org/info/rfc8200'>
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author>
<author initials='R.' surname='Hinden' fullname='R. Hinden'><organization /></author>
<date year='2017' month='July' />
<abstract><t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t></abstract>
</front>
<seriesInfo name='STD' value='86'/>
<seriesInfo name='RFC' value='8200'/>
<seriesInfo name='DOI' value='10.17487/RFC8200'/>
</reference>

<reference  anchor="RFC8376" target='https://www.rfc-editor.org/info/rfc8376'>
<front>
<title>Low-Power Wide Area Network (LPWAN) Overview</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell' role='editor'><organization /></author>
<date year='2018' month='May' />
<abstract><t>Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation.  This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.</t></abstract>
</front>
<seriesInfo name='RFC' value='8376'/>
<seriesInfo name='DOI' value='10.17487/RFC8376'/>
</reference>

    </references>

    <references title='Informative References'>

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

<reference  anchor="RFC5795" target='https://www.rfc-editor.org/info/rfc5795'>
<front>
<title>The RObust Header Compression (ROHC) Framework</title>
<author initials='K.' surname='Sandlund' fullname='K. Sandlund'><organization /></author>
<author initials='G.' surname='Pelletier' fullname='G. Pelletier'><organization /></author>
<author initials='L-E.' surname='Jonsson' fullname='L-E. Jonsson'><organization /></author>
<date year='2010' month='March' />
<abstract><t>The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept.  It is designed to operate efficiently and robustly over various link technologies with different characteristics.</t><t>The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095.  To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately.  More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.</t><t>This specification obsoletes RFC 4995.  It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5795'/>
<seriesInfo name='DOI' value='10.17487/RFC5795'/>
</reference>

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

<reference  anchor="RFC6437" target='https://www.rfc-editor.org/info/rfc6437'>
<front>
<title>IPv6 Flow Label Specification</title>
<author initials='S.' surname='Amante' fullname='S. Amante'><organization /></author>
<author initials='B.' surname='Carpenter' fullname='B. Carpenter'><organization /></author>
<author initials='S.' surname='Jiang' fullname='S. Jiang'><organization /></author>
<author initials='J.' surname='Rajahalme' fullname='J. Rajahalme'><organization /></author>
<date year='2011' month='November' />
<abstract><t>This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.  Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.</t><t>The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6437'/>
<seriesInfo name='DOI' value='10.17487/RFC6437'/>
</reference>

<reference  anchor="RFC7136" target='https://www.rfc-editor.org/info/rfc7136'>
<front>
<title>Significance of IPv6 Interface Identifiers</title>
<author initials='B.' surname='Carpenter' fullname='B. Carpenter'><organization /></author>
<author initials='S.' surname='Jiang' fullname='S. Jiang'><organization /></author>
<date year='2014' month='February' />
<abstract><t>The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods.  This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value.  In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier.  This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.</t></abstract>
</front>
<seriesInfo name='RFC' value='7136'/>
<seriesInfo name='DOI' value='10.17487/RFC7136'/>
</reference>

<reference  anchor="RFC8065" target='https://www.rfc-editor.org/info/rfc8065'>
<front>
<title>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms</title>
<author initials='D.' surname='Thaler' fullname='D. Thaler'><organization /></author>
<date year='2017' month='February' />
<abstract><t>This document discusses how located
in the Internet, a number of privacy threats apply tunnel is to technologies designed for IPv6 over various link-layer protocols, and be established between it and the NGW.
Therefore, assuming the tunnel provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 confidentiality, neither the DTag field nor any other SCHC-introduced field is visible over such links.</t></abstract>
</front>
<seriesInfo name='RFC' value='8065'/>
<seriesInfo name='DOI' value='10.17487/RFC8065'/>
</reference> the Internet.</t>
        </section>
      </section>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6936.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5795.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7136.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8065.xml"/>

<reference anchor="ETHERNET" > target="https://ieeexplore.ieee.org/document/6419735" quoteTitle="true" derivedAnchor="IEEE-802.3-2012">
<front>
<title>IEEE Standard for Ethernet</title>
    <author >
      <organization></organization>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6419735"/>
<seriesInfo name="IEEE Standard" value="802.3-2012"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date year="n.d."/> month="December" year="2012"/>
</front>
  <seriesInfo name="IEEE" value="standard"/>
  <seriesInfo name="DOI" value="10.1109/ieeestd.2018.8457469"/>
</reference>

      </references>
    </references>
    <section anchor="compressIPv6" title="Compression Examples"> numbered="true" toc="default">
      <name>Compression Examples</name>

      <t>This section gives some scenarios of the compression mechanism for IPv6/UDP. The goal is to illustrate the behavior of SCHC.</t>
      <t>The mechanisms defined in this document can be applied to a Dev that embeds some applications running over CoAP. In this example, three flows are considered. The first flow is for the device management based
on CoAP using Link Local IPv6 addresses and UDP ports 123 and 124 for
Dev and App, respectively. The second flow will be is a CoAP server for measurements done by the Dev (using ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to beta::1/64.
The last flow is for legacy applications using different ports numbers, the destination IPv6 address prefix is gamma::1/64.</t>
      <t><xref target="FigStack"/> target="FigStack" format="default"/> presents the protocol stack. IPv6 and UDP are represented with dotted lines since these protocols are compressed on the radio link.</t>
      <figure title="Simplified anchor="FigStack">
        <name>Simplified Protocol Stack for LP-WAN" anchor="FigStack"><artwork><![CDATA[ LP-WAN</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Management   Data
+----------+---------+---------+
|   CoAP   |  CoAP   | legacy  |
+----||----+---||----+---||----+
.   UDP    .  UDP    |   UDP   |
................................
.   IPv6   .  IPv6   .  IPv6   .
+------------------------------+
|    SCHC Header compression   |
|      and fragmentation       |
+------------------------------+
|      LPWAN L2 technologies   |
+------------------------------+
         Dev or NGW

]]></artwork></figure>

<t>In some LPWAN technologies, only the Devs have a device ID.
When such technologies are used, it is necessary to statically define an IID for the Link Local address for the SCHC C/D.</t> NGW]]></artwork>
      </figure>

      <figure title="Context Rules" anchor="Fig-fields"><artwork><![CDATA[ anchor="Fig-fields">
        <name>Context Rules - Rule 0
  Special and Rule ID 1</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Rule 0
  Special RuleID used to tag an uncompressed UDP/IPV6 packet.

Rule 1
 +----------------+--+--+--+---------+--------+------------++------+
 | Field               FID      |FL|FP|DI| Value      TV   | Match   MO   | Comp Decomp||     CDA    || Sent |
 |                |  |  |  |         | Opera.        | Action            ||[bits]|
 +----------------+--+--+--+---------+---------------------++------+
 |IPv6 Version    |4 |1 |Bi|6        | ignore | not-sent   ||      |
 |IPv6 DiffServ Diffserv   |8 |1 |Bi|0        | equal  | not-sent   ||      |
 |IPv6 Flow Label |20|1 |Bi|0        | equal  | not-sent   ||      |
 |IPv6 Length     |16|1 |Bi|         | ignore | compute-*  ||      |
 |IPv6 Next Header|8 |1 |Bi|17       | equal  | not-sent   ||      |
 |IPv6 Hop Limit  |8 |1 |Bi|255      | ignore | not-sent   ||      |
 |IPv6 DevPrefix  |64|1 |Bi|FE80::/64| equal  | not-sent   ||      |
 |IPv6 DevIID     |64|1 |Bi|         | ignore | DevIID     ||      |
 |IPv6 AppPrefix  |64|1 |Bi|FE80::/64| equal  | not-sent   ||      |
 |IPv6 AppIID     |64|1 |Bi|::1      | equal  | not-sent   ||      |
 +================+==+==+==+=========+========+============++======+
 |UDP DevPort     |16|1 |Bi|123      | equal  | not-sent   ||      |
 |UDP AppPort     |16|1 |Bi|124      | equal  | not-sent   ||      |
 |UDP Length      |16|1 |Bi|         | ignore | compute-*  ||      |
 |UDP checksum    |16|1 |Bi|         | ignore | compute-*  ||      |
 +================+==+==+==+=========+========+============++======+
 +================+==+==+==+=========+========+============++======+]]></artwork>
      </figure>

      <figure anchor="Fig-fields1">
        <name>Context Rules - Rule 2</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Rule 2
 +----------------+--+--+--+---------+--------+------------++------+
 | Field       FID      |FL|FP|DI| Value    TV   | Match   MO   | Action     CDA    || Sent |
 |                |  |  |  |         | Opera.        | Action            ||[bits]|
 +----------------+--+--+--+---------+--------+------------++------+
 |IPv6 Version    |4 |1 |Bi|6        | ignore | not-sent   ||      |
 |IPv6 DiffServ Diffserv   |8 |1 |Bi|0        | equal  | not-sent   ||      |
 |IPv6 Flow Label |20|1 |Bi|0        | equal  | not-sent   ||      |
 |IPv6 Length     |16|1 |Bi|         | ignore | compute-*  ||      |
 |IPv6 Next Header|8 |1 |Bi|17       | equal  | not-sent   ||      |
 |IPv6 Hop Limit  |8 |1 |Bi|255      | ignore | not-sent   ||      |
 |IPv6 DevPrefix  |64|1 |Bi|[alpha/64, match- |mapping-sent||   1  |
 |                |  |  |  |fe80::/64] mapping|            ||      |
 |IPv6 DevIID     |64|1 |Bi|         | ignore | DevIID     ||      |
 |IPv6 AppPrefix  |64|1 |Bi|[beta/64,| match- |mapping-sent||   2  |
 |                |  |  |  |alpha/64,| mapping|            ||      |
 |                |  |  |  |fe80::64]|        |            ||      |
 |IPv6 AppIID     |64|1 |Bi|::1000   | equal  | not-sent   ||      |
 +================+==+==+==+=========+========+============++======+
 |UDP DevPort     |16|1 |Bi|5683     | equal  | not-sent   ||      |
 |UDP AppPort     |16|1 |Bi|5683     | equal  | not-sent   ||      |
 |UDP Length      |16|1 |Bi|         | ignore | compute-*  ||      |
 |UDP checksum    |16|1 |Bi|         | ignore | compute-*  ||      |
 +================+==+==+==+=========+========+============++======+
 +================+==+==+==+=========+========+============++======+]]></artwork>
      </figure>

      <figure anchor="Fig-fields2">
        <name>Context Rules - Rule 3</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Rule 3
 +----------------+--+--+--+---------+--------+------------++------+
 | Field       FID      |FL|FP|DI| Value    TV   | Match   MO   | Action     CDA    || Sent |
 |                |  |  |  |         | Opera.        | Action            ||[bits]|
 +----------------+--+--+--+---------+--------+------------++------+
 |IPv6 Version    |4 |1 |Bi|6        | ignore | not-sent   ||      |
 |IPv6 DiffServ Diffserv   |8 |1 |Bi|0        | equal  | not-sent   ||      |
 |IPv6 Flow Label |20|1 |Bi|0        | equal  | not-sent   ||      |
 |IPv6 Length     |16|1 |Bi|         | ignore | compute-*  ||      |
 |IPv6 Next Header|8 |1 |Bi|17       | equal  | not-sent   ||      |
 |IPv6 Hop Limit  |8 |1 |Up|255      | ignore | not-sent   ||      |
 |IPv6 Hop Limit  |8 |1 |Dw|         | ignore | value-sent ||   8  |
 |IPv6 DevPrefix  |64|1 |Bi|alpha/64 | equal  | not-sent   ||      |
 |IPv6 DevIID     |64|1 |Bi|         | ignore | DevIID     ||      |
 |IPv6 AppPrefix  |64|1 |Bi|gamma/64 | equal  | not-sent   ||      |
 |IPv6 AppIID     |64|1 |Bi|::1000   | equal  | not-sent   ||      |
 +================+==+==+==+=========+========+============++======+
 |UDP DevPort     |16|1 |Bi|8720     | MSB(12)| LSB        ||   4  |
 |UDP AppPort     |16|1 |Bi|8720     | MSB(12)| LSB        ||   4  |
 |UDP Length      |16|1 |Bi|         | ignore | compute-*  ||      |
 |UDP checksum    |16|1 |Bi|         | ignore | compute-*  ||      |
 +================+==+==+==+=========+========+============++======+

]]></artwork></figure>

<t><xref target="Fig-fields"/> describes a
 +================+==+==+==+=========+========+============++======+]]></artwork>
      </figure>
      <t>Figures <xref target="Fig-fields" format="counter"/> to <xref target="Fig-fields2" format="counter"/> describe an example of a Rule set.</t>
      <t>In this example, 0 was chosen as the special Rule ID RuleID that tags packets that cannot be compressed with any compression Rule.</t>
      <t>All the fields described in Rules 1-3 are present in the IPv6 and UDP headers. The DevIID-DID DevIID value is found in inferred from the L2 header.</t>
      <t>Rules 2-3 use global addresses. The way the Dev learns the prefix is not in the scope of the document.</t>
      <t>Rule 3 compresses each port number to 4 bits.</t>
    </section>
    <section anchor="FragExamples" title="Fragmentation Examples"> numbered="true" toc="default">
      <name>Fragmentation Examples</name>
      <t>This section provides examples for the various fragment reliability modes specified in this document.
In the drawings, Bitmaps are shown in their uncompressed form.</t>
      <t><xref target="Fig-Example-Unreliable"/> target="Fig-Example-Unreliable" format="default"/> illustrates the transmission in No-ACK mode of a SCHC Packet that needs 11 SCHC Fragments. FCN is 1 bit wide.</t>
      <figure title="No-ACK mode, anchor="Fig-Example-Unreliable">
        <name>No-ACK Mode, 11 SCHC Fragments" anchor="Fig-Example-Unreliable"><artwork><![CDATA[
        Sender               Fragments</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        Sender               Receiver
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-------FCN=0-------->|
          |-----FCN=1 + RCS --->| Integrity check: success
        (End)      
]]></artwork></figure>
        (End)]]></artwork>
      </figure>
      <t>In the following examples, N (the size of the FCN field) is 3 bits. The All-1 FCN value is therefore 7.</t>
      <t><xref target="Fig-Example-Win-NoLoss-NACK"/> target="Fig-Example-Win-NoLoss-NACK" format="default"/> illustrates the transmission in ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, WINDOW_SIZE=7 and no lost SCHC Fragment.</t>
      <figure title="ACK-on-Error mode, anchor="Fig-Example-Win-NoLoss-NACK">
        <name>ACK-on-Error Mode, 11 tiles, one tile Tiles, One Tile per SCHC Fragment, no lost No Lost SCHC Fragment." anchor="Fig-Example-Win-NoLoss-NACK"><artwork><![CDATA[
        Sender               Fragment</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        Sender               Receiver
          |-----W=0, FCN=6----->|
          |-----W=0, FCN=5----->|
          |-----W=0, FCN=4----->|
          |-----W=0, FCN=3----->|
          |-----W=0, FCN=2----->|
          |-----W=0, FCN=1----->|
          |-----W=0, FCN=0----->|
      (no ACK)
          |-----W=1, FCN=6----->|
          |-----W=1, FCN=5----->|
          |-----W=1, FCN=4----->|
          |--W=1, FCN=7 + RCS-->| Integrity check: success
          |<-- ACK, W=1, C=1 ---| C=1
        (End)
]]></artwork></figure>
        (End)]]></artwork>
      </figure>
      <t><xref target="Fig-Example-Rel-Window-NACK-Loss"/> target="Fig-Example-Rel-Window-NACK-Loss" format="default"/> illustrates the transmission in ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, WINDOW_SIZE=7 WINDOW_SIZE=7, and three lost SCHC Fragments.</t>
      <figure title="ACK-on-Error mode, anchor="Fig-Example-Rel-Window-NACK-Loss">
        <name>ACK-on-Error Mode, 11 tiles, one tile Tiles, One Tile per SCHC Fragment, lost Lost SCHC Fragments." anchor="Fig-Example-Rel-Window-NACK-Loss"><artwork><![CDATA[
         Fragments</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        Sender                           Receiver
          |-----W=0, FCN=6----->|
          |-----W=0, FCN=5----->|
          |-----W=0, FCN=4--X-->|
          |-----W=0, FCN=3----->|
          |-----W=0, FCN=2--X-->|
          |-----W=0, FCN=1----->|
          |-----W=0, FCN=0----->|        6543210
          |<-- ACK, W=0, C=0 ---| Bitmap:1101011
          |-----W=0, FCN=4----->|
          |-----W=0, FCN=2----->|
      (no ACK)
          |-----W=1, FCN=6----->|
          |-----W=1, FCN=5----->|
          |-----W=1, FCN=4--X-->|
          |- W=1, FCN=7 + RCS ->| Integrity check: failure
          |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001
          |-----W=1, FCN=4----->| Integrity check: success
          |<-- ACK, W=1, C=1 ---| C=1
        (End)
]]></artwork></figure>
        (End)]]></artwork>
      </figure>
      <t><xref target="Figure-Example-ACK-on-Error-VarMTU"/> target="Figure-Example-ACK-on-Error-VarMTU" format="default"/> shows an example of a transmission in ACK-on-Error mode of a SCHC Packet fragmented in
73 tiles, with N=5, WINDOW_SIZE=28, M=2 M=2, and 3 three lost SCHC Fragments.</t>
      <figure title="ACK-on-Error mode, variable MTU." anchor="Figure-Example-ACK-on-Error-VarMTU"><artwork><![CDATA[ anchor="Figure-Example-ACK-on-Error-VarMTU">
        <name>ACK-on-Error Mode, Variable MTU</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   Sender               Receiver
    |-----W=0, FCN=27----->| 4 tiles sent
    |-----W=0, FCN=23----->| 4 tiles sent
    |-----W=0, FCN=19----->| 4 tiles sent
    |-----W=0, FCN=15--X-->| 4 tiles sent (not received)
    |-----W=0, FCN=11----->| 4 tiles sent
    |-----W=0, FCN=7 ----->| 4 tiles sent
    |-----W=0, FCN=3 ----->| 4 tiles sent
    |-----W=1, FCN=27----->| 4 tiles sent
    |-----W=1, FCN=23----->| 4 tiles sent
    |-----W=1, FCN=19----->| 4 tiles sent
    |-----W=1, FCN=15----->| 4 tiles sent
    |-----W=1, FCN=11----->| 4 tiles sent
    |-----W=1, FCN=7 ----->| 4 tiles sent
    |-----W=1, FCN=3 --X-->| 4 tiles sent (not received)
    |-----W=2, FCN=27----->| 4 tiles sent
    |-----W=2, FCN=23----->| 4 tiles sent
^   |-----W=2, FCN=19----->| 1 tile sent
|   |-----W=2, FCN=18----->| 1 tile sent
|   |-----W=2, FCN=17----->| 1 tile sent
    |-----W=2, FCN=16----->| 1 tile sent
s   |-----W=2, FCN=15----->| 1 tile sent
m   |-----W=2, FCN=14----->| 1 tile sent
a   |-----W=2, FCN=13--X-->| 1 tile sent (not received)
l   |-----W=2, FCN=12----->| 1 tile sent
l   |---W=2, FCN=31 + RCS->| Integrity check: failure
e   |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111
r   |-----W=0, FCN=15----->| 1 tile sent
    |-----W=0, FCN=14----->| 1 tile sent
L   |-----W=0, FCN=13----->| 1 tile sent
2   |-----W=0, FCN=12----->| 1 tile sent
    |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000
M   |-----W=1, FCN=3 ----->| 1 tile sent
T   |-----W=1, FCN=2 ----->| 1 tile sent
U   |-----W=1, FCN=1 ----->| 1 tile sent
    |-----W=1, FCN=0 ----->| 1 tile sent
|   |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001
|   |-----W=2, FCN=13----->| Integrity check: success
V   |<--- ACK, W=2, C=1 ---| C=1
     (End)
]]></artwork></figure>
  (End)]]></artwork>
      </figure>
      <t>In this example, the L2 MTU becomes reduced just before sending the “W=2, FCN=19” "W=2, FCN=19" fragment, leaving space for only 1 one tile in each forthcoming SCHC Fragment.
Before retransmissions, the 73 tiles are carried by a total of 25 SCHC Fragments, the last 9 nine being of smaller size.</t>
      <t>Note: other sequences of events (e.g., regarding when ACKs are sent by the Receiver) are also allowed by this specification. Profiles may restrict this flexibility.</t>
      <t><xref target="Fig-Example-Rel-Window-ACK-NoLoss"/> target="Fig-Example-Rel-Window-ACK-NoLoss" format="default"/> illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with N=3, WINDOW_SIZE=7 WINDOW_SIZE=7, and no loss.</t>
      <figure title="ACK-Always mode, anchor="Fig-Example-Rel-Window-ACK-NoLoss">
        <name>ACK-Always Mode, 11 tiles, one tile Tiles, One Tile per SCHC Fragment, no loss." anchor="Fig-Example-Rel-Window-ACK-NoLoss"><artwork><![CDATA[
        Sender               No Loss</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        Sender               Receiver
          |-----W=0, FCN=6----->|
          |-----W=0, FCN=5----->|
          |-----W=0, FCN=4----->|
          |-----W=0, FCN=3----->|
          |-----W=0, FCN=2----->|
          |-----W=0, FCN=1----->|
          |-----W=0, FCN=0----->|
          |<-- ACK, W=0, C=0 ---| Bitmap:1111111
          |-----W=1, FCN=6----->|
          |-----W=1, FCN=5----->|
          |-----W=1, FCN=4----->|
          |--W=1, FCN=7 + RCS-->| Integrity check: success
          |<-- ACK, W=1, C=1 ---| C=1
        (End)
]]></artwork></figure>
        (End)]]></artwork>
      </figure>
      <t><xref target="Fig-Example-Rel-Window-ACK-Loss"/> target="Fig-Example-Rel-Window-ACK-Loss" format="default"/> illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7 and three lost SCHC Fragments.</t>
      <figure title="ACK-Always mode, anchor="Fig-Example-Rel-Window-ACK-Loss">
        <name>ACK-Always Mode, 11 tiles, one tile Tiles, One Tile per SCHC Fragment, three lost Three Lost SCHC Fragments." anchor="Fig-Example-Rel-Window-ACK-Loss"><artwork><![CDATA[
        Sender               Fragments</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        Sender               Receiver
          |-----W=0, FCN=6----->|
          |-----W=0, FCN=5----->|
          |-----W=0, FCN=4--X-->|
          |-----W=0, FCN=3----->|
          |-----W=0, FCN=2--X-->|
          |-----W=0, FCN=1----->|
          |-----W=0, FCN=0----->|        6543210
          |<-- ACK, W=0, C=0 ---| Bitmap:1101011
          |-----W=0, FCN=4----->|
          |-----W=0, FCN=2----->|
          |<-- ACK, W=0, C=0 ---| Bitmap:1111111
          |-----W=1, FCN=6----->|
          |-----W=1, FCN=5----->|
          |-----W=1, FCN=4--X-->|
          |--W=1, FCN=7 + RCS-->| Integrity check: failure
          |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001
          |-----W=1, FCN=4----->| Integrity check: success
          |<-- ACK, W=1, C=1 ---| C=1
        (End)
]]></artwork></figure>
        (End)]]></artwork>
      </figure>
      <t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-A"/> target="Fig-Example-Rel-Window-ACK-Loss-Last-A" format="default"/> illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 6 six tiles,
with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments Fragments, and only one retry needed to recover each lost SCHC Fragment.</t>
      <figure title="ACK-Always mode, 6 tiles,
one tile anchor="Fig-Example-Rel-Window-ACK-Loss-Last-A">
        <name>ACK-Always Mode, Six Tiles, One Tile per SCHC Fragment, three lost Three Lost SCHC Fragments." anchor="Fig-Example-Rel-Window-ACK-Loss-Last-A"><artwork><![CDATA[ Fragments</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
          Sender                Receiver
             |-----W=0, FCN=6----->|
             |-----W=0, FCN=5----->|
             |-----W=0, FCN=4--X-->|
             |-----W=0, FCN=3--X-->|
             |-----W=0, FCN=2--X-->|
             |--W=0, FCN=7 + RCS-->| Integrity check: failure
             |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
             |-----W=0, FCN=4----->| Integrity check: failure
             |-----W=0, FCN=3----->| Integrity check: failure
             |-----W=0, FCN=2----->| Integrity check: success
             |<-- ACK, W=0, C=1 ---| C=1
           (End)
]]></artwork></figure>
           (End)]]></artwork>
      </figure>
      <t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-B"/> target="Fig-Example-Rel-Window-ACK-Loss-Last-B" format="default"/> illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 6 six tiles,
with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK lost.</t>
      <figure title="ACK-Always mode, 6 tiles,
one tile anchor="Fig-Example-Rel-Window-ACK-Loss-Last-B">
        <name>ACK-Always Mode, Six Tiles, One Tile per SCHC Fragment, SCHC ACK loss." anchor="Fig-Example-Rel-Window-ACK-Loss-Last-B"><artwork><![CDATA[ Loss</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
          Sender                Receiver
             |-----W=0, FCN=6----->|
             |-----W=0, FCN=5----->|
             |-----W=0, FCN=4--X-->|
             |-----W=0, FCN=3--X-->|
             |-----W=0, FCN=2--X-->|
             |--W=0, FCN=7 + RCS-->| Integrity check: failure
             |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
             |-----W=0, FCN=4----->| Integrity check: failure
             |-----W=0, FCN=3----->| Integrity check: failure
             |-----W=0, FCN=2----->| Integrity check: success
             |<-X-ACK, W=0, C=1 ---| C=1
    timeout  |                     |
             |--- W=0, ACK REQ --->| ACK REQ
             |<-- ACK, W=0, C=1 ---| C=1
           (End)
]]></artwork></figure>
           (End)]]></artwork>
      </figure>
      <t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-C"/> target="Fig-Example-Rel-Window-ACK-Loss-Last-C" format="default"/> illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 6 six tiles,
with N=3, WINDOW_SIZE=7, with three lost SCHC Fragments, and one retransmitted SCHC Fragment lost again.</t>
      <figure title="ACK-Always mode, 6 tiles,
retransmitted anchor="Fig-Example-Rel-Window-ACK-Loss-Last-C">
        <name>ACK-Always Mode, Six Tiles, Retransmitted SCHC Fragment lost again." anchor="Fig-Example-Rel-Window-ACK-Loss-Last-C"><artwork><![CDATA[ Lost Again</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
           Sender                Receiver
             |-----W=0, FCN=6----->|
             |-----W=0, FCN=5----->|
             |-----W=0, FCN=4--X-->|
             |-----W=0, FCN=3--X-->|
             |-----W=0, FCN=2--X-->|
             |--W=0, FCN=7 + RCS-->| Integrity check: failure
             |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
             |-----W=0, FCN=4----->| Integrity check: failure
             |-----W=0, FCN=3----->| Integrity check: failure
             |-----W=0, FCN=2--X-->|
      timeout|                     |
             |--- W=0, ACK REQ --->| ACK REQ
             |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101
             |-----W=0, FCN=2----->| Integrity check: success
             |<-- ACK, W=0, C=1 ---| C=1
           (End)
]]></artwork></figure>
           (End)]]></artwork>
      </figure>
      <t><xref target="Fig-Example-MaxWindFCN"/> target="Fig-Example-MaxWindFCN" format="default"/> illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 28 tiles,
with one tile per SCHC Fragment, N=5, WINDOW_SIZE=24 WINDOW_SIZE=24, and two lost SCHC Fragments.</t>
      <figure title="ACK-Always mode, anchor="Fig-Example-MaxWindFCN">
        <name>ACK-Always Mode, 28 tiles,
one tile Tiles, One Tile per SCHC Fragment, lost Lost SCHC Fragments." anchor="Fig-Example-MaxWindFCN"><artwork><![CDATA[ Fragments</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
      Sender               Receiver
        |-----W=0, FCN=23----->|
        |-----W=0, FCN=22----->|
        |-----W=0, FCN=21--X-->|
        |-----W=0, FCN=20----->|
        |-----W=0, FCN=19----->|
        |-----W=0, FCN=18----->|
        |-----W=0, FCN=17----->|
        |-----W=0, FCN=16----->|
        |-----W=0, FCN=15----->|
        |-----W=0, FCN=14----->|
        |-----W=0, FCN=13----->|
        |-----W=0, FCN=12----->|
        |-----W=0, FCN=11----->|
        |-----W=0, FCN=10--X-->|
        |-----W=0, FCN=9 ----->|
        |-----W=0, FCN=8 ----->|
        |-----W=0, FCN=7 ----->|
        |-----W=0, FCN=6 ----->|
        |-----W=0, FCN=5 ----->|
        |-----W=0, FCN=4 ----->|
        |-----W=0, FCN=3 ----->|
        |-----W=0, FCN=2 ----->|
        |-----W=0, FCN=1 ----->|
        |-----W=0, FCN=0 ----->|
        |                      |
        |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111
        |-----W=0, FCN=21----->|
        |-----W=0, FCN=10----->|
        |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111
        |-----W=1, FCN=23----->|
        |-----W=1, FCN=22----->|
        |-----W=1, FCN=21----->|
        |--W=1, FCN=31 + RCS-->| Integrity check: success
        |<--- ACK, W=1, C=1 ---| C=1
      (End)
]]></artwork></figure>
      (End)]]></artwork>
      </figure>
    </section>
    <section anchor="FSM" title="Fragmentation numbered="true" toc="default">
      <name>Fragmentation State Machines"> Machines</name>
      <t>The fragmentation state machines of the sender and the receiver, one for each of the different reliability modes, are described in the following figures:</t>
      <figure title="Sender anchor="Fig-NoACKModeSnd">
        <name>Sender State Machine for the No-ACK Mode" anchor="Fig-NoACKModeSnd"><artwork><![CDATA[ Mode</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
             +===========+
+------------+  Init     |
|  FCN=0     +===========+
|  No Window
|  No Bitmap
|                   +-------+
|          +========+==+    | More Fragments
|          |           | <--+ ~~~~~~~~~~~~~~~~~~~~
+--------> |   Send    |      send Fragment (FCN=0)
           +===+=======+
               |  last fragment
               |  ~~~~~~~~~~~~
               |  FCN = 1
               v  send fragment+RCS
           +============+
           |    END     |
           +============+
]]></artwork></figure>
           +============+]]></artwork>
      </figure>
      <figure title="Receiver anchor="Fig-NoACKModeRcv">
        <name>Receiver State Machine for the No-ACK Mode" anchor="Fig-NoACKModeRcv"><artwork><![CDATA[ Mode</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                      +------+ Not All-1
           +==========+=+    | ~~~~~~~~~~~~~~~~~~~
           |            + <--+ set Inactivity Timer
           |  RCV Frag  +-------+
           +=+===+======+       |All-1 &
   All-1 &   |   |              |RCS correct
 RCS wrong   |   |Inactivity    |
             |   |Timer Exp.    |
             v   |              |
  +==========++  |              v
  |   Error   |<-+     +========+==+
  +===========+        |    END    |
                       +===========+

]]></artwork></figure>
                       +===========+]]></artwork>
      </figure>
      <figure title="Sender anchor="Fig-ACKAlwaysSnd">
        <name>Sender State Machine for the ACK-Always Mode" anchor="Fig-ACKAlwaysSnd"><artwork><![CDATA[ Mode</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
              +=======+
              | INIT  |       FCN!=0 & more frags
              |       |       ~~~~~~~~~~~~~~~~~~~~~~
              +======++  +--+ send Window + frag(FCN)
                 W=0 |   |  | FCN-
  Clear lcl_bm       |   |  v set lcl_bm
       FCN=max value |  ++==+========+
                     +> |            |
+---------------------> |    SEND    |
|                       +==+===+=====+
|      FCN==0 & more frags |   | last frag
|    ~~~~~~~~~~~~~~~~~~~~~ |   | ~~~~~~~~~~~~~~~
|               set lcl_bm |   | set lcl_bm
|   send wnd + frag(all-0) |   | send wnd+frag(all-1)+RCS
|       set Retrans_Timer  |   | set Retrans_Timer
|                          |   |
|Recv_wnd == wnd &         |   |
|lcl_bm==recv_bm &         |   |  +----------------------+
|more frag                 |   |  | lcl_bm!=rcv-bm       |
|~~~~~~~~~~~~~~~~~~~~~~    |   |  | ~~~~~~~~~            |
|Stop Retrans_Timer        |   |  | Attempt++            v
|clear lcl_bm              v   v  |                +=====+=+
|window=next_window   +====+===+==+===+            |Resend |
+---------------------+               |            |Missing|
                 +----+     Wait      |            |Frag   |
not expected wnd |    |    Bitmap     |            +=======+
~~~~~~~~~~~~~~~~ +--->+               ++Retrans_Timer Exp  |
    discard frag      +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ |
                         | |   | ^  ^  |reSend(empty)All-* |
                         | |   | |  |  |Set Retrans_Timer  |
                         | |   | |  +--+Attempt++          |
  C_bit==1 &             | |   | +-------------------------+
Recv_window==window &    | |   |   all missing frags sent
             no more frag| |   |   ~~~~~~~~~~~~~~~~~~~~~~
 ~~~~~~~~~~~~~~~~~~~~~~~~| |  |     |   Set Retrans_Timer                
       Stop Retrans_Timer| |   |
 +=============+         | |   |
 |     END     +<--------+ |   |
 +=============+           |   | Attempt > MAX_ACK_REQUESTS
            All-1 Window & |   | ~~~~~~~~~~~~~~~~~~
               C_bit ==0 & |   v Send Abort
          lcl_bm==recv_bm  | +=+===========+
            
              ~~~~~~~~~~~~ +>|    ERROR    |
                Send Abort   +=============+

]]></artwork></figure>   +=============+]]></artwork>
      </figure>
      <figure title="Receiver anchor="Fig-ACKAlwaysRcv">
        <name>Receiver State Machine for the ACK-Always Mode" anchor="Fig-ACKAlwaysRcv"><artwork><![CDATA[ Mode</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 Not All- & w=expected +---+   +---+w = Not expected
 ~~~~~~~~~~~~~~~~~~~~~ |   |   |   |~~~~~~~~~~~~~~~~
 Set lcl_bm(FCN)       |   v   v   |discard
                      ++===+===+===+=+
+---------------------+         Rcv          +--->* ABORT
|  +------------------+     Window         |
|  |                                  +=====+==+=====+
|  |             All-0 & w=expect |  ^  ^ w =next & not-All
|  |     ~~~~~~~~~~~~~~~~~~ |  |~~~~~~~~~~~~~~~~~~~~~
|  |    set lcl_bm(FCN)     |  |expected = next window
|  |      send lcl_bm       |  |Clear lcl_bm
|  |                        |  |
|  | w=expected & not-All   |  |
|  | ~~~~~~~~~~~~~~~~~~     |  |
|  |     set lcl_bm(FCN)+-+ |  | +--+ w=next & All-0
|  |     if lcl_bm full | | |  | |  | ~~~~~~~~~~~~~~~
|  |     send lcl_bm    | | |  | |  | expected = nxt wnd
|  |                    v | v  | |  | Clear lcl_bm
|  |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN)
|  |  ~~~~~~~~~~~  +->+    Wait   +<+ send lcl_bm
|  |    discard    +--|    Next   |
|  | All-0  +---------+  Window   +--->* ABORT
|  | ~~~~~  +-------->+========+=++
|  | snd lcl_bm  All-1 & w=next| |  All-1 & w=nxt
|  |                & RCS wrong| |  & RCS right
|  |          ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~
|  |            set lcl_bm(FCN)| |set lcl_bm(FCN)
|  |                send lcl_bm| |send lcl_bm
|  |                           | +----------------------+
|  |All-1 & w=expected         |                        |
|  |& RCS wrong                v   +---+ w=expected &   |
|  |~~~~~~~~~~~~~~~~~~~~  +====+=====+ | RCS wrong      |
|  |set lcl_bm(FCN)       |          +<+ ~~~~~~~~~~~~~~ |
|  |send lcl_bm           | Wait End |   set lcl_bm(FCN)|
|  +--------------------->+          +--->* ABORT       |
|                         +===+====+=+-+ All-1&RCS wrong|
|                             |    ^   | ~~~~~~~~~~~~~~~|
|      w=expected & RCS right |    +---+   send lcl_bm  |
|      ~~~~~~~~~~~~~~~~~~~~~~ |                         |
|       set lcl_bm(FCN)       | +-+ Not All-1           |
|        send lcl_bm          | | | ~~~~~~~~~           |
|                             | | |  discard            |
|All-1&w=expected & RCS right | | |                     |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1         |
|set lcl_bm(FCN)            +=+=+=+=+==+ |~~~~~~~~~     |
|send lcl_bm                |          +<+Send lcl_bm   |
+-------------------------->+    END   |                |
                            +==========+<---------------+

       --->* ABORT

       In any state
          on receiving a SCHC ACK REQ
             Send a SCHC ACK for the current window
                            
]]></artwork></figure> window]]></artwork>
      </figure>
      <figure title="Sender anchor="Fig-ACKonerrorSnd">
        <name>Sender State Machine for the ACK-on-Error Mode" anchor="Fig-ACKonerrorSnd"><artwork><![CDATA[ Mode</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                  +=======+
                  |       |
                  | INIT  |
                  |       |       FCN!=0 & more frags
                  +======++       ~~~~~~~~~~~~~~~~~~~~~~
     Frag RuleID trigger |   +--+ Send cur_W + frag(FCN);
     ~~~~~~~~~~~~~~~~~~~ |   |  | FCN--;
  cur_W=0; FCN=max_value;|   |  | set [cur_W, cur_Bmp]
    clear [cur_W, Bmp_n];|   |  v
          clear rcv_Bmp  |  ++==+==========+       **BACK_TO_SEND
                         +->+              |   cur_W==rcv_W &
      **BACK_TO_SEND        |     SEND     |   [cur_W,Bmp_n]==rcv_Bmp
+-------------------------->+              |   & more frags
|  +----------------------->+              |   ~~~~~~~~~~~~
|  |                        ++===+=========+                        ++==+==========+   cur_W++;
|  |      FCN==0 & more frags|  |last frag     clear [cur_W, Bmp_n]
|  |  ~~~~~~~~~~~~~~~~~~~~~~~|  |~~~~~~~~~
|  |        set cur_Bmp;     |  |set [cur_W, Bmp_n];
|  |send cur_W + frag(All-0);|  |send cur_W + frag(All-1)+RCS;
|  |        set Retrans_Timer|  |set Retrans_Timer
|  |                         |  | +-----------------------------------+ +---------------------------------+
|  |                         |  | |cur_W ==                         |
|  |Retrans_Timer expires &  |  | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| |   rcv_W & [cur_W,Bmp_n]!=rcv_Bmp|
|  |more Frags               |  | |  ~~~~~~~~~~~~~~~~~~~            |
|  |~~~~~~~~~~~~~~~~~~~~     |  | |  Attempts++; W=cur_W            |
|  |stop Retrans_Timer;      |  | | +--------+           rcv_W==Wn &|
|  |[cur_W,Bmp_n]==cur_Bmp;  v  v | |        v   [Wn,Bmp_n]!=rcv_Bmp|
|  |cur_W++            +=====+===+=+=+==+            +=====+==+=+=+==+   +=+=========+ ~~~~~~~~~~~|
|  +-------------------+               |   | Resend    | Attempts++;|
+----------------------+   Wait x ACK  |   | Missing   |       W=Wn |
+--------------------->+               |   | Frags(W)  +<-------------+  +<-----------+
|         rcv_W==Wn &+-+               |   +======+====+
| [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ ++=+===+===+==+=+          |
|      ~~~~~~~~~~~~~~|  ^ |   |   |  ^            |
|        send (cur_W,+--+ |   |   |  +-------------+  +------------+
|        ALL-0-empty)     |   |   |     all missing frag sent(W)
|                         |   |   |     ~~~~~~~~~~~~~~~~~
|  Retrans_Timer expires &|   |   |     set Retrans_Timer
|            No more Frags|   |   |
|           ~~~~~~~~~~~~~~|   |   |
|      stop Retrans_Timer;|   |   |
|(re)send frag(All-1)+RCS |   |   |
+-------------------------+   |   |
                 cur_W==rcv_W&|   |
       [cur_W,Bmp_n]==rcv_Bmp&|   | Attempts > MAX_ACK_REQUESTS
  No more Frags & RCS flag==OK|   | ~~~~~~~~~~
            ~~~~~~~~~~~~~~~~~~|   | send Abort
 +=========+stop Retrans_Timer|   |  +===========+
 |   END   +<-----------------+   +->+   ERROR   |
 +=========+                         +===========+
]]></artwork></figure>                         +===========+]]></artwork>
      </figure>
      <t>This is an example only. It is not normative.
The specification in <xref target="ACK-on-Error-sender"/> target="ACK-on-Error-sender" format="default"/> allows for sequences of operations different from the one shown here.</t>

<figure><artwork><![CDATA[
      <artwork name="" type="" align="left" alt=""><![CDATA[
                 +=======+        New frag RuleID received
                 |       |        ~~~~~~~~~~~~~
                 | INIT  +-------+cur_W=0;clear([cur_W,Bmp_n]);
                 +=======+       |sync=0
                                 |
    Not All* & rcv_W==cur_W+---+ | +---+ +--+
      ~~~~~~~~~~~~~~~~~~~~ |   | | | (E)
      set[cur_W,Bmp_n(FCN)]|   v v v  |
                          ++===+=+=+===+=+
                          ++===+=+=+==+=+
   +----------------------+             +--+ All-0&Full[cur_W,Bmp_n]
   |           ABORT *<---+  Rcv Window |  | ~~~~~~~~~~
   |  +-------------------+             +<-+ cur_W++;set Inact_timer;
   |  |                +->+=+=+=+=+=+====+                +->+=+=+=+=+=+===+    clear [cur_W,Bmp_n]
   |  | All-0 empty(Wn)|    | | | ^ ^
   |  | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0;
   |  | sendACK([Wn,Bmp_n])   | | | |& Full([cur_W,Bmp_n])
   |  |                       | | | |& All* || last_miss_frag
   |  |                       | | | |~~~~~~~~~~~~~~~~~~~~~~
   |  |    All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]);
   |  |              & sync==0| | | |cur_W++; clear([cur_W,Bmp_n])
   |  |&no_full([cur_W,Bmp_n])| |(E)|
   |  |      ~~~~~~~~~~~~~~~~ | | | |              +========+
   |  | sendACK([cur_W,Bmp_n])| | | |              | Error/ |
   |  |                       | | | |   +----+     | Abort  |
   |  |                       v v | |   |    |     +===+====+
   |  |                   +===+=+=+=+===+=+ (D)        ^
   |  |                +--+    Wait x     |  |         |
   |  | All-0 empty(Wn)+->| Missing Frags |<-+         |
   |  | ~~~~~~~~~~~~~~    +=============+=+            |
   |  | sendACK([Wn,Bmp_n])             +--------------+
   |  |                                       *ABORT
   v  v
  (A)(B)
                                   (D) All* || last_miss_frag
    (C) All* & sync>0                  & rcv_W!=cur_W & sync>0
        ~~~~~~~~~~~~                   & Full([rcv_W,Bmp_n])
        Wn=oldest[not full(W)];        ~~~~~~~~~~~~~~~~~~~~
        sendACK([Wn,Bmp_n])            Wn=oldest[not full(W)];
                                       sendACK([Wn,Bmp_n]);sync--

                             ABORT-->* Uplink Only &
                                       Inact_Timer expires
    (E) Not All* & rcv_W!=cur_W        || Attempts > MAX_ACK_REQUESTS
        ~~~~~~~~~~~~~~~~~~~~           ~~~~~~~~~~~~~~~~~~~~~
        sync++; cur_W=rcv_W;           send Abort
        set[cur_W,Bmp_n(FCN)]

]]></artwork></figure>
        set[cur_W,Bmp_n(FCN)]]]></artwork>
      <figure title="Receiver anchor="Fig-ACKonerrorRcv">
        <name>Receiver State Machine for the ACK-on-Error Mode" anchor="Fig-ACKonerrorRcv"><artwork><![CDATA[ Mode</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  (A)(B)
   |  |
   |  | All-1 & rcv_W==cur_W & RCS!=OK        All-0 empty(Wn)
   |  | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~     +-+  ~~~~~~~~~~
   |  | sendACK([cur_W,Bmp_n],C=0)       | v  sendACK([Wn,Bmp_n])
   |  |                      +===========+=++
   |  +--------------------->+   Wait End   +-+
   |                         +=====+=+====+=+ | All-1
   |     rcv_W==cur_W & RCS==OK    | |    ^   | & rcv_W==cur_W
   |     ~~~~~~~~~~~~~~~~~~~~~~    | |    +---+ & RCS!=OK
   |  sendACK([cur_W,Bmp_n],C=1)   | |          ~~~~~~~~~~~~~~~~~~~
   |                               | | sendACK([cur_W,Bmp_n],C=0);
   |                               | |          Attempts++
   |All-1 & Full([cur_W,Bmp_n])    | |
   |& RCS==OK & sync==0            | +-->* ABORT
   |~~~~~~~~~~~~~~~~~~~            v
   |sendACK([cur_W,Bmp_n],C=1)   +=+=========+
   +---------------------------->+    END    |
                                 +===========+

]]></artwork></figure>
                                 +===========+]]></artwork>
      </figure>
    </section>
    <section anchor="SCHCParams" title="SCHC Parameters"> numbered="true" toc="default">
      <name>SCHC Parameters</name>
      <t>This section lists the information that needs to be provided in the LPWAN technology-specific documents.</t>

<t><list style="symbols">
  <t>Most
      <ul spacing="normal">
        <li>Most common uses cases, deployment scenarios</t>
  <t>Mapping scenarios.</li>
        <li>Mapping of the SCHC architectural elements onto the LPWAN architecture</t>
  <t>Assessment architecture.</li>
        <li>Assessment of LPWAN integrity checking</t>
  <t>Various checking.</li>
        <li>Various potential channel conditions for the technology and the corresponding recommended use of SCHC C/D and F/R</t>
</list></t> SCHC F/R.</li>
      </ul>
      <t>This section lists the parameters that need to be defined in the Profile.</t>

<t><list style="symbols">
  <t>Rule ID
      <ul spacing="normal">
        <li>RuleID numbering scheme, fixed-sized fixed-size or variable-sized Rule IDs, variable-size RuleIDs, number of Rules, the way the Rule ID RuleID is transmitted</t>
  <t>maximum transmitted.</li>
        <li>maximum packet size that should ever be reconstructed by SCHC Decompression decompression (MAX_PACKET_SIZE). See <xref target="SecConsiderations"/>.</t>
  <t>Padding: target="SecConsiderations" format="default"/>.</li>
        <li>Padding: size of the L2 Word (for most LPWAN technologies, this would be a byte; for some technologies, a bit)</t> bit).</li>
        <li>
          <t>Decision to use SCHC fragmentation mechanism or not. If yes, the document must describe:  <list style="symbols">
      <t>reliability  </t>
          <ul spacing="normal">
            <li>reliability mode(s) used, in which cases (e.g., based on link channel condition)</t>
      <t>Rule ID condition).</li>
            <li>RuleID values assigned to each mode in use</t>
      <t>presence use.</li>
            <li>presence and number of bits for DTag (T) for each Rule ID RuleID value, lifetime of DTag at the receiver</t>
      <t>support receiver.</li>
            <li>support for interleaved packet transmission, to what extent</t>
      <t>WINDOW_SIZE, extent.</li>
            <li>WINDOW_SIZE, for modes that use windows</t>
      <t>number windows.</li>
            <li>number of bits for W (M) for each Rule ID RuleID value, for modes that use windows</t>
      <t>number windows.</li>
            <li>number of bits for FCN (N) for each Rule ID value</t>
      <t>what RuleID value, meaning of the FCN values.</li>
            <li>what makes an All-0 SCHC Fragment and a SCHC ACK REQ distinguishable (see <xref target="NotLastFrag"/>).</t>
      <t>what target="NotLastFrag" format="default"/>).</li>
            <li>what makes an All-1 SCHC Fragment and a SCHC Sender-Abort distinguishable (see <xref target="LastFrag"/>).</t>
      <t>size target="LastFrag" format="default"/>).</li>
            <li>for RuleIDs that use ACK-on-Error mode: when the last tile of a SCHC Packet is to be sent in a Regular SCHC Fragment, alone in an All-1 SCHC Fragment or with any of these two methods.</li>
            <li>for RuleIDs that use ACK-on-Error mode: if the penultimate tile of a SCHC Packet is of the regular size only or if it can also be one L2 Word shorter.</li>
            <li>for RuleIDs that use ACK-on-Error mode: times at which the sender must listen for SCHC ACKs.</li>
            <li>size of RCS and algorithm for its computation, for each Rule ID, RuleID, if different from the default CRC32. Byte fill-up with zeroes or other mechanism, to be specified.</t>
      <t>Retransmission specified. Support for UDP checksum elision.</li>
            <li>Retransmission Timer duration for each Rule ID RuleID value, if applicable to the SCHC F/R mode</t>
      <t>Inactivity mode.</li>
            <li>Inactivity Timer duration for each Rule ID RuleID value, if applicable to the SCHC F/R mode</t>
      <t>MAX_ACK_REQUESTS mode.</li>
            <li>MAX_ACK_REQUESTS value for each Rule ID RuleID value, if applicable to the SCHC F/R mode</t>
    </list></t>
  <t>if mode.</li>
          </ul>
        </li>
        <li>if L2 Word is wider than a bit and SCHC fragmentation is used, value of the padding bits (0 or 1). This is needed
because the padding bits of the last fragment are included in the RCS computation.</t>
</list></t> 1).</li>
      </ul>
      <t>A Profile may define a delay to be added after each SCHC message transmission for compliance with local regulations or other constraints imposed by the applications.</t>

<t><list style="symbols">
  <t>In
      <ul spacing="normal">
        <li>In some LPWAN technologies, as part of energy-saving techniques,
downlink
Downlink transmission is only possible immediately after an uplink Uplink transmission.
In order to avoid potentially high delay in the downlink Downlink transmission of a fragmented SCHC Packet,
the SCHC Fragment receiver may perform an uplink Uplink transmission as soon as possible after reception of a SCHC
Fragment that is not the last one.
Such uplink Uplink transmission may be triggered by the L2 (e.g., an L2 ACK sent in response to a SCHC Fragment encapsulated
in a L2 PDU that requires an L2 ACK) or it may be triggered from an upper layer. See <xref target="AsymLinks"/>.</t> target="AsymLinks" format="default"/>.</li>
        <li>
          <t>the following parameters need to be addressed in documents other than this one but not necessarily in
the LPWAN technology-specific documents:  <list style="symbols">
      <t>The  </t>
          <ul spacing="normal">
            <li>The way the Contexts are provisioned</t>
      <t>The provisioned.</li>
            <li>The way the Rules are generated</t>
    </list></t>
</list></t> generated.</li>
          </ul>
        </li>
      </ul>
    </section>
    <section anchor="MultWinSizes" title="Supporting multiple window sizes numbered="true" toc="default">
      <name>Supporting Multiple Window Sizes for fragmentation"> Fragmentation</name>
      <t>For ACK-Always or ACK-on-Error, implementers may opt to support a single window size or multiple window sizes.  The latter, when feasible, may provide performance optimizations.  For example, a large window size WINDOW_SIZE should be used for packets that need to be split into a large number of tiles. However, when the number of tiles required to carry a packet is low, a smaller window size, and thus WINDOW_SIZE and, thus, a shorter Bitmap, may be sufficient to provide reception status on all tiles. If multiple window sizes are supported, the Rule ID RuleID signals the window size what WINDOW_SIZE is in use for a specific packet transmission.</t>
    </section>
    <section anchor="AsymLinks" title="ACK-Always numbered="true" toc="default">
      <name>ACK-Always and ACK-on-Error on quasi-bidirectional links"> Quasi-Bidirectional Links</name>
      <t>The ACK-Always and ACK-on-Error modes of SCHC F/R are bidirectional protocols:
they require a feedback path from the reassembler to the fragmenter.</t>
      <t>Some LPWAN technologies provide quasi-bidirectional connectivity,
whereby a downlink Downlink transmission from the Network Infrastructure can only take place
right after an uplink Uplink transmission by the Dev.</t>
      <t>When using SCHC F/R to send fragmented SCHC Packets downlink Downlink over these quasi-bidirectional links,
the following situation may arise: if an uplink Uplink SCHC ACK is lost,
the SCHC ACK REQ message by the sender could be stuck indefinitely in the downlink Downlink queue
at the Network Infrastructure, waiting for a transmission opportunity.</t>
      <t>There are many ways by which this deadlock can be avoided.
The Dev application might be sending recurring uplink Uplink messages such as keep-alive,
or the Dev application stack might be sending other recurring uplink Uplink messages as part of its operation.
However, these are out of the control of this generic SCHC specification.</t>
      <t>In order to cope with quasi-bidirectional links, a SCHC-over-foo specification may want to amend
the SCHC F/R specification to add a timer-based retransmission of the SCHC ACK.
Below is an example of the suggested behavior for ACK-Always mode.
Because it is an example, <xref target="RFC2119"/> target="RFC2119" format="default"/> language is deliberately not used here.</t>
      <t>For downlink Downlink transmission of a fragmented SCHC Packet in ACK-Always mode, the SCHC Fragment receiver may support timer-based SCHC ACK retransmission. In this mechanism, the SCHC Fragment receiver initializes and starts a timer (the UplinkACK Timer) after the transmission of a SCHC ACK, except when the SCHC ACK is sent in response to the last SCHC Fragment of a packet (All-1 fragment). In the latter case, the SCHC Fragment receiver does not start a timer after transmission of the SCHC ACK.</t>
      <t>If, after transmission of a SCHC ACK that is not an All-1 fragment, and before expiration of the corresponding UplinkACK timer, the SCHC Fragment receiver receives a SCHC Fragment that belongs to the current window (e.g., a missing SCHC Fragment from the current window) or to the next window, the UplinkACK timer for the SCHC ACK is stopped. However, if the UplinkACK timer expires, the SCHC ACK is resent and the UplinkACK timer is reinitialized and restarted.</t>
      <t>The default initial value for the UplinkACK Timer, as well as the maximum number of retries for a specific SCHC ACK, denoted MAX_ACK_REQUESTS, is to be defined in a Profile.
The initial value of the UplinkACK timer is expected to be greater than that of the Retransmission timer,
in order to make sure that a (buffered) SCHC Fragment to be retransmitted finds an opportunity for that transmission.
One exception to this recommendation is the special case of the All-1 SCHC Fragment transmission.</t>
      <t>When the SCHC Fragment sender transmits the All-1 SCHC Fragment,
it starts its Retransmission Timer with a large timeout value (e.g., several times that of the initial UplinkACK Timer).
If a SCHC ACK is received before expiration of this timer,
the SCHC Fragment sender retransmits any lost SCHC Fragments as reported by the SCHC ACK,
or if the SCHC ACK confirms successful reception of all SCHC Fragments of the last window,
the transmission of the fragmented SCHC Packet is considered complete.
If the timer expires, and no SCHC ACK has been received since the start of the timer,
the SCHC Fragment sender assumes that the All-1 SCHC Fragment has been successfully received
(and possibly, the last SCHC ACK has been lost: this mechanism assumes that the Retransmission Timer for the All-1 SCHC Fragment is long enough to allow several SCHC ACK retries if the All-1 SCHC Fragment has not been received by the SCHC Fragment receiver, and it also assumes that it is unlikely that several ACKs become all lost).</t>
</section>

    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to (in alphabetical order)
<contact fullname="Sergio Aguilar Romero"/>,
<contact fullname="David Black"/>,
<contact fullname="Carsten Bormann"/>,
<contact fullname="Deborah Brungard"/>,
<contact fullname="Brian Carpenter"/>,
<contact fullname="Philippe Clavier"/>,
<contact fullname="Alissa Cooper"/>,
<contact fullname="Roman Danyliw"/>,
<contact fullname="Daniel Ducuara Beltran"/>,
<contact fullname="Diego Dujovne"/>,
<contact fullname="Eduardo Ingles Sanchez"/>,
<contact fullname="Rahul Jadhav"/>,
<contact fullname="Benjamin Kaduk"/>,
<contact fullname="Arunprabhu Kandasamy"/>,
<contact fullname="Suresh Krishnan"/>,
<contact fullname="Mirja Kuehlewind"/>,
<contact fullname="Barry Leiba"/>,
<contact fullname="Sergio Lopez Bernal"/>,
<contact fullname="Antoni Markovski"/>,
<contact fullname="Alexey Melnikov"/>,
<contact fullname="Georgios Papadopoulos"/>,
<contact fullname="Alexander Pelov"/>,
<contact fullname="Charles Perkins"/>,
<contact fullname="Edgar Ramos"/>,
<contact fullname="Alvaro Retana"/>,
<contact fullname="Adam Roach"/>,
<contact fullname="Shoichi Sakane"/>,
<contact fullname="Joseph Salowey"/>,
<contact fullname="Pascal Thubert"/>,
and <contact fullname="Eric Vyncke"/>
for useful design considerations, reviews and comments.</t>
      <t><contact fullname="Carles Gomez"/> has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336 and by the ERDF and the Spanish Government through project TEC2016-79988-P.  Part of his contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAHbM6F0AA+y963bbWHYg/J9PgWX/KKlM0pLsclU56azIkl2ltGUrllye
5OvpLIgEJbRJgA2AktWW8yz9c9Y8Rs+Lzb6esw9wQEm2qzv9TZRUWyKBc9ln
n32/jEajQd2kxfQ/0nlZZE+Tplplg3xZ0W91s7O19ePWzmBaTop0AV9Pq3TW
jPKsmY3my8u0GOXLiycjGKHJJ6NJWTTZh2Z0PhntPB5M0uZpUjfTwTJ/OkiS
+mpRZbP6afLNVVZ/gx+UVdP6pKnySeP/npSLZWo/aMqJ/tHkzRzWc0wzJ3s8
c/Jzlk6zCv5cLKusrvOySDaO937e20xgi8msSs8WWYGvwBezskpeHr3bfTVM
0uVynk/446ZM3u4fPTw4ungySE9Pq+ziKT+W4ECDy7OnCe08eVdW7/PiLPmp
KlfLQbpqzsvq6WCU5AVsaXecHOZFerqqSlg3w263SO2HZQVD7U7ez/OS955l
sNXt7Uff7ybpRVassmSa1cneebpY1smzeVpMagRK3lw9TR599932VrIHeyyL
0XF2kZ8VGfw5zT4Q3FZFU8FTLyp4KYNPskWaz58CENJ/TmHGMUwpC305Tk7K
VZPmhVvny3RVAZTM57TUg8OT0W4Dy2jyP64yv2T4bZTsJBWtN5mnuGJ4DxZU
pXlG3+4dJ9vfP9n63i7/+yd3Xr4sbCwL++d80YxSt6LxrNJN7Y2Tn8pF9ie3
pb20mgMs9UPaz9siv8iqOgd0SI7Ked78n/81KQALcBd7sIP5qrhKW9vce/i8
brKLLDnJqiqdpvUw+Z6+2PrhhydwHil8O59Ps1k2r+1OjpcMSNnIhJZzVv4z
7Cabj1fLyTibrnT1++PkWVo159ncrX+/XOQFbtJ8Q5t4DSA6ywAyp3X7RH5I
JucZvJZMV8kvebb6AAfzf/53wSfy6Iedx4+Sw+wKoLcO5FOdeHzKE/9zSTOO
4W4mia74XwDg/74q8rPUrfhfVnBFEOxl7b+iJR8f/PTi9f9orfbxzneEQf+S
wWtvSiJJ9AXsLIMNJo+2n3y/tW6lOCHPN+b5/rnOz2blB1zpoCirBVzviwxn
e/Nib2d7+0f59cmPj57Irz9sf/9YfwXCp78++h4eyItZa4zHPz7Wp7/7/sfv
dLidH3b018ePvpdfv9/2k2w9oWefn/z8/M2r5ydwuK8Pxttb4+3trR8fHjx/
/vz4ZH+8s7X9w/iHx999//jJj4PBaDRK4ISbCqjhYHByntdwMJMV0jLA1lle
AG7D4dyeGgIlXGSXQMCGyeV5PjlPllV5kSO5OS2b8yRNzvnViXl1kU3O0yKv
F0RL4ZjKJRLMdN6iq+65MVHM5DyFUbOsQGqG93zKlLe8hFt3CXO8g3mT3SpL
k1dZg2uqkw0iuJvjwYBGsKuArZ+mNQwCv6f4zQJ+Yf6TCP+BP8sKnqCtAP4j
ZJiCT4HSTDJav3xe8JTwJ2wCALyaNEBjkhrWBIQxCug0OcuAtsF8NwIpb+o2
b9GHE2QwD4HTyCj1uH2w6bwuk3qZTfJZjtP2AhxnAvDVdbY4nV9Z+B80QGoK
gH6yQpDB9PVquQS+S3vHFSSHJ2/h5T+u8iqjWUugiQZiDQxWlPPyDJYwxjtn
5oXFFhnQbD5QGm0KdPMMcAvRMW2Asc4aGK5ziPD45TlgRL0C1LNfXAKuFGWT
LEv4+3SeDeEs8/k8yT5MMtzAOTKYq6wa7SSL9EO+WC2SZXo1L9MpHNmfMoJh
JmjXPZyuDOBgBfCFY8+LabbM4H8QEDOaTg5g0obHFUOKbw88eEUDIJj78Eax
ZrYqJnyOecMHC8g8mwEKJLN59iE/zeGLq+QyB+ytsrO0ooNbpnhlEZp11jQg
d/CLHt8m5yXgNqBRODtRUhgDoMM0AkB5TjyjddKncBPwlsJ9YADC27TA8eDY
zijzeMDA4tIALhX8DfRkCneJgJJ9gEcbxj9AxTOUlzK8gbitqpzlwAuVDuHz
ivN0SeEOwzJ1O7CYfUCxZFFOgcMS3uEO9OLj+nREGgoEBTzIelIuETmQji7y
6XSeDQb3kwNgJLRKxISP9+2fn/7forLdu57kC7iDcBYgMYlcnszzRc6z10h9
gRvN4PyBKsBEIAY0yI+HQmMBP+ZZtoSDqt1VavIF095FClhSAKmqskkGDJXI
BogpFYrT9TnSpyVclXJa06v0GhESmLKoFzlBakjYUSH8CI+yOqtgqNO0gSev
xrE9IUYQVQXQISuFOf6EfOIKaTqApqElAQrAh7QkkCMIqR7CDi2dSTbqLEs+
fhTp4NMnBOLP3cMMKWSG4MoRmwDVsgpYDyJuAXcjv8AbTxepAMymu58jvZK7
KVwKKUsGQ83n5SWCCtAJ4EREBOAUPFor4YfLNy9zuX1nGW7HLKSLgE8Hg29p
GuWMTbnkew2bgTOuRmWFr2ZTReoFiGxM7wG4c4DT5H3W1J6eIBFNEYvKVTXJ
RoCfQEwYiUEqrmQ//rll2pwzUjGDzgQN7H0c0ndpNTmHrTHLxv3WgLVwhqek
OU2q/BS2DfdiX1ByA37ZVAKIAHRCHbIepLcMw13Dso8Rq4A0b8CHmzArEK8z
vLpyi5Kf0ia7BHzeePXTO8SCb5Nn2SQFPuAuAnBlRLJVPgfFubDyQM3bkIsE
1L+8rIVI6ongBmBz74vyskCET6cXeM2AtQOXwjMosstgSHp8jgLGDNk6wAoA
QrdzPmeK6rCKF4hrSAvPwvAJ5lXpfLRcVUQGcDkrvIFwKvUCNIHleVlkMfkM
do4ikhLHjRT5FZ7fmxWsahOHZ7SxsE9PkVALMgLln8ORE7qhHCf8VEdkNAQC
/JSAdwF6WlYriQmHQFpDeDJh0ABop6Vd7cNpZtcOX6LwEfBHID6ygPSizKe1
Q0q60vg28GygGvVVMQHkKPI/tSWL8UDPKoXnAFcLQnGignDSC9gjvk80Nps+
RG5Z1EAVh0R8cQG1zAO64hXQpPQCFJ4UpCNLgcaD3eAcgDY05aSc88WssjlR
iSKZwUpO4YoSbcLNoo2lQVmLbwCxU0ce4apOCLgkqRHaoKB6UDBhn4AkXuO+
ACfg6uMRJzlKT8i+K5wiK+i+AOSrjGh0wbLnbAXPd0TgZJ305jkjjPu5klpO
CERi2mDwYoUqbYUnwMCOCL2KFMK6Ya8tK5KR5q7+4XYi9izZ3vlhC/hOA+Pz
GYK6+enTkG+hPNuZyh1pyoOn03QpX5FQDNiEhBTnBGyYTIA5ApGbXw1D2ukV
mT7h4mFMm/D2shA+t9hxR7VZJxJf3VUgrp1EPIhLxMmJQ4WRQxIvRd8goR6p
PLleLAV58o3fcZ28KhmWrJG8h2MFdgHk497h2+OTe0P+N3n1mn5/8/xf3x68
eb6Pvx//vPvypfuFnxjAH6/fvpTv8Tf/5t7rw8Pnr/b5Zfg0aX10uPtv8A+a
U+69Pjo5eP1q9+U91n4DZROgwJvPUTaBS9cw7/SMFN55tneUbD8eEMqiCeXT
J0Hf7e8fw++o0w35+FC64z+ZsSyXWVoRb4F7P0mXIEjOgXIMYAYQ+IC3ATgz
gqKwYMvaP96nD0f04ScVV1VAsVIAHyeIAUAgQQ1ZlMDkYQGLIfDfJslSJWKW
OqC9qg5liWwupzjNEQ+JiSIZbwshl6TxwWDVIpfRZlW5sHR5OBDCo2SROYgX
4lTNYsbbXC2Bk89DYU7FzRf52Yi+oMWC1AnCWpIkZdKScOgwUdUrpiOVQuDy
ngPJhkey8dkYyB0wmbJC4g1bThv6NWsm400iwiJPnSIRAuJ5lZznQMWnyJjg
JgIB02FB/kyqdJqDbMmC0FiXhGj/hr5xItIbEJGQ/MraQMvPPfkGURgNXDmq
LvO8eB8MFJW2dCjCWJWkgRiSCG3Fz3AZKhWoED5OEp2qK/iJ3Ne3aGvcmWcX
2dwT6bIIZmGT0mDwn/AD021swoz+f/DnesB/wH/8//jzMPmdfP1gpD8PBu4R
9/8P4Ynf/YZ+rvHp39OIif3xA+AQOpVbgH34OvnH0eh6NPqn1hDXBkDXAx1B
/3uoK3CruKCXfmN/8HOGabBjXgXtIrLgB+s2AihvvwUkq4PHAVUE7B+fJvfD
O5SQG+k333SJzpCVCSb4dKlJkGJiBVdVLvg3QI6AaJ0YCvDxPv71iVleLThp
7QeWXJCSPwG58WrBYkmHNAPdAcr1oQHc674OaBjIgN78JYMi5gJKghRWTOhi
vc+Se/V5lr0nJvAc5IO8Pk82gDzcg81P6NMXQPEm50oJZiQehezisspRdrmX
8mRHpPPdIz0DBDdc1j0gH/Y7Uo3g3J92dawh85kZXX1Qxu2Okt1AY0KyhULN
Q7YckBIs+mZTPpRjyhAldL6Dg/2nwb2mCzlLJ3A1naTKgic8yofcotXh/EQV
ch2ENb78Kfw3Bd4vUswYfWDOwoD60AvUSGBdyEyXDem2qC/jyCxDiQiMoHM7
qlKgKKynJlnOEodOkmy8XRL27F8iMc/4gM7mZV2n1RVronv7u0+tXerhfqDu
7NJAY1nVqeyWdHJYhVOaaKHAEIDUo8aGYkEjFJvHKqvAsJ0GWhhjOL/gtS1+
BbbijJBllYNKDpyPFLqYPsdbMut/kwFNXWV8eKdoaxddZ5HmhUgzpHBsnGZX
pVB90lHgoOHxbD7bFMMSHsRVzsJCx1wtE5P6CbgUKLTOsK7PG5XSWPa/RZR8
Kmx6Hb7Lo4S1/PRnICxSxBBD9w9gOIc6oI8iPpeVaLZ8UOi5rEVN8mjm8FHQ
EfFuCEiHAsWzfLOD2qTOO7RW1XlOpg3UINL6agFiO0r9QJcmCOHibAhgVOiT
DQhhywu/ROfnZYESgVmV6t5RPX7I9JqOce/hftvV05Sdr5RedLYC9CdpVqB6
k4kZ0IpuozuGIWPrEHT5BqgnfIcGOYSsEHZndzgVMsLIkhqMfoFHzROH54ta
bniuXgFERwbfrvXgpwle6vgvs+IMXWI82pz/kpvm7p+cdnDz0JGEyvwHZ5PC
a16sFqcZ0Qq6fHgmof0FvpnlH5Dt0FQkhNKbIOVmKohepFWekqunKd9nhTw7
TMbj8SaNyRvVIRw5WhVsFBPaQlZiuZXJBI25dHwnwUZbpCn311AQAXRm2OGy
JCbj4a1aI/OADTKGpOzCwz293T9igvvi6Ck7tvRYGGhOtxQ1aLGaNzkiFRt3
SPDnhQ3lvaMSBG3iN87/R4c0mawqZM5C7tedPcpWZHX+kKLtCC5FXtVNsqry
EZmfWPVH3jFB2qifsxbAa9ord9U2szlkzzuChW7XNsOWqfUWWeVwqelc3FJo
E743LYtv0EpUZfeYSX38eHTkbr2QO6J1cSJ3nGXeqJBOpxW/GCprRD7RwS7j
vdzBSBG0h8B951XmQHKmOcj/yZycIWwuISrg6GRNBgZFdTH3sHOgAGQDGDCH
aOuP9Ma0zNicBjpIhhw4B/3XIxOePe7j9fEBu64Y73KlsLzcHVk+RhZNn/IJ
y13FIAx0dtar0ymIPbWjzOyTIGcF3Qzy5+3AVkjNripcnhjr4GNruBnqszgb
zoPmIEBUEDgTfAfutDP1i4rX//oC1MOG1UU8oDnxYxzoxDxEnhOcqK5XC2ds
Ib0vdZ5nvMaEtqirs5ZJYDl8/TQ5VCr7WqgsiYeO5CorJmKMiivhphBusX2H
BIBMSj0POhZ0BIiHk27AJU+efwA2aIQNMeLixS4EXQitiMh7HxJz6QYOrK5Z
3kPoWaxiDGCPpvFyIQwZT0lekc2yKRdXMSSsI0siW14cJp4Dt4ZPAH3n+VlB
UjtQb7LKAW3J+HLBfeTdyd0RY9dTnlOMcEShmZMJmUQ1mi2psh50BjEsPVMw
BjrQMRqG68ePOPIRflXjnKBz66Ro00USS/IyvNzkkxVaccRSR/R7jvbsrM7M
4DjGM3SnkoJERF4FuMWqUJq9WNWEn3SvEbDZ1Nu7SeTwqzB+iaL9VCD7nZJu
pLKwmQ39ZHA2FOTo7mWVsc09SRen+dkKDSkAkHN2fV0JnxBRUsZiBMTJjNzZ
Ifq1ewoF2w3+xVHRTQw8tFZ5ksIYvb0ghOiEQKzJPV2fqwnJSWM4NL95ll9k
hYgJ41AchodqFwdhLcM0z4uHb0JLLx4drFwXIVi353QEo6/QXTe23ZWEAPlF
D1USQOnXKB0i9g3pSgL5wOi9fp0INmKldl23LC2Mf3kIGojayb/m6vpnweUZ
pbq2AOSPEE9EghP5Csg6sU/+dBPkE3ToCRl0UQPW38hWPaN+xb0wgehkDRbJ
wazvbRH5yQdTkAuL9t2s4GZfeRWS9VAjhw7tR+5GAi75Zcts5B5k7kcOz8BC
kWzoYtFzNZRrQOqg1+SUDHmGGorE5xKj1ILbplJUnA8+/fSJ7gu596YZcJY5
o9TJL0+Tk7RCVzzxHcScXgbEayBujq5CZGyWcDldOe1qym+XT+G/z9CbFEsd
bRBupfqTfg6z7ALvEAdSYAMX373zLt1weQxSbeiNI5vrDEROYRv49klZzolr
DO4LgwKR4SLPLpOP91/Lr5/UJ83m6zDSIyUpJ+I3Y1sxCnrLpZMPN8QYjx40
vEKbGpJj+Hb3Sede9yIiKAfeppCTAHCJtPGU3q4BK8eABggxa97Q753BOgSg
fr1J5gRnl2QvAcUykUzB8BKrc58VVU2pga2X/yHa4ezT/uXI+/Zt8+w1j2W3
hh/QEwSWf4yuJjZICIHbL6i1s/b5XN8ImdB+bKCrBuQjpyo26FyXk0YMQQAO
xSbL6NOeHm3Iz1iUaGHgekqe1yoqNqJftoRKGmQYo8Nk9EF1EKOlFsuGoywo
DgF1U2dWTYhUdgkpxv5kZJCEq47EEAXN1gTOXjgeAEOQOCiQj+OLvIleHO7+
W8uI4kx1vKQx2b7zAqN1MpFL2fqSvgcSPkfdUui5hJ2plcUwJSC0K/RCOWkV
j/u1G8vfpRu4rEeo0IGy/uf3/rWLNY+1f64HHYxtu0z6cZvx+zoUveh29UzG
T4ZS01dYgZng9j+/D19DNCtbQRMb3252XjP3vbWaQFhIwu/+6frzFnn9FU+1
F6oRsLpTbVHNvvn4YcOVv8IKdGj8+f3tts3PBm/eDtrybPCmWRNvb3fvt8nG
g83waB9E3rzLj74ZRSaFft1CJ4GQQ45jNCBUt5nujZCvAYh5T9WxwjahhoOV
MCghcvRA4ObZjHRMMq+IyjsePHjqaC8G8C5ZlS5ar6Platxiha8NnWVOyIKZ
/1hormxPZRndA/K++/eDa8fqt3FlHnlWVFJU8lSN1nte/JfoW46r8IxGLWRO
sm3buU1oBU62nLxvKJz3JDq8WGEiS1FFgnh8zE2l4bJi0StXzZKD0x0hFQdI
qG2IrA9QpBlkuU7HaK3UzKemKWTvoJ6SiaS90LbIqa8uywbNBaSUsR3JmenJ
isemJlT02zbP1Bu30S9AEW55IckZIIixIHqtN6QLYfmmh/aElydOnYDsuU1e
J9H9yRU/EuTQW/y5U/KdSNylUEQKrgRjMccL3E9eODsInNNyiWf/8b7/8JA/
g4cZNSXgB5+V+CH/vgtWomCAtsAC11hkJRY743FO7lUbXgR3nc9LCU8r0uIW
P7vLZReqfQzE/Tzgp4J/4FRhsG38nx38n0c302mMVtm+pn92+J9H14POWzcP
w/8T/OOGwejVWw6Dj16H/wy6StaNw+Cz161/kuQr7QsHcno/3nHQxD8PQO7U
H3zRqdtJHrhR3G8PRt3fknES/GOEvf9Mrt/89O46+c1vfpNcv+LfEtqw+W1M
Pz5wC/8KFMTIOq7Rtsk7R8i1FMrevbrfQqYahCbZoCSiHsH5OMMqhf2XE9Jc
QmOuMCjROoMMGjRKcwCEKHn31PiDr96jGeijV/1pkvck6sixfHUSdIxP5PoR
Di2x3hLiYCNsKIFAPasuQlxdsfCeqMoSCWRYpvikcPnOLEfUMq9ceA3HGVgQ
Dgf5rK1LGj3YCQ5W3+GkFPZfqbrhnT9DfypWDXaiBrzgGLefqCUsppUEr6CB
VG0GsXhKlipgisu04gixBXufejJUKJzyp3cEP+Yl7D0sVcMnMz3AvspGThXY
yFWD31TBoQh0cAQmvhQYFMeDXUKulpXRCDlipauDzFO9eQOYoCwyyjnJLjAf
5ab8HBsAR5cClirejRuwWFeCfie9MQClIU6u1ypvRXQCMs8xwJhDGlZFkc3J
4V83ICjlNVpqTRTqwklcMO54gPlNPSkHQ/StifRWr/JG7eS8Dg9z2OEgjJwv
MkCbyi/eZsjBUvgsAIwsVKKr1UXdNj7NI8j5NRAFSNYt2kJB7C1vkXWRjQfH
JT9kV90apY+AROJ+0Lovwd2NeNZ6qM1QMwypxoPQCQaGS0Gi4L6oPEQbwnin
ijNF7juJ8uN9/O1gHyix83iJc+3KydfiTMALscbVVA3wgUDHemg8SgwVSl1t
Kxlk8e8fmfNwJMoHoWKDoW3skzrz1CnVDYFpR0qtuULjG9bbt9FbLJdI6a2X
K0/fuNwDwfeUZ8XKAjaIkwkV7ycvJvOVS9x1D3EuFNEPZjP0NFxgRoL15487
8M/1QqfHF1svObaPYI6BFSHIa83vCrJWWukLQLjYi4+Rzpmb3SfJUL43EEZQ
/kC104yiJFAoTCaFnomPAaD9DSURg3Jmao2wMe5DTbGR7XQ8yZSTigRTsZHc
pZ1bx34UObY+X/mmUI1u5CZFHRjVmxIQvk12m2QOp9EQK1LoE0lDc/RcmQPC
JD07sxHJs1KzzjpZku06B7r0ovShhJ0bfZmKR4yDzQ4Kh+5deLgjRKMNHYxL
eEKwCIvHLQWhnpqKisHF8P3+5aZA4R0yfJFoHG2jyxBGPvirQR5vhhx6uxRy
kq9JtgOfGk17wNUsgxhnvyKWwE8kJOpUUmxxQcgoEXPzOTlQqxI0ajRHnOHF
khwboQbMDOyWKfux4uNjMUinQ5rff3c/3lcLzGBgDQzEWKlOlK1TwkJnmAk7
VJGbbTAUXDwM0DGQpnyKJHuSOBdVc2LbyaeyCzU5IZNfcRopEauKJIpTwIrL
fMo1UjifbZ2/v0407PFNCSugqDuse4NB+sc5hyRKJQbOj9FrAJDA7CEgZTDo
NJ+wPJO3ctvroVZxkU25DHat5kJiP6xFXFXuMb2L8hxg3amGAw2VJF3pYICQ
VaE5/y4YKAj2RMS+0soRpy6akURBOxTsZmTCiXhVKGg3dnUUOW+CjjBmauVz
Vj23DFI+nE0UWS/hC5NGimyHE0x1gA5lqbHoE7PT0rkHA2Ys1JtPPCP/usva
UKWKQ2s5SI5vrPjKXLyEj0y2kQocoVBHLa06zs8Z1YmQOFkOYYCReUqAvDk9
iTFDQU6NjFQmAZcZ4f5O3Agrm2j1BIEgyOl0wnw3mAPjKXHOe3PbM0qUVdXq
m+S8ccLAalWMSL7GtEMcJEhetlVJYodv0JuU5rZI7SzWk+ZDI3EmKafoURLa
0BWL8lnXqSOofnCGCNnb2zHO8mD8dd41b0SFn/7dPE8FzGo9lziXmgSvuodP
Bwb2tBMgn2y8ONjH0IcwtH3jxUvzoYui3nhxRB9HUiCSjf0D+k5icn4hfNw4
+YU+7EScJhuHrze7Rv5oZk2ysbe/u2msqA9vtC/f9PO7wTrDHgH51Q2mp4T8
VV9hKTBK31L4tG9eCCzlevA1lkKWVEKJzjK2b7MMXgqM4qyV5v/9T8TF2f6b
Rrlm/Nu+fvHy+sXR9f7BtcWu6w5WXSMqCQ4h8lx//bXs/JdYCxpWEdTjsfw/
/CGfIWK7X5P4J19tLQ8dXF59AVy+xlIedi33d/65HvyuM9Ndfx62HLvIWpwJ
eg2pE1ZCluldvnEuBF1rB2iQs80YBLG7zjo6FzJ3UAs5a9ApNOSsZmFEwm3I
Doc24mMqKpTscm4If4H24n1TZegII5CJRVJCy9s3B4nJgNmkBFublhDEa6de
MKQlwzBo9CO2x5H+ok6qlU5XPZBgdU2GAqkHE2iyylsS1SjdLvkzpEIWaPFL
T7M5Gw8lvF744P54wEyYZCMH55adulXe5hSk54u8rHx+hQ0a1WJ9eeOjgp2U
N+WiLyzqMZQjLJt8EC7Uv8fgprV5XEWIjs+bxZLI+ME+w1QzFxIbFFaoQD59
6hP7MDqeeATXSNNUg25WnWBZDJFALFgVHMFfrmr0eJNtgypfqY+CcSINhXPE
eQ40QyH4QPZN0tWE5Ca3joKmPLNgRn89Fi5rJQTKkyZ30chBXnhbm+/nM/y0
YhhnGqeSu8cCOgZOY77JZiLekrnLJWTBncR5p2ZggATm4KH4VmnCX+dNjSm4
fZre6RXV1MQJ+5Lz+OiC1DwNSO/OLAW4cHU2Q18jAkUdX4nVXd7Xyp6U2bPB
WTgU6YApi+YsAvHzqZbCa6hGimyNri9l9eFVnkj1rdZt+Lm8RMOFlCgShKca
evhiK5uQUqIk50+Nqj7nb0YkcDx4cWSybfhu3iW3kGynOEbUxhi5u6TKYSCm
eJyyWQqr9vHr23zn+e9tez+ZZGCoql+gfdimHhIW3yX1cLdXIzDgMfTJGY42
yI54E5QArasssyYvtfc9Zava26OXB69+i9a2zad946kCLD5S4TJqXCHPmcQ6
oVlclPvd5XLIU+y/fveKJ9m//KJJnCMUxtZpYEaZ5tnB/sGb53tcXyjZeJav
nSs+ja93QCYAV9+A0yba6pkiN6NBK/fvDPXLWPKGUDvEn2BEV+2mnqToXfKZ
FcWVpCtjpugZXcMGC1VqvRwmcJTmodXgvKNhI62q9GpIXNHW16Eha6nca1Xs
btlSyaYIdepv+zRTjS6L50T6u8m7VoO9BQWvrzs8EhytTEaEyKTgJYevHQrR
jFLLs+03X4JkIROISePwdd2bSKSHYrJAJufpcnT4Wq6vtbz2K+BObKg766GE
yeBFx6JFKDNFL7gCKcLmtcNhNPsdIzBgolqyYFc2PVEvv6TEYGkNdXOO+SWX
LpeLTzS2SCaa9lN1/NYBOGnEu8ITXuKkGu/lnBlnC5bG3Rdbd+CasbQntjSy
KxfiX9eAQYm9n7okofi2nABJsoj46wrrAGo7imw9YmPjwtKH6qDBxWCpBzVB
Os7JBTO4gq0rRVxlM1ZIXBGwmH1cDb1DsgJWGdUDazvrKDLCjSJmvNc3uihD
B37g3yHD50SCQoP6EkNvF7bpkz5mBfSccpJrJIEu0QnQBAufgz84Zn87lxFU
97Ef9hahFcy+W6KrLQOLU0ou7bwsqamGYgdsqiqXFS234xDbIKTS7Ux1L5uK
PIoCJPKCRM5lPhDPJczHVyABJLfiAdtg+1UpFRAlmMnFpxCBY5Vjr73aOpuz
8MAx21Jila35bK4/rWAscyx4qZ1CbKzs5xRxoo7CQae20Aa7yek0DziM74hr
aaCa4urzNTYTVMRKLUvU1c1OM+uURI3w5FwzG5E8zs9ApWjOF8qCnCImss6J
E+RAQVzKjifn2eS91XMc4tWsqrHf74D5cKAViB4TrA7lXiJ9QOk4RTPMmYxV
S/FVT+VKwbSGvKh3aZrXXHsSd27WFJFvjB7EJ/VC6/R0l6UhTrHytet2eNMK
HcgLbojgIN4WBAIFm4l5XtkwGl+Zp09WHissYgejJPPLDoQlwYPb7rpHC2FG
MeOqr3IfEXVtYENEdfsr7G/oL+ot9pgEpVfIf34U1XtcXin7ufNafTgxwfyb
GofB1dEUtEcFg+x5DQDa5EFKHdfJScW5Dyn2zZG6Zzou36QXR7/ZMn0qZqs5
EcNVDnO1aT5LUt7SoiY0NTHRgFZPFgsUPAHAnmcXKbrujIo8KVfzKc0MSvIf
V1klpThZT8bR9jRWQWXC7ENWTXLcIxk9sBaeeh9rWyeK9iVeTyYZUgdawvs4
9hMn88wFBlV1CI11yAnNPlCy9hVJg+iFiMdV7sNrVOk75j5v5DMMdD3OusiU
NsLS4IIONPg3tffrNudZ0Vlp6Lft6nbiy7ekdKZF85ygJ2ZLT6C6VbhQJ3Lk
OqNKpmJTitgdQWZr8tpJKOEaO2PXrHCRucpHHxGHBQWBz5YJDt6AzWHik3jI
ADXPWQYmgdGEfXg+wAt/jcTqMq+zWxKGvG5ZxJw5fonxLyB/OrFXLhQq9m57
JHSdlhcZMQ1XQ53LQMotDxbPq3znnOm4GdwT20XdXPyO8xxrHhpOF0af8Xi7
PrY2lKZrzgTzFe3DeA9WeLIztLtg+TH4dwrbczCgeNe8QYteWnDxJzpQqTGd
1/UKo+ro4nA6KS88Fl5JetSQEdwgk4tHQVjbEhW0MY+tKnlPM7Y0yeXAkHGp
uq9dJjjg9NPm2NF+lJKqNvqK4BVLeOrLcsPxjiXmgwobRAtqYNXQ+RVXbGQD
gAaetdXwp2jkTc1h+6C1oXXjhPKOpNNp/ZF2nOFNfvaa9Px604YnaO0p9TZU
QUuFwDvhynzE5IVAErYDt4rGmL3p1SdTbhUm/wU5eTJS7LxU/YkeMOAw4ksR
xGQUZTGiYXXK2rt5IjAftmFwx+1HHDu3el/2UGkOxwKb91HlDOo4U2ElsKBe
xXXEVxkFWeQ5TsO52Qurn/RlMF8LBLcVtu6THfMJuqr181f+86+whtAzi5t/
k7l82xgsnAKObtlv9YY/dSFLUvFG80u8oQXjqtoptFF6ooGFIjwR5m1KhFyM
jEhxMtIg5le9abr9dAqXrsF17S1ofZyOH0JrepHHpi+oS71wjTGwJhRu7Eon
5o3fqoSCu1YqO3o7KU2loLQQm0UCD8jupLjrxJJLkiCNbQHdfrcwqXhLzMN9
L5uSoaBjHXJhqLIaqaOo69vPLv7BmQov0Vids6VQLVlcjtZnbjPwx8lrVztV
jFViVAjOR2J815qvahc9Sh4MLaXD452XSL9ZbnA1k4kXcTQZyT0+NDFu6/Xc
jJPLsZMdeTNyCRkIKhNPMy5m5OIYpxzMjn8ocR2KPvQhm45qqi1UVs6rKJ8A
gcYDU+5QhbwYHh6xQ3FENAPwHAvGKZhtTL+dRhdA+36hPhlnVY1cPDlOT3Ur
LL+LhcY0QkFXpo4qa1XDBxZxsT2wVvB6Qo4ThDkM7UIr7yY7J+O51Mq1yogm
+LixnCUU60YXfCNCvSdQcC68N4MmMEljPJKonN4wa4oE9IYtdEIcuJDeQWFK
Fg6JZoKMOfrdtz5VQCrXeD9CsKKZQqI2hQ5dL6RG/dDoZBEb5mFXI/l4Xx0k
g0HHg0MKS70pNhDxHrDrQaNuHUkBPkB9Dti7cOVS/dFtNXVpIWE9npZ/jPxi
xZV2SqHgenjb1hlysQgu8wtHlfiDU1accJgX6RzdRugrSqvM+Td8MikZXEE0
TefM49jIpfo12yA0/MAgR0sLtMHLJ78Qtc7PCrgxT5NXJi8DfT9aNSlIVeof
2fnZfgmxxoCCqmQD+a2pAze7+I6fbXzA8o2yH+Rgp1ohjjdDMQXoKyd1D0ud
o2KFn24mH7hMadRaY5dKDXAQdnrLY6v8YFxaMiIsj1xhzlGOUV4LPHKal3uJ
XZTzC1teWc1QLibjxUuO7zDt2sLgDDuzVvEMq0zIMBiOMQ759gf3hn3+B4Ue
BXDIAK6+hQ8S4ZgOPAmC/0gKNTxN3jlriH7GSw3sGLmNb9bYd4qFDirc0xO2
1LeWHMYOVx/GgfSFQ3KNSHrIZkDT0zaS/xZ00ZVvJe8u437eNUR7U47DEmOy
Fp4hB9wwBHBTQqVu8tHW4qQV0oW+yEGnpMmtnbuu4nqKpcR7vNCuxme7T5wW
DxNexIOIhNrtXUA2qhDODFpf3yTURtb81XkWo0Jln0E8bFihK4RLOyg0Glh6
veavblzp19gI8I0RCcZ25GxO1bXlLxQ1gep4qx/Jcn4VBNfWINeUBJLYIZwU
xBgbbEQuajAID8FXB/5ychG/TtIArIpuKA7xEgheB0Q0hH5zzar5GF/j2A67
IBhCuPjo235YVJmGnKVNiHW8ERHHw1WEQ7DpHJ+iPYDMTxmzIPfzENwW5Y5D
YNiPH+LL8ULVWefxj+iz5PWJEY1vXGUcff3Tp6ReLRZp5Rodg96DKay2jUmr
GbbP/AziQFx7BuOznJTz1aKgMpuW0nxTU/swjcGgSvpMTfJqKi9xcc4OFerG
nmh8rrHc8CwUm3HfeqtZIxBWJVTs4337qSgVg8GBFXtCRtMXrZeQa0BqbtsO
DmLsDLqloGwd2q9dR5HAEsbjpAsMgtaeEa4GhjF6eYm/1n6udJooU7TKcsTW
4fYqjbD5Llu7m4aIOrqEfGTopX0sDWxApqujEO8wEi5iGXG2q+tR6/1oSasH
SqQNxYo/F9qA6Mhgyhf5B4n4ldvDUGZVMZw/sAl1EMqprm2c6qipX45RLVFr
OLgTUoWes9RLU37rg/YJk4Dj6f/moKyChXBPZ+1H4ngNNrw8frYpnf+w9XzD
tXLUGdOPuQ5lpSURrfdmpB2iLWpCJhNfd95YAkTAOImJ/qdemNVOC8JQZQby
uTgFwT7v9oFr2DQ4POpgsS3N9qCFo4DLNPN1gNH9z8dx+pe0CnE6OKa1aH2i
e9/wbhYS8lttXjA6PueUjCnbxh4Pk+0dPPCdH0R9CZXLgxCwqvZtERnffqyp
qjoihX085pFWhTRkFwWZC8sTm9Jhtr+jcXa+e8zamB9l63Qbfjr20h/WDP0S
ZfCKllp3hvswm806o20/6R3uK991ZY61H1E8k3Thol7ZdmTBkE9hK3S0YZxe
BmNRlilTaqqPgXTOUnogaa/K5hj+8qqG+14EfysmuLyGli4U2JrFAxz6SsOE
ZssvSl8HM+xwwM2yeBHS59WtQ8nBPdLC7oHqTTo0B6PeY0PFvSHPz8onKNrU
7UoqOAZBBnY3UQOYzQ5hIoaePBv+FYTIodlUfawkEqMdwJJHn/EgbNYBfdLS
cCWudiDxZWYG0bnqznk44AQaeBhEoHE5YZNqdwecqK72bUYdww0AXwY+8eDO
CIOQ+SyUMLdPLwmiOLuAm6tO7zSi62TATJ1eHu/upffbI11Qr6wsbN1PKxgM
O4wpMCG3yW8Qkoy0N7i57SbDMdO4dpD2y5TwSQ0499dDbgLeDz7CQPNzhxh8
6od1jUsYh0U53LAmFrWSWVQL7TybvYYYa3vpTHrGFdX9VgITk+zotbekCd6w
88WhuD4fCeGvM6x25Sycci/ZuOhm7bOht8HIqoCvIhf6BhhYqb2qlUrIN0kv
AugvEF8ESAHx8GDCxa+kNKC/9zxry7Jj7zBcW41OXi2N7a7wBmNiJmFXPL6y
posXllrAi8OtODjyQqz9rhoQ2VRdPSTWQKU2mc5Hc+s9cjkkkiJHW5H4QPa8
1qsJifoXpshZZyRiFDI3+jm5lzmPuS23CU0d7hLhHzejMduxEX8p/BxL1wS2
yw4uWPepDStj62QqD5DFvAJsvfJ01Z8oZ4BG2JTH2JdUnOjYTPxMJL+u9mcE
7zUHHDe4CuWE018FmZgddzUDiu75ieoPYQiFU0aLz6T3HZ7qg0nkQnyI3k3y
IwQkT9mVu0AtUP0dsRZCbLarDaVnsMPx2huVbWMrTQBAkodB0RfZ3CfhKWjQ
ZBZrbMh92tWpzhO66CXb65DSOd16OG6uJilsgaV+yG9Op8WZkU2kmCTWJ134
uFTfoM9HArQqk8PSvqn1O0GZA63c5WrdsI1yGrQMom61+21p3kVIUAUlep4C
dCW1R8pBtVrb8viubL1N7rGl6wmAuCQuWq9RDn4tXHhcFfhpt6IkpkUOux2N
XSlZhb1YkPT8tViQ7tAdmAu0wJMYhsEXfBkBuDapfNcB+r64S9hxPBgcmzBm
zc1mI223AbNYm/VUsCodykaRxstjbDbD5dMCzQ5u0x9XiMWhbIxXzGfP+7x4
vkSbagfhyOq+pOwwY95mWvu0EeSHVGHMHD1WD2JfnjST9TkqSPK5rkTpN45D
LupsfiGar1+oZIQbLRS/o/STerWgCp+9FRg/3qeSveTO0jZThFKx0q2CD4cn
b00kS4WFoSTSFmgtN/xeFXDwnOYhnkY6cCYDeDr2Fk9L29SRA1dJPwsWXUVa
arnqqr29dexeTf+tsLRsRu3apAhchMyItQ6GcIyfII6AkKjRhRSG2975YUta
A3Dr652tLaTDXIbj9ZEkEWNIgUYGS0e6dmzzkOpraflIuqP8/VWiHTcxMOj5
v749ePN8X5WIEDddaU/N4XI1RLF0oiOO1MJaJGY6TtwJ4H2uocOlxDxqlbw4
wCn4xrb3PERRk2ZSEtOyVc1WaN3SSp/I8IMFOobnqjKiNNkqJk1B6pwU1uqY
ZNNDvQIvMJSYVZgF893Vle4ORSJBuNkhxfR4Ot3tknvCxXp9c02N2uN1hWVA
ucgh59a5HlfI9zHM1VTctjW7UZJhNqhIGH+wJntuKq3rTLFu6flbeyrmRGWO
PCMUCJajONMzU7AmScehqzvPOLkDD9jiA8es67ERvbDWmZ7t+BaqnIOKATgS
GiUma3UtCRoFHXklHu0kqxafPm22o9/IeCjGPGLbWlxTetoh4FY1929Uplh3
iplrpfrdvd+aFt4alEEIKmuqTfFDHNs1VnuuZ8HkmHsB6o1endbCz8N4AA+8
1lEaUS6TRpTn5maFtK+306UIiEajIloSjqUAA96QU+HPS1CxALGHKFdjQw9p
rQ1y4ZBqeFQMsHZ4HR5cUKDai7Zs86MCyXgEWPaVyhySLJVXQaSZSlAhFck7
zRYPkSZJXvj95FA2MfCnbtm4r7qju33q26cKGlAgE3+biDe2omwrVffCVp1O
sKy5c5BYAVzvNjc+4BS1uIXXQCaYZ9MzZhnUO97yuWHL1ufG5BnGGkiqi8wj
PUFbbe90tKUG8S1zrFMJv2Esp4RDX56XPlApfomHZF0VJX22mge7QwaGwEM2
mtUu5V7gwizJPTtrhYQaQHELptHuaVkFhxGO12TzuZImDyjhppTPiu9n0yjt
Snv25xehjZ96lxEcTiaWEY8DNPtd5yYrCjEeL165IsG56fbusB+edrh/wtf2
nV7bZ3ptT+iyYrQnX19sQ4rYobTpvns72s3KLJesiow7ka4cDXNFHIJ+dTzf
J30gwVimOSWKYVrYHzB6k16B6w+iPYBIXwpi/UI4+cqitGqRvbXCqEuajDcU
jf6Y8fXpB+IK9PkO8skD++fowXg89l5D//nowYAW5/rOmCZxpgWN+9PHOF0H
j5nGfF++otCTaYGnTsw2cTNHz4eK/kuiubZPiBDhTWLs0sPS99wNmjfwMOz2
06qroeipF03pbmormzfc+5z0PemLNdRoQO2T5XRF0fDHguJyMwD95bdPoryG
ojQJuFjAGZfp7ZGM0jD1WVWulr4wtrBJtiTJH45xDwYjZzbV79osZAj4iqRZ
BCHe6JDvgZpDnBXNW/XktgkzkM/ht3cHr/Zfv/uP44N/fz6G2c2f3ugUOgVd
f71RsE4KpqZh0c1F38El5U/kbjvjK5lemahvJasl9ngxbZqpz3xQClrwi9Mj
2AA68vvnFYQQsPvgo8CWJ2SRGMkHdsEkWcNrJEPweDqFoBCbj2mOadbdhp1v
hLW+ysuCt+Vqf9xie/iG3SIthxbQESSCjLMeK0eqoJHj5gK/uqHsg+6ak2Rk
14ZcCt7fnmDe3GrO/ijh8aETSUDUbiK9vc/0d0K984qIKif3aUmP4T9s0LYD
/23Df1trPuNNmCcGDEwYyoUQwtf6q/9s23wGo1L+3c73CT6BURyj6xZVDs/o
1nSZyRJ/sPOjF95Jw7TI/JvkOw5LPAS1BiajEA9ABeDGk5W2ogIqUYDcLN12
uCIMKldFJ2FaEJLDONi8yU92DOStix/0pALMo9YNMfopcozyG/5TmY2a0E+x
nfVauZlpnRNAhcvgpdyVKYxvkAxFcCsoCxB3/U4vE3ESXdLH+7IaYWTo4xBq
LUOy2CtAao3vbq4hu2MeSN4+Ty1RsKfowxJxTrGfotNxRIZ2VxGjNaWjf45O
tujceLAH3DqbrNBXkHDRyLMST7TCqmFDMyD7n4FMaQtOIqMp+z1y6x48KBzE
qNmIHLJTcVVFUebXZZGDJtwpLeauW91yEXLmcFpM584zSRpQfMKEg/DloLUE
LyLsQ+ePgiO+195867rco1uMaaHZB9SQc8RKakOBLuzGcX+5IS9hJNe9bbAb
NhMniYQ2KGWbtlsYaytKUnlYWnu7+gZ9h6M4oLhCHZI0SV2tgiJqaWM4cbCG
rfVroCvgJyhKXlN3ouHN6xx2F3Ok/mzEXrSNevuIIAFNp81w2GVHdjaK3TSz
U/CP7Jmmz6qqrGrx3d0XTYwT07wydgiUV3WxmDxqs1y9BaPpjsXtdtAPeIH2
IJrtqeuX5027Qh4luAAFD3zSq62XKZeKMTq7sRCRkvwmsA/3TSWU93YToRiy
5FJHSqW5+ilnsdVSqVM2y/9qcARZHGpfDxANeEOKfyiBTfyP/4C//wPt68+P
T45FXUaP51mFcNpD9woXV3Mf6mcSepe7h1v2Ee5EZRwa6nHtyHcqfJMzxzvH
5DRYQDQWUupYJwZu9B/5FUx0udZVjeqHeBH2Xh8ePn+1/1yKeUVeDApGnl6J
K4ub/xgnC8EgOSYSDxrdxpu9481B4Cm0+5P9yJFjGAuXB7d26Lxp28ckvsSV
fXJeGZjMuQedv5DNDVW7+Rw+W6+WWJehDhxm6IjknIUrnzQqVBKe08eYUOJI
e2/2Hu0ArZhfFeUCuFqy9eH5/rMffni0s2XbdkmHpql9MiyQ6p3Vg5Up5fEc
SRk2ZcQijlNUDj5+fH7y8/M3r56foEjTOsA0rEMceiH9qcEzA4CBgYZDNoVc
qV4a9boYb4TEVZjotCVq74goxP9zKis2DBiTu+Kopbs4ceJhDemSuBLOlk21
nIa2WMf33RliOycirFQ2AaZA66iOd4q2XmymY/NX3SQugMEuF3k8l68iaiE+
vTosXtBGXhNa0Fd8ob1qF7ETKXLCBXab1v2QaNMObAVtHHxpfyGQ1eU18OGE
3QpBGE1tgn7YVwsInczz0yplUwqJ1ewFwQdGgE4if/dQj6Znj4O1e6QtKIkM
doxI+aesKkfZhwYphQubowKAuCZ/6DDawC0CsbqD0Km8QuWLNUJGOrS/0NQQ
/pv//NTqvOqsq9bQ4nmsePKJYjTOOFu37K+b5ESQgFzhUm0bFGkfYgjqzO6b
NJnyo1zcyZboN69wcD8FnJOVjCSfpFxyKyLuxbsqeoz4PLJp+WfdK6x14QN5
oTlG6GzAr4mPe81Sj8altlhdIq/dPGjOZm+E+ppNlQKFD6KOG5Gh51IDpHiG
gAit7RhwhkaXdJ2nlQw0oYsP7WUHUomFOhWQ6Z7H6jqj+9yldCir2vrtWiJb
UEjXVKDG6dWxmk07vgE2+QeWIA22JBjszucR3AVerrX8VON1/vdQ+Egr/7UP
IP822U+b9AwWmZykZ8nGPvzvprMs8lmIk9ttKk9NN2i7mNMMC6LJWlrwEfgN
kkS6sEmsUhAX7jqH5mhjSIuMonFwOVIOOW90NYGPelYFYQRFdhlAIPC0yzNY
aS6H4YMHV4VWmmqBiVHQWjQQUNqKQ6zBJ5ShJy0ogoYQQTyYy5x0wyfcu/IE
39oatod3MQ9hnGUX/C46H991Qf2mFMUW7aQ9V+VKy2NrTw4rTrksds/lygvG
3rwxBbysUBxA7mDGs+EWYEZcHVMHHwfZBMgruc0SJxLfqymZ7d7rI3mRuTxy
muLna2eJo7O3YzBFNkuI49JQiB3WzgsoADXLAMlyni6RmX2bvOM6Ie88O1ES
qu1pqfiQ4zFdBwQTvNp3cKEoa4qnEIw9XI+xIYPAt29A5JBuqBPHRtR06ZXY
xyJ8jqHPzTwIjZy09E78Ayh/fjneqC0gSfbbNky3cdkzTo0n5WcmqTqwzJMp
4A+rWu1yaSyNwBaeoao8HS1CCU0wNrduUeFqzydLvRIr0Iu9V9K+AX6LSiJd
Mf5nV8oTsSVAkFefS9JamFAWF9lViAnpaSmNJ0FtPqMUWnV2qdapni65XE6d
5BVEPYd1tDBaWpjgYgH3MMmwAW3OZpE25FOQYzFHUUpaeTeLFnqbmmxCOSmy
GZNsoBVf7BFoOdHuzSL+pg10sBGx6caCy6rUjCY9ZLT4plY+Os/mS9dYOEB7
MUiY8ua4JJOQpheFxHPndd925w9Cx2h7k9A3nRs9jsrUemWsY/Bw9jpzZrjN
Z4A4KPzXpCZHaNaw4wlkbu38ZKYlMS3Ou7qkHmp8xFvteyvY95bb9yBpKZ+0
JlmfWnZjhmx3GFrtuA0Bae4uQ/ntAcLSEvzuvr3JOtMS2rRXDkgM7mIxwGJS
cevav/2Ca88ex64x7ZMzuaM6p2YNnHbo/jImFa49gZX7KXAA3wmjrr9N9qTh
jTfkbT6FDymxdHuEZFaqLASA0ZApSwqNU4iDtZfUj08TWlTxb0tBgXFNbUuR
nXOH8l3TS0oUGXef2mOhvdn0deHakDb2Khhu6zbDURKzDimdohlzLykVfAag
5ijeby1jYau89rNufdyTUuWuYDHt9eD1CycG4RyCOSHkJk7TwvjbnK4YI2VH
wTpPqlUx4fMLIj4l1BAZDdkEON4TDQIa7elCPX0AYsivxJwwDJfJn7Y+fPP8
XzU0TEV8/o7s6DKQWLZjk2DXy5bhriRG7Hxl2uhDZsFiMIUYOrDqAbzGO5UQ
eLKm5dwbMyZKSGxC+NWRVhg96cBCg3dUYCTqWbnIZSS5G7XWfEiSJFZ9pCcI
4MF/xn4G150lXyd/+XN3ReT4VxvWRqrFQje/fAVhXQkHYfX5hwAKz+cbjdt7
k51hLccWNKl6gPMDil04+qQcd163T9wOAEcefdt2JHc5zphiwaJx7quh3sbL
y2hhtF7FdNV/cBTNu6D7kVeedgTFDpRLtWV33+WaioZEEZdCNWzMIEZqnCQY
v3FIURuvEnoADpuCOfDY+ReOtfO/t0JQerAAsEttHte8e/j3HYacoMCSXHcx
Mo6OX21BAVoaNFC83NdmOmppZRRCshzHEq154mVhUt1evfbhXSiMSZ4qe6Xh
pFzCDD0N4tKK7RLNoE1XiOPg6BExzolRwSss0+TUl3SV1+cUW4/FClEWGWSS
6sGaiel9ymAfDrhETkielb0I94CP4VN06vgSOda+deHSU8PvT4bJIX38yjXl
OGG/Z8ERlQnFfjftqMfcREo2xlDFxZ8xZyE2EBlBzWjRG0HSlC1NGSRBABGK
CJVAglr0J/ZQL/WxpOfEuxVdPvyawVTEDIP4xV0h2SK3iscOqdHQkqKhE2JD
SqWH8TUo1a6Ne4WF+tlggzqR2rRcqGtH7cebBSPUGtznI9N6qV+LAEbpH/z7
NpEqS2upTkB9XGhylB/HyeD29niMkXgEACGHISkct9ny11lQXzQiGVhCKnkH
EtmDvUgj1xC8Iorxxhv0dWiZzb1oEzT+jr769akanrWxWYn2cwOBG2LBtC5Z
tIN0R/gM+hhA6XY0si3eA3mEP6w70mooXXoI3468/P1XkJPiup7h3p7o4Cpb
/i/nIXPeQsqAV64fvssWUHoxIFIeLj2SWUCYMFqXRPLuPX9wC4rD8CSKs/eb
bS9hOcLSoQKiim/ecdJ1jwthZuoVI0v9S9667pyW0Ea/gw3R79cu+eY1hKTP
Y6YSvxc2hamD3N+0kf5n7VZKkiBeoz2yjwvZCdz3pIZLsTd+KvciozUFsc3D
W0s2h4OiNBYLcZv3j7bVHS2wnlCRCKLxm0ydIlZHkFMjV0jT7djeR+1bpXyQ
xC8bd48xnQ7SVjW3loHCBRnKPLbqp8Yp86MDtI1bx5PUG+padnoMKKE5MAyZ
8DFKpknKSwzkOhWzj9ZZo1dGKfXPEks9RlKMkmdU1DdNMOyvrDASpGvCYZlO
MAZX8LM2zghrBroKM7ylQdsGJYtpWfLFYLWJgaqux2I9ybEwRa2RblTIg5GH
nx9KfBqqMaTkwo4pBec8l8RdcvtIFBO6AlygkYwMgN0mbGIvurPN6Pjvs2wJ
hJL83TiAFLqtm3I5Zp8uBWtQ7m8BvN/O7ZcvunhZGN7no256rq2vGsisTlDE
7IgipdtbCtcsMeR+0Rh93/CiqZHDMJmsmFFPq3IJg3FHSy5RWvZPI+kDYjQi
Bza9Q4UostnM1b4hhwSOjakSNHzN7a9MnwfuK+cQedh7CeIMH4OCw5gnLSGA
hsmCm+DZ2ibRmFkMg6sDOSeCzs6z1dtqRIlOuxawv+SmspiuJkyQGMTuMFeY
9qlDmHFcuYx9RrJ00vhQs1qc3lm7GL3LvZDLvP29hMY5W9H2d7h9qW9RcT8Y
YyZAbtSbOdT7s07EcBoS/cgC8Ue/+GwhpMc+6H8erOPw28CVttf935fOrXui
YLwOZRj903VL6/EoEdgsDTyX81UdNtpicPrK6IbFtbDLuTIYCx77hh0ahm/M
wWuOc2/5bLH8siO7+VhuM8YdwduBjAL5jasv3qFKpHV1LrmHNv+NSWaxS+wt
sjgma3A2WxIryrjUxyeUE0my0tBc7N4UjrDwPMoM2OHYOVONTERUm/sUR/NJ
fq1Lr2u/4YI/Sb5LHiePkh34Y+s62aAd3Lf+AFtJunv3bnHH5Z5L1mTk/txh
srUY94+wOf18hBh4+4HhBO6wk6N0Ck/Y8A09hTvOeLftBBfKI7/epOdRxJfL
NExIPpZ0trpziZAs3f4ioVHupvvT1jjOxWdL9yBQPfCbmbS0l/u0LneKYhOC
7TC7N1lQ/3++UpZFJnwcv+KdWq/ir19qJE+69870z7B+ebE7Ibh8y3vRwiVq
1RAYuYy7mgxd6AkZtPR+fCb3nd1SUz1FS8isLxhzwBlfcQeCul/+asayjtEd
0xx67Fm49dvYtJyz8QabdtfMtM6gnmyNx1txJyKvYYMUGLKf3mhOj0/dthDh
htsSoseREH8C66pDImt9Fm2vJ9vQ9RnlHEMKYx5xDnNPLHNoC8kbKb67ziZu
69J0MivHBtNju+lia2Bb/9uhbMdPFDV1/w1QVn1APWEYX4igBvoBlkbO7hvf
WOZdJ7R2OJASI7MWSnI2Z9ZIAqQHdZJQJSYb7fnm+fHzN79gGcjWWC5KieOe
SUBAhUgKGSfa/MNH/YcNE3TWYeAdVVs+16Of9qKutd2bEmbTsb26YdUsF3oU
va1uO1/hviqLdHe2tZC1t1bLqvmNR7cRubX63F/z3vrL2V6mv51B9ApHupzQ
5xF9l4QGd3+cCBH7P2yco9eTKqKYG0o+E7ykIsDQfaXZP3Muu4PPFPeD4wku
dvSA73i1w+v4GZc7v8t1jVIUvrP2Oq/BYqklwu5YKdqY1hHxzlR152ZRJRcU
7RlX0M71D3YNiQZ+j/KMy2LK2BMbMT8PxUgaBgMZHxZJh6l0O44iBhaX4DFs
AReyCeujpAGwNcnbEhHYg8ExR2NTyQgqSlrALHjM5WSyqqRJ3Dw7y5t8kTZe
nJVuGTn3l40dGdpozwrOaYxBcs3ZrSG+NiSVfa8ciMol2b6glLCULrtVNeHh
3coJw8iSrk/F9TEDjwvxTs7TCo4sqzCYYWKGxWroNR+bK8ePJZtLqhroyqTD
vPTkeHCHgsWcyasFvEGbdwV2M1vUO8htq9mxVoeF03m6sN4puYR4luPDvsFf
5EWOuNQgRh1i81wMGHYVjIOMdX/Q8YmQGb8qR3ShkXtgKCg5aX31WfHA2qdc
sgYMys21fO5aWterBfvGiCBQk2xuSrxqRuVs5JJ1poAalBbibjrdmiB9H/cD
mCPWDMvlJSdImGb3OVv34cQlJbvCD7Fq37hc6Stl8YZL7Zv9m4ZUBVUIX8D+
5Lo4zbNL+rUnXluUMBFrRjQJEtJcBK0p7SNVttDj1aoSS0NyRvBQ1+1gLDUO
gGZ1LsLT6PUgVkTZaXgjIsCgxJG+MDtkiiCGczopU2VODeA4jkiAcF5gq/Va
qsync0YwAJ6JkcEBfGVIZ+WXvU2lYhjsBrFhPHhnfO34HOc6nlCYc7cyjebm
+Ke0qIwrJxM8wUW4orVY2A0VhDth1fGwLFY351B6x1PLocRl1Mu+37WjYsP4
mPDqh3Wt8czsa+wVCXTsnq9D6d6XUpOv13Ag8bycnJvU/1fJhvVTOs2yU9KE
z3G7BeNhJ6mDhx5qgUZEVBXB4inYQ/sthXoF1VKCeE19Fu5cXkm96dw1NejU
ULr1WqnDhy41tdCJNK+jdhALLoIh3nqW5NLCdSUkwdHigQMsr0KeiIzON1eb
3LywnXovMqrBSzGlsgHqYOxSxmutcmMl3AUWcKVQ7aIDoLEKzu4V6tSB+AVo
XK6qiSRQl4T7pLPxrQJ4UiF8cvfzCJyc6/FcwloYX12JeFfY7BRksUIhZqmx
yeNsFQNYI1JzrUPtlNiBDAOO8SkP6gbEa9kGJUytOBqpY+srJ3th+uaA7ixY
vnKbGKPxlaS1+dJUS2Y351rfNlJfQPf3nKvUBkXzopmfQ1PmVHdCz1DTWxOO
rZXue8LO63IQFg2yLCgee+G4KWsHkj4W1geK7YMq7kZgRsvXOI21CTSt0KxW
9sxJZwtBafkQnu70o0G/w3avKDtPgBBAjRw+RGyZLrLjVQmsAvWF42La68wK
++bVJKkuWFIdu1Qkufz+jr6FF2ynMyKaMTA6/TokOsgEmyhNHraf1wRNhqaY
r+to0aqaWu/5ZfUAOr4k0S37pCOXARCpTSXy4kDrjtgSidFR6iipiS5L5GT6
puVGZD08UgcOHYj1kEwt3QENRY7mvrpVuIxkkXGoQKaomNzk0LDZHg7LZTd7
FmBNf1wFwCxp3D7LLqK3B0cufduxWzfkzeTi828ISmSj3fllelWrauY/6apn
7afXqWgm/tIpa7VW9vnb6mq4CtyOdJuSXr46J3Z/wrAVF6bYKtFjz8eXWAkq
CvD4Gpc4A6JPxYCXKRX8ccKWrzfX0tq47AWnrO/WV4uXqCL5yFAui0y4W0it
ovbJwBd/XKV1PopoYKxdtd4YdmKFx4Nua5ChFC29oKDGIjtL8fdhKy7YheDe
UjuNhK+2y1CZoun4Z7tYgOnw0KOmwUuiqXFnuyQGgr+BkvkMuO0MWxyRWcPp
B3nQR12ieFNpaHoKx9it1KXKvJSi97Ug4rJl3kjHIWcIa5xVp5Umy6npKAGL
hx3003zec8T8sG/8ZAYMCnE1reCqnsCqIRvUaL6yxO482JtPNOVLvGOLdCoG
4vYWudjE9CItJpkL1iUDrcckXhm1ntYuLfWEqwFl01ttQjtIdjaDNXiupBpu
J16MbbMc5SsmXKBVIxlkXk7ej+omWzrBJSCCem3CRqLV39ZKcBpWzsu1eseh
+3qbw88/X82+Wbcftp80BQC1pKYrukXNvuBQqDUoVRfb+f2rz1Ha16v/bi3t
sr836Pwxs9FdrQSfpWVb9U11bDwC1BLbVir5OLrWr6nj6/ydLfYs6/8dFR0r
MAoV0/xG7ryxRRU4L6mcZEuhG95en6eWf+3GiLY1W4QOwMWe2+K9PdXGIpXE
EhOaW0gSo+9NKIWj4NjEgNT24AcqrNSJZ/ZM19sq15Gi9k69Ck/i1NxI1hOb
q2W2Vr3WccLqAraiqy/dFfRg6RonpDLlbc0TSfJrGCj+utaC+B2jljYoWbal
lQCBuKkCXQpfsE/azGnFNu0r4hxv2PiRz9gUyUHJR038sIoaxA8U/Qb3FmmD
KhRPjjfeXni66jyNYGs2vTdMOOV5pk1C6XoAzJn7naLy3VyFthLab81hiPe6
Et+9ZAnCSkYVsaRSdNMyuIVyCyJQWYcwo7cjPTKAeJApjlfEAS0Z9waAxYSe
U17HPbeOga4DHYg5CL2c0NzxblCQsXuYTzeN8xEWJ8TWgQX6TYgAieAF3dxV
aNnxz0jZ37yVRtYKS6YenV6HUFk3LIrP7a0LZ6CIWjpDwHuPH0mFbWGajR0e
aNr3SQEWfu+tT1FI4aMurZlB5WReBzELjJbwGisYFxZ36sIt9fyHirZ2Rfgo
tDDZrncj4aZFhA8k+JBf8/Ld9ttYFVGYCGvDNveUZHcDdO4EGa5a60HjLGuO
GeldJ9ueQqlHxPDFq0JLkt307r+BvJBL9Rm0BmGzD18+4Gtu7sZjT64i1eiC
om5/b1uO2CvD5qMdTMeV2QeoP8SIKgfGfMJerPckyxFOZE1tjaWJ6BS3hql4
Y0Oi4QkQ2UFaVJuhSRIV9sv8q5wfiuyo9aOiMxTodah86BvuEdVvnCo+NsKJ
C/tTDb8UxF0xGXZ9nPqVtn31sivWCVqnQji3Iwgn2IWD4KPRdKkl32oChj/Y
evX5TpJeL0nMgB3WtoooOyT7cHJQIP8wD6VqDIus48I4/vn125f7Gj1slGiG
pCYc4fMEIOKirmc7jRtaDrguapVhxCoWrGGZJ+Tjbe+GMD7Mu14UqKBINfbc
tEJeE/Kr5XdF5vEqf0wrV7pjYxDm+SwjTV5tDAYCLQnExFV39uBakKvZUyq5
yq7aCjZcCId3gmu55LoLFnK5gK5arpxVewthlKlYs/sq3QcnFVGQ107UdfCH
p99GQ+mqcFtB9PMG8030/EjmdO4aeWDscIaFyGULqFyi3tKDfv1lmNyjZkVA
kkCHu0dBHPWttXHdUjlr4Z5SBleYAklz22zoLWW30I5iVp9+J2unVHvvmf09
64AhNNjqH6IxN69uFXDhB43VvxiQ2oYv3EsnCAISpFll87pjH1d1pCXslA5C
w1C7DKLcdM7tLpj/IS5FGKPBRSHQ7YveIkSWCrE07dtj9nFpjC1zRideStCz
++ZFtMQjZ7PzXQLXwumLJncENOBTpJMHMb2tK4qAKluhWNGK+oNQOVotpygM
4GNSTbmjJbczYzgrK1q90sudXSG7w5WwR04zCnpcxj3+N5xHR+FjbMdxeqwU
nQO9y5Y70Ri66CCiQkhmzIXoMxI0eoEde50DvxM0nQ6zHpbrwjE6ivMN90CN
LvjeSPldW9eL1FvoNHuLtuh04BlKzk13M+agJ8DPitFqueaIv8Iio7Uf1i9U
LGZ3wUbH0eMvPDUJLB4hOreJdce1hMq2B+DbDEthlGUtOBVn6K0peuyUvDLJ
NYc6dAuzORD6VPI0q7XLcMv8Y+kikUPfqRbG6NCxdVShwwS95IdCq6UKNzKZ
/wqwiV/UYDe/JjgIc9p64d8eKnfFmC+HKagpV8p01172O0B2++8KsvIcRdmp
NBg0lgzG6RwBLWENi7rNEWUGtPy866F5E9P8O+BoHcz5r83VWsu9mSUFON4v
OcvGv0hmu43+ETGE8MzO+tk/1l3pz1hGOrC1G+FgJuUCm8BRHNGyXK7mvifu
9jfU0jEKBiOkr9nvTarO7Zjg7ZSdz1tARNZpXdtboNWtVNcvI623V13/1iD9
G13CqK74lS5hZJS4RBgy7P4r2rqMX4/CBFPeVmVcqyB6hriGc+K2B/K403V/
Pc52C7x0T8qBWJbS4n3jr7Xw23G6m5GaHJg9cS2fQ+NU32vtmzS9W2SE3NUy
13ulb148VcZ13SF7wONiK8OLPLXXmCLkA6cepa+zh8pGbawTYum+dLyTnWHd
CxTB2hF8Y3N42/Mtxr9NHkmM4AaprmU1oABkNx+Vk8CmCx3n7vpTCr2gLm5G
/Z7mZee4ccJaGJXY8jB+fpKJyzIpi9Fz8reaPBP9LJ5pEr5xu6T6oBQDWUY5
x4QzCzXBhNqFcWSzhk1yFjoNJPUQPjtz4655G+E+b5e5EbwTy93wYaHD5HTV
E9KzzAoMCKSqIZRvaMIPmVJwI0RXzEEbQYLkT5GQ9yTf08Q/d8MA6wW+JCGY
GBFsaVClIZWaaE99vYBKOB3SrJFDV9MwwH2ZwwGZgE6feIRNS6UcCNHTk8hw
EqMuS42uCI3+VXQt4ctCd6Nj6AjdL0ApXXFvOR9y2+mMp26snlZ0GFian62w
aokcOSu+WGakXgLUXdynIMpYZ0CmoRkbpvWg8+7Z6ONW0gSs89iV0z/BT2Cw
siC0VJx3pEKrRPkiSjcXf7Y/vkOYr3ZJP5HqlPRj+X/fz/XXWs3ghIqD0nIe
w3+P4L+dhOpaJVtrPuMNyF+PrqWEBAzk631v+Qrf7rNt8xmMSeWrdr5P6K8f
RteAPy3sqc9oJrPmVl2q1vFpZaow2c3EQVBZTkK0DjHSZhqmYNUlUtOsKFdn
EgWQY0/7dHHKOEuimKSOEHtJT+tyvmo6TaZPzmMJR1wZUbG57s0xo8bOSigR
O/mOdCI+x4NXpQkBk2IHvSltNJKMqpvjSvntTCCvYESjnH0eVt1OJiMmvT4n
iztgIvB8sKRJdarZ+3xK9VrWZzp1s5w0OdiNtTZhi8QOXEndYJMBtFnYzcWK
zdxm0qDeDB5FTxIUt6xn3s55VdMM5Lclsq1ZWp9TtI6F/5qwHp81TBliZJHo
xgC2SsP3jLtee2oF+WAq5FD8tdw/w7QoNyNh/3LMt0QZJQgbGQrT0pS5lqWu
m0E39FzOQdIZTc3u2lmHtLqbtpwXkgA0kzXhOf+XyVbrr2fz+Zlqnr9vSBqK
yy+mFAs2Qtt0DNMzjAS23LiL1+fobHbyzMLsuHd9uXH/nUV3uyy6Ed5+J9t5
Adc3bWJCE6/GwXJQTHf3bTmNJkTX99OnTW/97EidUhrJyIyhjB2Xq5MDuRKT
1JvN2tJoF+Uu8wnLxW4qEtL/O7MwzCzsaLR8jl+UcHhD7d7PzjnELu30VlhC
C8fLpkER0JrJCQ5tSEAr8BbFEYozDTPPhAmAJMC2t5b8uLHz+8PN5NtgXEld
r4iWdKoNB3VGfTBczFITCersjToFVSh+cdtKlyReSh2XoLOTKEQHM/mTNF2X
sBmQCcbpyHyulpgeROMbb55mVsdz1ZKkX1GnBMqV53HzdJLFw8F8XZjpH9IJ
2dRKsQ6QiW/YrsoEw/bWYhp66whH7HazK2H4Szbi1yjejFlrWteN27EY4dI9
Db9vrnN0qzxMdzEpiJJJohMP0pbcKnmx6zGnS/MwMdbyZO/wCbNg77iU/Wwp
5lPR4Z3IEjKsTv2SAMJsv2Aht29rwwS74xHip3gVKomUJ0lmxBgreEXFWvFZ
LtAWYYAMw7V9ZL8YhMHmWxi5Nt0UzaptRFMiN2RNqTzL+KLQ3bB9wxWz6ja1
bzd0vmEBqW24HAHTugHmed2g7llWXpt1gjJb88Q9UAv16TmlUdfJQFTTCe6Y
RiByuyRb5+i3xk4urGJ/zhLHzOPZfDQUyaVczackntDyvc9Ae2lHbFTPObd6
wXEt4SKkqcJtPSt0NTqJmjH+Yx68IWMT4+lvyAUTR/jaRLAimgi2RngopvC9
sVjGIYAqaK+Hmq9faP5Xz5INRzXe2vUrijpHUlrpLTPF/j4j/mPJVpy27HSA
d5G4bjwSD/06Avt4jQPjTbUtZkNSq8C2uYth8l87CkDJwQKgEjpkPQ02zLy3
wl3MD4tbZTNLu2dULD1bNuGNzd+uxzH73A1I5pfnkyDN6+vRO8rhamUc3Kq2
kzkeLcDUQoOxWUJu+B4ff90W/HzZTcl6WxvIgD/NuVQe6hHGE4xmkDLkxdQ1
nf1i4jEedOI9viaC6Pb8EfWQwv/6x967BDo6off8cxuqzz9f4fg6oTqtRTI5
uguwPgNQA4FQoXwkkgZ9990NrAOMnCdELDgbFyk8KVOLkiQsdtQtS1gfuqdt
qf00Wmw/rLXvWpE5e0N5ml0xONrdFHqLn7ZtFHonPv13vu9/5/v+DfJ9GYaf
le+7ZszPTvtdN+ZfLaP3v/Nr/xbSdsfsEAZaGUfYJdO1Tk2XYZijqUZCuGxn
JEi6b97RH84iFS8HbYOf8VEAGbHqIX6YOsudaQbFvHXVKdSmj3ZTD/tTNfhm
cuugU9MVPh7mI6QUfd6FusmdtKW0mdzOQcwrF0idYlud4myV1+cUtuWsiOwz
w1LB3HqdiCJpvhJIfYI2F21jD/SuvPCFZwkEew/3gRyeztOrgIbaTcRBlX2Y
UP83DVWqRZPWN5GtB54T6ihun7C+PDa/M8+rUtSBnVYxm6dn45aEFNh8/WEF
yCWMKheYm9AplHMOZtwkyYMjsAaaIruKpMgXrE3UlAn0cUTIXM5RyqrGAKmv
eJDfBmvBqexaOs4vtr/l/ZsU75iNXHKuK95AssZLRgt67Q8kwFk9FxPIimLy
CcGskZ4tTsaTq8OKwrcd5OOjhhf4FPVQh/q4i0uBBZ7poj1myWOdO5VyQeOI
hci822dyIEG412FpDRKONnKsizAqDRAhFhe0qnYsa9lT2Ry55iBR9tSsqiLp
BE5jyPIl8JGRq/VH8k7E0DRUK4eEuvj8G2tRZRz33Lpv1vP87DyYVhNSbIEf
6manWw1NJTdM0SlgOLiVeRXDbPJqslrUDVc4VoPrIG1HR1mjEr7H11rmDZRo
DQbkcCm+hLCBYKKxdFGIxGxHZA2ylKZ13FGHYsSMA4Ruan2QtsZlBaI5tzkB
rlxJtD+AP/yMysyTeoJd9WDTcHUYR7ubCvtyOM32bbTc4A1V/m8wYNKYn9eb
4A5x4P3zvy6ipyQsEbf5lUPS+5fyxnRx6PoSu4FZaWg2drFHevN9fFNH5MVn
Cej2qQ4M+KkJ93xsg4Hfoyh+h2Q9foXOyjgNphtXdgMy57aw3Dhui+C4/a9u
i3DHfQtrBBMcrTeAVYjI0UwCvtWKovPCiqLmFTRxOClkkRYptydIPt6XDz9p
ECxKgamzK4EKpaGBcLtYICEDxlUDZI0fgg+z+czHa3GzvkIK+NM0QDCovUAN
Kw4j4M0B1RQEecrveqekFNQ9UDH6isCITS3pXUBsYN0g/QRNY7iLK0yPv1Ch
Ut+dVELyXTnfjZn1m9HONvmW0gTOpOZCBKipwZhbIqs4wa1FmZz7tXOjmWwa
SkMRUQNfa8ULHbR9zxpZuyqMwUVCovDIX2vvlnoEh/rp0yZx6kgXBqbPgXWm
O5tr6RwGorRf1Tnw4GUeDvsAlBgnr7U/RDfyMK2y2yzsGM8u/vZtukVIEP2u
SlEb2fhsPCRzydHFE/l08+bo+NjP75MNK0z6QS7uMIhOiN1sltIKvf3zIP5q
NAQfOzzzPS4XqOqSg7RnV/LkPqZN+2e/fAWdzd3m5/fhawdolmjFfEX30EpJ
CHD4gbueHsVojf90/XmLvE42HN/57PMmftVz1L2gjsDaHfWLAEp9+7lW+cKJ
CdGjvtsKdE/08/vb7Z+fDV+9zSG4Z8NXH7hTR9EzfuQP4q/e5UdeVSC0Q10i
8xowOVyRIMhb/KgcqDRMM09CKh+0RHfNu9Ci6oxVnXVhwsmaSPK22h00KlQe
tQAFr8FY0hURXypRhrrrPOPkWFdkHWNn8SbrKsgA1aTvJdIu4SSKTngMB4fT
/IGrILC6kR3BOglcH/Ytknc6dBDZC9F9FHDe7h9JD/VaW2yLkRWjbFiaiDys
VkhyAkgpbNcw/EpFGKWo0hUqyP9ES7JE3rIGBYM/pJlkBkuOyWJJ6ZUSradf
4gss193nZQKu8CZxfRzm1P0cx5unID55OxAM35STco7BaXVGYWrSoQu+vCdv
35PXVb8i5ikvBokmWBgTmT4oK7Uk4hhOiyGfhTNRD5OTXySWAtn2k2Fy+Bp/
uceulnskCO/t79JnWLILxZ97ZssnVToDsTmZgKJZ68ZFUNzPZ7PjrLqQhTvp
9AJkQFYgam+CPS1Bq6rzqQY+v6B39ul4l03pAjjJ66H+OA1fw12gWjbgRPUM
VBgeWLIdsJYk2UXv4f4ott9sBzeIiqQzfYiI8nzvlbdRSQke3zEMZDtM1mSV
BPu4Y7ytw70Ct4KGkWk7zpHTfaXxu4lbfoot2F7DjfMjXpEbruQWb4J0bDQn
4OA+XASAi6zlZrVJ5JDJycAHjfI9RkLmE7IlalLIa4MLigKJooD5ip53uED2
W5LwVyBAVQwz7Q/PK60YJk0qnZbodDAt9jQjGySnvMp2CXvdxl4eP6uj29Gt
CM1xvnCYBVVERgBeEW61tb3D42cbHzYTg98wEcVu4LHPVoVkMeMp8BlStimh
qS2A8dy3EmZDVsLoAl/t0Np9xhE/dU59A2uHFCg4C+GGd+GN8AVcMoa7GyLL
1+8F6l9ESFrXbua/8IcOZGEMWIELdyT6T1lVfuZlEyDyCLe6XdHFuSNc1tlq
Wo7gdk3LhfqUJ5Oy0jiGjx/fvNh78vjR958+De3qfm3c7l12sDpCfvbEp2dV
Jn0HCeLUDIVe5zIDGaFnXp+L7645J/ehdQ3YvQ4+mxYyDtFypiPqM3IXYnj/
vvMtvWR/oGNqDjOF2GXz3CmO5+1sO9Grqf5BkQHBrN6z0OAsHRXpPqtGWvI4
OtZyR4ZkrQ2RFhrc4rjvyayj3317j2s+JK8w9/RnI2K44+9889djZnZqOUB8
E/Yn78EJ6HFqXilu0Xxr+bZxE4UXJ+8D7GddnGR3DmS9oFab2CkyTdQ7PkLR
jgTMdF6zG52LP8AB/Fwuk5c5JtwaCYrh7ax2Lj3IUUdTAAv7Li6x7ESy8XbJ
xH0KR8Kf7F9ukuzzdjlEesspYpU4g0GawdcvpYqD7Vy4n104yCrWDo1cTD0R
57JVx+bGaphm/8c5jMAv7V9qKwbPVQ7QWgvXI6nKFdsrJR9ZGrtShs6soqaz
DTbkOCHxSkptwOtUUAh2v7F/sKn3kuKPMMTDuzkZMV2NjppkDjl5BAtdZc+3
n9KviCdx5DCnj18z+js+H2KrQZQItppvLba6xe1LR1CPIfCGJTxBpnBBH0qE
y3Y3nPIUxQtuxgWbw2facm8Sl3s5xADTvCXv/wokhYoO2COPkY5BVSIVRLAV
tJxdkoyevCzfHQFFJEr/+MfHj5Grtd6gFDVAZurhUpKs+eTxCGOfMRNZBvwH
MpI7PyWoAPkHidzwHxN2zVDVO5iiPRxeBUw5ONjfJFJcZ6pQeZphlKfkpGTm
JCVhRMck0sVaigt0a2HXUBxxkpZHBkNdgOo+eQU4DyNt4C3Der5Lubds4pZH
uIMv1UZi5ybTww0OZML3gNTCeZLqvSl9ogme8oSoivqIQCqDA3mGa6Z7aLLW
ZvnZqrLdANMlqFrA4JGD67vjhNv5qeuAuLzE6q6f1d3QIv/jih+rGyo5Jfvb
A14AdF9UNWpap7GogLByroMbZzExCTan9HNvozBDOnnK72/Ysg7POe1ElEyG
nKfMgpm6CmIGowVAFfHHo92q1gbF7Vc1rgCzbxyYTn6JbSgYvHdj8r1ebO+J
4rtAer1hlkoIjYjRndkSj8iUoWR5E4rC/fSatLsc+DG38NboGgyRIPFKSAc3
UeCLD88KqqGUhV6a1cSV47T1GeD88CRcBAyPyNdMhK42Fn4RKGBDsLh7uKl7
sCv8nRhmpFDWJTFp4klVusg4MdXrTJ6kAD2Ihj/DXGNQ1nkak9urRafqdnNH
oMk/bD35jjSNRgOJMNivzitSLdEWsMrnU3c2dI44OgYglP7M5EhAHOL8VNIB
gFI4wWHF0YaA1NgWNQpnucW16rbufQd2NjoG7Phut1rdq7AD8QqJn9XgUnsl
JMbBVp1LFl/+WtdxgJVhEPAkI56TDy9x8dEHFEZtrChs7VoK4xRnKF6NZJZd
qqO0D4mNACOWg6VJBoa5Yps6PH7WuxVQ4XEHL1CL0S7p5iZqMhHnFDfALWkL
/tr9GvetTXoYY4HFZAWJTKEVdlpOVqSeOi1H68uRsgZfTdnIjesmu6vhAPGR
eVa04fZxLQzhgfm/SNigCXCkv77MESq1LhryEleg0XNiK3WLRi0FdZNhsi9a
yiZZE7hMQlvuIMbE8/h6cWzChsfgCiBUVFlBVkGAYE+4uO9PnbCDsjrLjP4h
IneBUs+zta9+8MpXECjkwHCXYgREWzneXAp26KGD7Zt6w6pucWPVitm2H/sa
hcPErSYtwvjT3Oau9Utbn0cNvWm6tVNREygH6kISpISInPwaZAPv17xlD8rs
p8b5sqJgBV+AUiKHMK7266wutODI6vbQtVuvFmIf+HgfPpzIZ5/8cvUj77Gj
UB/KAy2rK5aQiJTNqGBG3QxUtJXSlBVXEcHwKski+P9QcNjZ2vqfUmomLzj4
cOj8NJL/hcHpuAhqVtKsiiKbw62cpMsay6XjWoD3DbKCcBxtrCO3XKq3OQv1
DsKHDYoDFJYMpHSTQjpdZGAxfViaiMWxX2xCYUFVxupsAeMPgtCpyPwAfKZA
crL0fquwxQAuBop283yifJripBZqqCFyXRNxJDgjQPYBN85AymP9YfDvMLU7
0PoerfnJj4+eIIBVhRbTmPUx0mM7P+z8TxYfdEmafIczDdyGQiOmOOSUmZVc
q63KRg6h5YlpZp7hGDpxNgw4PupslVYpaEhi1uzEexKn0mom2EeCLeAicg92
/fEazyXXVau59G7qMlnaBaYR3YCD1MFeMNWQnx9Y65bZBoGHAFG7JTo46R20
Gx+4Nu9kvsUq65IoBJoG0wMNomMmjLWbkXWz06cpB+1pMCYwX+TztGKrocSX
uSUe7v7bwBupggXKIbCc3TkDH0aL3GngISawUt907GiI5obH061L9XWJ2UFh
XBhD3hvBIgzHEQ1iaOpE8Bdv9o4HgC87LPy6mj8ixtVSz9YfhYGCC4az1+Qf
XB0X3rE2J/YnQ6UupB2LN5wMwmUty1wcgJ071PO+BI1VPmSGxuAIzbwbZBtW
9qP0qktJor2kShyzvBW+l7vQv8OTt+Rv6VwMtFYDd8XQDFl7kcSxkEISCQM5
ZD1zoPSMyVsuc43uC8oB4bYlEIOug1iqg5gEVolqLY4p2rGH9NCHv6JYX5/T
3iVhzZWfzOv3HIwMR5HOOTYE4L4qBB2EW3Os50BE2KImfsM3jIbCUBLaAZb1
RZ5IQwIvzan9h8ttJc4/4IZhfE0RmURMcvfYW4NApQPukTfsDW5+FZEmOdh9
tYv2NvLXs1bT1oI4vZf4HCYEwij4Ese3ZJMVE95gBBA74Jtw1E9kasA9cfVS
MjW8BrS6yLNLtDVwJC89IsW0CDf8QXIyVblETtA1lADtpXAfFkr8EO59DK7h
xS7gNq2qrNZa/j7wBkgNqmbp/OpPKms2SLixrLa+3ZzDbWyEm7ryNhgKWk5X
E+L85IWVNaIDdOpy9piIGe96nolu2AdKV2nHsPiHQcAk29JA4joLw80HL7Pm
GywZC2glHalTqiOK3xLFUWuORP/POkOwd7oVo1liCgiPzdWudMWMyBhu5Y1W
mqUryoJe8bSJzeb07bBoqOSxp448WvchaUIU4uROmomtXHpMBJ1ocrtZEFlw
4TbkEkjCT/ue3qB30vPlbCZCZFgFigFQUGMCt/3WHK1SL7IPLWNGC0/eqY0d
LmotUWdTVwtVL6HL0jFWzKUj+divpsT0Be99CqPX4X/OXEJam2fQsi9NxtWY
CQAjjikK43m04V3kcWIbBLJRvAIY14Kx7rDGcBlAlgkgGVeALLU/iJhfLYDV
1YT6iQQCVavMR3OxV35IrOWlz9i1nGZoS0aHyxei6Mw5KtgaiLNplCFKjkdU
ZCLRyg5nUUolFkkXDGv4Z1eIwBr82AMTNb7ZE3EHwVCgF1u1A0QOJ4QKnSc+
v2maXeSTTDdylhVk5azTWeaJ4DB2v/U2FGgYZfFf0A5jVXiNNsURU2uOdvd+
+/yEi0JuGDROfZond8H6bmtLxDJAOVoU2oSyWbqaN+q72vNCu0zHVWlrsolN
M3IMo9oIwDtbodkNgxonFVGs91nBQftLTTzyp8UBJ2w2kFRcKcJQkx4rBNGd
IRdnqJNnb57v7v3MbtE3B4fP2QXNjyEdKecXVG7yD4jaeNoVnG2FsREkQbAL
89wtiVyUpzUyP2EMsEBMmoW/JtG9M/fndzLO0PDMiQpTz+ak8xDNETXaKjqt
FRHNQyAhYc4KQwVcvg/otGjeYbh6UKSGFSKsh2wNQD7nujg42HDVhjNO5CPL
FY0Gx/yMk4YrUEqG3ThZFKpqCdC1Ua+I9/Zv0bjaF4htpaghcuQdso0iyM+z
SAH/5lOpnEoVah1hmsJFmqKqwMbHATbTiQE4DMx1JIEPlW+BhDJ063DyWZpT
JzGVgZUu+Iqzdc6ZV9VzEvM8ssbJqXb+VlhnlwTi+fPkYxx4eoKLOlfJBv0+
lNdSl54V2PDsCChNe3M8tDYyDfLa7y/GEoKI6+4WhEEhj5qc55mUEeCoVTX5
2CCZQgzypfdoOzlZYsDoMyMccxwYTRMa/TnkpgZOQtIT5yvnkcr8ATjFKUOx
5wEohOB56uuvfaSznYkOIwmvK1EfHXF5DUyoA6GaW9a8OBKPNMN1Cx9tB7PU
UkJ0RfXgrgzuBsg94HqypmLTNLJ0LhYnHXza20hdtFVrO+PBy/x9xg7ntOaA
QV8h9hiGgEPxu8JAPnOKWttTi7WEMX0E+oHflHFpCI6m75V0gY4lHkbXjHQO
C8NEspJrCfQfDMfpReq7qg10KM9PWQQIKYdWUGAoiuvVqwuoCcKOKVGTy13C
HtHaykE4C45/n9kxWIgSbZaCMb3plz1MZG5KohahRYZUK68Xgb1hYjR5ExCu
flwSbKRUgDMbmsqzIc5Quil7Deq8WYnSEyKg2Q4PbOLLkRqvllIRiTPYbqlP
BTlLD31SEl/IZys8Y6q6U13wxWeO9kValW/m7fSqN74zFeWgoAWarLLaHxAE
x761PLWuhUqpC4kI+lK9RBaq5DiQsLURbag2obZPHmUMoeJBhmKucIJ6vNxW
7Wq7yEHg9ZlrhyZnwJKFoZtrMlkt0eoz1QpgwYOY61+uGszhnAik5SNJ/RbT
iYM9Qq2Ce6c8Kl1I07QpC7qUyE6pxPjiCmQl1ORZUphmBWr5JUYDVCg2y7Ax
zRKxk1KMXTOIzvYkNWhSssFkgQnpzJJUZkSaUmBlbseSjF7AY6jM1KCo3RBm
jAfPyGIpRiMcXro2BVAggwTXcKBrayUZlzAGE7kNxJKg22pFa4viioVNVMlZ
pYwvdtQbGISqMQbU9cCVyAYxYpP3QgU7Kr8toRR6CgcKFXL0kW2axCzKekYl
BgauTI8fNsywK5kjU7VeWrDVTk2TsGxPq4KfLa5zns2X6lvX5ietjDzfc8f2
I9KDQszie7XIqXQh1SwYiV5GllwNKefzR5pBhRI65s6HBua16uQgGqAbAX/B
NrkZu0RSQKNi5N0RIVmarshh1dBtgQfyJd8P7QyGcZ8r6l7GVDcoJ19jgTki
fLhvAz46XlggO3G8gGYrjGUGMeMtEEQx5Il9s9VfnygjmgPWAjSwkj/RZxxQ
yqdy6jdNrCZLnescr3daeLqJcuSqkCoLEj+RuVpzwTXX3lCN1gLtXTRudl6W
71lIwbPmpky12Y8WU5kDokyvIlgfozQn7OEpEl9OrGUaDFO9LCs2TKBVX0w0
ZzKWKCTUnE9Ww1MT3FYvy3LW2XJFaMV0m+qnqYEGUWmenXU7Vq2QENTc7sHs
c4XxUlhfk1tmUjBMt1OjFGhsoQA17kL/ak7hxbhyyVrA1B20LQBcpcYFO1GX
WcMRNb6xjpafePHwDfk8w11TdR6WZpGvSotxtBmJNX9rKNmslZr3MjtP2AVI
yqs7wxqnXALmLFunMc2oMDuraGifObvSqKVy1kYTDtUHJBBToTfNnMI3l/m0
OR+HPk2zOyni2tqByw1zBSGoCFJQ12yBZ2JNUPiijpiH+6aE0+qMy37UmbXo
1UbPBdLKnQ/gqk7VLTTjsopLNmEZ6ZHCTZyPuuuOEHoVJsaTtg2YRnfnaokp
o684KSg5KFgHLovBi7aPkw1VOLW1+HhrS8nh/uiZoIZ9aWRUMQZqbucMxKdL
GGEztBtcKjCq7A+utYx1F6rmrRYvd1bIlCWe2RNy0vsvq7xxIfaX52XdrsE6
F8Ghf9GNRsURn8Bfzkrd7VhbJz58E/EekZmEzoqKytExccgZuyiKcs20reFq
rLTaDZd94dSzQwYAaqha2NIRTapjUwT7zBGubFZFhk92TcRVdnIMRO7S3Jih
j5VxflOXTIdkVkxRuXcwv/rpnbbzParyi3SCdvSaArrqupzk3tVMSwz1fLdq
dbsg7po6q01pDjpoA+hk74B975Vw36pCa3BiWUU2lJDGSgPndD3IvKsVXzV8
Qls3qE0ZdMdpPmETjLQI9L3esLZtXEUZYu0wrhwwz6RGDyYueth4uxjFH9GW
qtRVd0oVN9JJVdbS2Rgv+8/lZUbJNbdCxqDSoUPKv0PsOvF59yQDuWrfPJYL
uKCkkinTLlDKh3BGvqS57xwH97GiOCzfsXzkPas+5+0i56BrF/Sn+yCv9G7I
fsmhnVKv6BKrpwBGL89T2JHE4wDSbw6Ogc3l5V/+vHu2Qlb1lz+/KReY3TvY
B8l/+pc/P5sDEgwHe2mF/U/gb7RFFgV8nwHjSM/hk2pVYBfk4eBZlafwCDy7
zLhl+REowjnIOPDhHMbDj3YBsnUKH5To4hoOYD58aR92P88vcd4CdgsfrCYY
xgPjZ3O0tsA3eXZW4hd/KC+KbDh4DnpdNYVPDlB6qP/y5+O0mJxnf4Ix0/MV
DPEv6RRUEVhXVvwhhSP6y59/m05XsJvdCmMd0tPzFX5UTFO4tlfDwTE6x2FH
v63g8Auc8jCv/gBL+O0qO59nWE4PBsM0hL/8+WWWn6ZDB76XsJk/4VorwFiY
ANS+Iv/Lnw/T6n15Ub/Pcd/ZhwxePMzmRQ4fDgc/ZSW+DAs/SpfptFwCEypr
fjJFSQ++APoCT+6dgxCBOzzKKriRNe79jA4rXfAbF2kFq3iTNWkBq9qdpgs8
SSAKsMTzEgSIHMHzPkW4/QuwouU5/o2px7DvoxQ0RIDXyfkKFHEJsnle5ZO/
/PmXqwLox4AyLOsMhE4xi7esS8MEaxZnl1LqkczGVDtsjxae/ARI9SdfTm7G
DsGco51cKdwl2tzO4WHAbq5etnEILBMQr8pLmDiBE5+kE4pX2AMNflWlyVWy
zxX1N50YgGPhHmFy6uua/aFERR2G29s93v7u4dbWo0dP2CwiMz9/s//C53p2
l6Ejw7VG8SA5eb63s7X9ZPT9jz/+8MPoaJwAmWUjH7f+wfJYpysOq+JC2wnR
Jt8OVZqsoU1HjEBSaPaKhSW86KSB1pPzEu2UoqjssWGxSl6iSswxqxpZWORU
MoRjDffSxWmVT1H6G2DRHOy7ijTCOpueazW9j/eD2iaDVlWWs5xEHvSa1RNg
D3AadcwJ4symzl398O3+EdtLzspUSSwcyQoLxzWsW/nCfKwUSKMoN1h/cICr
WofhpplwNYyE54jGxSnWUaNlpxyQypZQuPyFym4Aj90j32/S9HCqMha5alfF
gtU9Nf9gAAiJZMZgITzSVPkjq8oAYIPziP3+JaYlvyyRCLdzP8WTz3VNt3ce
0SfbO4/bMf7DxPuONC+4xiCJKa9JDZIpz0uWUc6hFjMLiy9TsnXyHcDRN3iB
PP13T354xPkRP83LU13sLi/WpOchU3n69OBg/+GTx8xBG/h7G/7idVEpUgsp
0FRR7AjOhCc22X+0BAl2HwpwTZKcgZsmGcLoZ+li4eYecGLfMdpCPn3S6uN1
4JTAGzd5Pw6rDUmbDn5eJcVpSbb+OVVWd2nkdWZivBlPnEtIe9SnUyBeLOZw
Pank0ONHQrHPthrYg9hvA6ybRUdJJbTcbwJKrSd2fa3vdX4bAJGi3cHP2P12
7T68Hoxv+KERCFA0Qve3eE2zsGpaIu3uf+7WW8I1SHkwyuSOFKDrKZvWmSIR
4fLlTphTeKsRXB0wSRMCeS8sBEYY5cp/5WxDgAM/UqTiBxDVXx6NYB1U9gtI
DJGiSAQf+x3kEor51AncB/tS75Jb+tnt+PQUqQSZoQcUQx1Qa6OUQdKYpaRX
SsmljlgZMqQ3KXCX7D3cV4wdkHd0C0BzLPGeGuml7vgmJb/kqjAXgItr/fLE
eTl5mO3B/23vyZbbOJJ8x1eUZyIYhBrgAKQui4IjdMYqVqK8JCVOhMNmNMEm
iTUOGg2Q4rjlb5lvmS/bvOrsKhyU5LFn1RZNAp11ZeVVWVWZ9Xh2mfMvpH4P
OMvMNFWylfuvf9p/qnr5unr5ffX8VaXe03INvqyA4TCCK/yB2k/2nKsKQ8LN
MLpcLShd5fwzX1H4ty3440nfkGRV/YB+qR+rNcfkAzpjIl56L3HDsIG7quqq
6umgum97IvlQKqV3eqknJlgeV2KicMF3D3UlHVsJHwVfUgkFG3pN8W+q7c4t
K5FjavRd975U4iDWDEcfVLsTqcSJh2KH032wXk9sGAkHJ9v37q2H2OLqe9Y4
qrp/Vyp5+eJh59Ej0Dsr9oQvQvN3ppIYTlzAsBIwBD69J3I/2u8J6NAVEZv1
gidz/tmvgj/og3xCsqdLQIBX3OXx6QSNoBWnGCtBlMQqubtOJQ7B3o5ivQsq
t6zkcyC2wXJ6+zNLXDuIUNoqV9h6cvLfKGyTw/kqbP+cwvYHWnOAiNMRRVTl
3pylSrpqCbGdFSInf1RS2AP+HSX2D7hiwtFU6eFsLxuOQUm1dDjLcAIoqZx3
C3CS0h2dTmcVOvnSugNXsDKK2+uONSv5T9MdO191x1fdsSLpfknd8e5ybd1R
r+T5dXQ49vgzV/JwmQLSwnbV4Xw53UEerzV68geX2A8fbHcEJxiot7vdrCg0
rsYU9uTuMom9ZiX/ORLbD1cvJw/ETyWh5ThwDDqk/KhnTkD13I+Zro/yO5dG
jZe8Qxdn+ni2gQ550A544CHi86v5eXBTw8bjcjxGkmLpxvMLyj2QJ5J4Wt81
cbeLORpOt73DUazYc6sPcMbCzrMTn7mt/fyVE7/+jO+cmcvh+uZ/g9vYhjbw
UNg5u8SN654rpCMu4ksfFvlUB84xDmocstRd9ieX5mCRc/mOta7FSsl7+07w
F/S33dXJeRrhWRtnUwdf6I8fgz0dGxJAw2vnH0bkwdNeZ/bY2dDE3MKTYWV4
b927PSiRek+nOR7SKVvqKZ3fkog1F3iihzEwmPruQjz0jQNiwpR+t9+Nuflh
AURqd44YsV74T6h1b4LZlzhYySRMq0Nkx7l1ukGiK4zpyKlLu4hXOothvPWO
f1FySLgeR/PPZI1QluvFboC6ex1tRLgJUL5C3BIC33dVhvEuFEHQQQgnFsoj
nXDMFN18MT5tmunyRWWd2LTYdCiqVScblKNC7zY0l2aoltpTm+GdMZNMt4nU
tuNk0+D8a/jeyKIHWyE3HA3G7b3J60lZtvegXyuwRO1cZ50x/KAYMEg6MCkn
MHXuSbyWEaQ5dA8b9h5IJDU1xEPsYYbgz8NJR71OCzHUu5+iCwNxbynE3aUQ
O0shtpdCdJdCdHyITUAhzFkzUqC7dPDdpYPvLhq8ef2AWWs1xoKij9ttPrRL
NTwD1oTaK/zDZ7841wVErVkvciLZ0uYisowTobV5dLv7xRDbPp1cU7tt7MEf
jqP4IEJ9PGWMq1SSrX43nvr7Z+CpJXWszlP69f17d3e2u50EyXaQZDtMsmys
POp2O/Bf91Okx7btQ8Da9OGL83cdiSrkbxXl77N8MJxPi0X83dH83Wk5GIMn
hrFA5PwOAiXG2J8sVWIsSBv7JFQAYaZ5t4n2+3z65vAdiBU0fUu6TOSurj5V
uDQe7HjCBYjDlyLbD1vqTW+bZMnOQjlCTzRLWig8Qkp/oKf2rmSVxuVXCnhn
DeDut+sA3xOi94CR62xgkWaqbHeNhh6oNYB3VgLuroPJ7jqY7K6Dya7F5OrA
K6Guuw7quhZ1a0/o9jqY3F6GyZ/qwBaTXbnLKbBVBPbhGrAPErCRDnfvJ2DL
COy9BOwoAns3AZtHYHf07DiwkckZRopuJ5rRsAZyRxZ5yxRVIUojqtN9NWUf
UljOgxVN43Jl6cR0liDwdQR2JwG7HYFNYUyFA0/r5/iDSMCK3sT5L9roYUQY
pWDfRSRGCjYiAzop2Coc+PZKA+/QgOXppljRzMwiW+V9tAehpVI3U5aYCgsM
FQ5+j3k6D99tGd+Df2xZR7RUJ3jKrcAoLnyH5H9hUaPjRrpXkf/iSLa/GOOi
hf5LCtJkAynQKUWZBgwtg25J+H524YYxs4v+p9zWtHBtHDnLq60WPjMrh+Hp
AuxsMuNwBNv3AkOFS9Jp4m/lJi/eqqZ79VOduntvMiseyS0ae9kR4xtx6h65
BjgtziXjE913BFw7EbV1iDGxepr0hq68Osna6tnjt3TALxPGg5KNM+TZsPgg
yR3rPk7HXsVZ57XwiitRucH7mdehYkvupH080fXnV69OwqujxfTCJadRQnFR
uPq6UC1aXv6bXD/4x9LVmqV+Vwo6JL6eC6hc7PRZ0+fzZTgtwWRruX3+EGz3
1fGzQHz8bqy/pktoRb7/FJfQH88nFHMJ3ULGpFl0JanTfg2WTPvJ5xc+96Xz
jVvIngWjkvSCcnkbrbobyWrP4Q76fMEbjcIFW0DmiTqaYtKqzmARbqgDRRii
DhThiTrQzipAEeGlGaxzKwZTaamx2O0aHWWCy+LNxgX37UpvJ0vXOTw25AiT
q3X5XDgtye6GYb44tz/903B7y1yHlmulOh4NAX9l56/svCI7/729gJ11WMP6
wV4uXu8LV6QDHnFf5NPvJkmefpokcTlpLenx7EtLj5iEkCiNC8WENghsSFQ/
bhkVzM/zwbguOL5Kjv83ksPFi3D+78D3EVwpcQX/SSyXZ8vlzYrcZ/erTatv
8g/YKIz480uX7YdrGCfhvvVdtkCuY4d5brNpndyITgLUFvIhQDfk9RCg5gVM
7W8nAR4uA3iwDKAmJFPbW0mAmssjtZGVBFiGyW7NsxMCdJag+lu1pIaHywAe
LAO4vwzg3jKAu8sAdpYBbC8D6C4D6NQBVPRxAFIbq47PzNlg8/ZTo4NYZbYD
gKVdiD+1FsKzE0mAJMl2FwzCbp1213Gj1zdwa8pjgd6wEjypJ6wgvtUJp/CK
ASX0VG8wB8WYLxocvJEcq37UFspkoEYa0OS1IHFt0tGJoGZvmwlmqG9GmJBA
tWsILdqY8y6C+Cexz2iztXzUqFudyrtxk/lRYTIFczaYLeKO8MG4M8xetbpX
r2BvotgAWK2ILsM8sGKZSBW1J7N4iAK6F5EIplJvcKvX+goXNeO2WKnH2Mxv
kWdBn81kfUeVofp3Kqag0cb62aRZaS7EgTt053rVijO37GkEn6GbHBJLuhh5
vxoeUrWjJOip7poFrwRzulsZ5hJ13vuXzpZUnm6KJunF3nP74VbVrNQbX17u
TUAuvgHBcYCCR6I3sSjyBJq5CCV3P7AIicGIELH90RyzN5nxVY5EbzPNMRGS
r+HJlGc2wejXr8aYdO4KheAhrKGmQZn9Z++J9h0m9jviELhGW8VXTzYQUP6U
DgTzU+GZYUoD1QeqxQ/X0wnIWQF2uqbqizj8oR6rFx8utyIQV5EGGz7ushrE
VYO/4mMypEozH+UZ3TmNi2SXGKvEzAaKIkFT+/0rTVN64fEJVOVIoOANWBN7
rw4tGoDXvwGls8F5fpF3y1oJ/3dM1qY6gAjPmPKAZ0Q3ZdQMytVmHWVgnWnK
qbBzbQB5hlch1bA/PD4ZOZ2pcMqRpPmNrgvl9Sj/ILegAChzL8Fm8VnKvgsi
VSTCvAnYgZnzlASSNjNptLJ9C7AtQzESnUGjOBbQEPNhFyxKpICDo0qJlL6G
H5mIHFgWFJyG5ZeZedVtkiSvnNr32VtwzOzotOK9SOJGz1+jAlK/Osau9HrU
ow0fAPU+d7zXmyIoDKkGkojHBzg3SI43T2in2r/pTftXbUtcjSpO5F7RqIKF
ogeYaTfAUNDqk9msGF3OMk/vXDWqfp3Q9Uv+qWE00zqhUV0Td/XGxYfZ8bW2
AjORYPoiuNcioJ+mO0XsoVr0OeTNgJKlRcReZgsf5WIGB4VZxUDLeNzXRPtG
EqgMsGOW+srMsHJtfrDl78JuZ5k/G6A+vBppADrJjSUXwhijjv+MqNy00McW
eL5/olPg1bRAW2ET5/2miVryjgrOWSXKS3ySgwjfrVQY5W+E4LDws+OTwazX
6zpM5RZOR7rMGsy5THI9IbcNt7Ci3BsjJhIRdWXNWh1PrCi0JVMqJv79b79B
SYrdyDfYQjxFjzX965+6I3V+tR1RYWAFi0AB0jFltEWaPbbcIwCpGrRAkMlR
31E6WNDtx/sv/ufdi4NDz3wWy+pIozqqC36r25c0x4q1Dpa54uXOE0yI5MCG
Yhanv+dbLhEs+guNjM9Nvdjff7uvScx/bNNKhXgJw08AItgHsaq57XgtjHFE
NTaMUQ04uO4ZcZOJmKLf17Dk2XOEUYLaDGnQTx35B0bXkoHjTLSIcFWJqEkt
BLTZkFlj312yBhJaDumB9SgzQiLwjnry9O3+YSOuHqmUEBKXIjumSnGKVTPa
nuEFuVMAkdtxsEvvflKAVNRH8ALDwQBQw4RaiqM2rnhNqTKCXXxnprSnqD0W
SLYxNmtCC7JyDUsHuP7odwzkkJAZmAA1qjhXmlpsM8FYMhYYFdvL1xpvhFhb
aHCmR0H5myqtH2LNuk15o/dLubhD1I1Pk6i4gq+vTMEa9ixeNkRaZb3MqM/M
s0TZ/OeGPDxlosDFcsgeZ273Tde0vmb2pa8ocBS/ZjAmSocDoGLjH3P5RBcw
XdDWvrMItLqTYUsHpXrRy7NG6HG++jCLInTDLoCpBH+eYo6VAL5GTVVc8oet
BNiGUnH8+4+DbSpRx32SSdKmuDJOApd7bMlUlVRyw3MVeM+VzGTmM6UuGRMm
jlGMkqwKK+eSMUnjdRQJM5RfUjIUNVySCPqFWLjh1CQkdWDO+jRre5t4zAIU
qBcwRBOwYYlu0fpMj5XuL4a0Zkp6ODfUyyW1cvXQYUrGJkaUa6I33gI0NjOZ
6zyLloxoAaWloS+payUTGCLGdUSRU5KxncRQlRhrcu0pvWMRzCssf6RQMo4a
erQkJo+7bcKWjBGtjNJW8jg78AAXRsNnymXDuDbYBWsX5fvsHgfVYmRJflxL
R3/3akzxv2jjyGmCMqyjW42TH5ojVLXjHwecMdIAaOOyP5/SJpJYFklTqb7M
INFcM2pX9/fFzNqUJ9kujevv9BTEMG+8govKye/lHkOnJ0ZrxsmZC5IzAMOW
YbQ3yWeIrZElRBMC2D8+ch2Hu41Urdo4Z+9hGwGpdK+zq12Dx+Qa3DWAyDY/
EFCLYJ+OLn+k+tkfo1/B18fjH3WxK2fQDDeFlRPA0FvP5+gu+u7ceYorvMO3
x+hDTDNBVvNjMP55LOivAoRsNGKV+gUO/L0SGQyPheuBv5ezcdgPb/qTyitV
2qOBRWaFWQ25eKQhZNmuUzLiWKV5Mm5Vd6L8Ca0boe7jL/O8viLZCLnsmrFV
LjEJxVizwKNjMk+bu1Iq9pZdr7u1VgNvhbRac74u0KZqsX/HlbZYke9QkSTi
aGdxRZVLlRseiX2jSYyNo5He5g23eKWiOEv7kAssO7cicauUQCjqqMe4jVRU
1tw/u36PbChfrzSNtdc7GqsNrijgLEsZvPB3FP4V/f+Ho3EcR0LebmNm/W11
uPL8M/jZpdoUS9Z2OnmU4giWzw7mkgoeKyKL9gOpSV2ROIWVS3xHiKTkhkqi
R0Qjm0dN16NmCbI+B1l8aFoNsVKsokhHIeM4XTLPR5ewWCs0jSvTW7KTI4XE
5Nxk0siMU5B/stTAnrx+3e602VXs4EQjNXSskl8VcLXAXPUrqOvhSqkEj/sl
l2zy7Ik796URwD42Ynj0YSLs6MBsToumOWTgiEg7vgWaLDMwNfR48suDietL
wYpmlLjr1kOGmP9nw/y813v731zemQC3NwktxLQkjluH9eso0/Tlu2/xWzYG
aja19oMSN2r/ree6Th/Y8FuhwTjW7mRc4M76Oj5cE7RCm7ucOdmPfTUe3myp
VzMdE3eMWUUxmZ2ksnPjKnA+WC9SBp8g+/iRAzJw6Fov2gOmFpXMcvYA2dl0
MqJe4jkzjkSLWVy3kvZ47SDQniTY1dauDnRTLxpa3T5RxODZgjenNrTRSybP
pkfG2npe1NWqvBn3e52FqzQGJBBZeN8BMhehzFqszSKPfjciA9GaWyvbCk8q
6mMBIGzcfpPhT5klrui/xYvIzNGWtEGq0lvFQcm2OEs6Gy/nw6GHuoY7JfCw
K+bOY64FF3XawVjVGXw1nZzhCRRt4poTO8czkoVSTU3QI+v2nDW+TKRn73oj
0N5RUjKbR+MmVclT8JP6yUAF8yRbuwxXuVMNM08kAyRnCiObAd9tWq3bNI1U
GwqxG1Bmanya2HRRorWKj00coy48prMTK5WOEaCZICoboeRq81lT3KE0ojo/
1Rs2GJGG9aSqGE/qKjbGk+OzOmKgODBG5TcUYaOIZ8k/++JPTNhGvXTFR6P+
pqrVsKu8/f9K7/YtK31lTGQhRN3zzO95/bF8rnfMNp8b19dPaYZp222GD9JX
B6xK8UmGJ7K1mcuq3ZwZ8wsGc6NqO57BaYwlbOP13TccF6M2fO6wx0zRQgTd
GJtPmptPI2exIg+iNs17CphEMw+S/nedSBXCV994YuM7q2lCpNXLs9ygWlzu
oedo3JsMMdPrD2gWECMdNX/cVbHaa9p0GeITla+EuUT9uzj6druxpA6aMnJ3
vrvEVLDqLQZS2Fi5ZdYhnmnPE/aiWdPd3wSL5WqZoctPVK87T1LqMmoADSQa
yWyhfuy6pcv6oYWoeSCmmNRtKbsKWbobCHg20L8B29zg3Gf8BF9HBkxrUX+M
aanbemZPl1f6EHVAJIsZPPNlihYHC9bbZiuK+hraNLHatVFBG2bmeDKXqmOx
J1gUZcKbSD66bfE0IqU4G5FmeqRkCpndpi2ZJLzFQ9aTsWjGdletwjzWq0JF
NQ1GjCApSmAWn8aa8FvInE0Q/GIJF5LbOm7GaOR5fqUFZrNDUEvPQNsnOA2d
WjCutz9SWzI2/qqvlU7zUTErpnjLCL+hL2rJTIaDUhJ7D8ZnvJSk7Nsm4Qel
Jdc5T2x6Fz8V801brztNOhO8aHoHelXOMCHLCCqdY0aWfl7i9aPT4nI4uaFr
JmW/GGPelJLgOQGfvsJEI8mnMGxoajaf5kNVDCUD+2SMyZNNXxyoAmt6gglg
SmoBKmOYgX+dDBpCyPeSteVyMgNoTMDTv8jH42KIqetPB7wW1ji3Qza3sOhY
f3k54cCQGM5nNMJV9imlu4HGdU5oKvHyb/vJKbi0c2ZmQCaAE1Eb/Eu8RMKx
ThfEKW4o8CQMb1S0FKaZP21jfMdTTMetg2DKN1IOZkOS40BXKVUPh4vUGXl0
9dBj56Y0NjzKPwxG85FkJ+JkHdTv8mIyH55i4Mgp9h1RMi5n0zntBp/cMEI4
l7ROVbSJ2vV7oOgXh3SLubmlDopC/frrQdF/BqWB+MQt8fEjjfr7/BTx/cjL
EfJ6Wx1Npqdq84wifwLtxXKGU1jJa+riCaYLP7mZFbvsCcE04z5wjolGmtgi
dHhAfYUZwZmlUfi39kYFks6gHCG6wVLaUq/O1I3GqGYNNcKAovr23SO2gO7U
bultlk2do3ysri8G/QvmHh2J8yTH3D9EQGAW1Wi2qevVE0h7f6XKAeHnYyYs
ui5I99EHxJ+6COeB6hcctdJQB6ZcITw9P8zP1eZh09459BppQZfOCly3YykC
xkxWzo1F3VA5v6T0TFgPcucUY6dC34Sk3Fv0LezwNZJX8QEZVVfhXH1vqTOJ
+CoMhNPE+9alBo+M5gioLz2UW1WJF8k291KV6oI0mlH+c0EePra6/AgEub8n
jxEcTkFcAOHPB+UFRbTdLIlPwJbFkAdY8uPH5la6iW66CXZQtnnhmmgn1ohm
QfTzUnXD8wmI2YsRzyvghFO3EZO0akhp4eG+iLMRZF4+H87Us/1nO9tb6imw
KYg0GML8koOr/KOYTtBrOZWwtYb9WiI1TbYt09V9L6YuXwRTp3OWLUkagP6B
YhoO+pzgaGKVE4hzog5df3jJ7HPWHS5A5KLPp1R8B6G01ESpiHIWCX3Mgo+m
MyLoAJRFE3dBxO8ly2Rmg80OTky3iTma2IvNMe8aJ0U/Ry6qlZBavCuedFF5
MO4P5471wZfpDEVhijutESmAMCtLGMFpMUQtRrQALUEN+dlMx9qjYY1A/+Tn
QbwOxCjWD/IYhSDR2nDSB8tgWpzPh+IeN2TH2i0foFUyGF1OSh3nuNATQAVI
bb0as5KJ6aUcE/1NyV4pwBZEq4oDSRPY4Jc5XkMHwTMmge9HGCk5wCA0Xg5w
ugdgg5wOwGqEL3nMMKXzy1pJyjoHk8+58fKryeDUGkJQ9mJwfiFoFOTHO0Dx
TJwYJk5ok1bDEp5NjCeWLU7XZTFF0zPRQ0RLOeHfZng8JKzlcmaaxyYapgmS
1rJJYsgKbOytxsEcZj/WEnbmpNAncewsAoOIzoUuwgcUxTpPIpt+JTFYHowS
VGh+WSLBANkPkKWg8PfP33HfpsUvc9ppNJU2FYnLej9IJBJ6MPgATEYx1fbR
k/Jm9BpGou0i/x6/Y1E6xqTOvUgMZQx2oWZifjKRcLPnZD7jbaYC4y6AATlE
QmisuAYwto2b4lHyaZaScRIWFoh8NCnrsJw6EgHPkSUIkbjCYbMBRzgCDTHA
jTG5ioO6iHWwL7F+/esbgDwajA8QAJZBLwHEOWEmn/R6qoWczEsNRB7OyORy
hvjTJkuu0BHqN4y1RDu0pWhYQAkzDNdAodPPipyIucVMwCsszQwkeKDFwWjw
DxEfSmGXTcD6HGqbnvvNi+ENUzyXvJB+6lCHBkqgfyRgIluuydoxFPJiS/3X
5Lq4Mv3F+QhANA1TpRiMHuPQi+0GBAREiP3UgeadnuogiXNMmgq9niI787W3
lib/cn4GxDQgXp4Y/Fiex5OOc6RSOhYgXQZ7O04RFKOepw71lruyQXs4H/IS
zMUm28SExdxsrMZM0y2kSYeWcGze4hz6+MscZrt9MjgdTHndB9oEJRAuzy0P
cyiQRVWxKapXlajJcWR+vYCr2aQ/GQL/wZhu9CyhhAYCOIEBwChApxlLawqk
WBajkyGrgZkTjoQyuB7EVZaZlNjgQCuOC7GFWo1r3C+mNAVx/WG6slfMrifT
n0FRQg940TinTAdj1nAzsGXV5TDvFw0+UbxIu2kB/ry4glEcIRXPS5twAZCH
DO3GbvBVV2l7SzF6oa4yPlqaStZ0VvqWg9lcFoZA0iA8y+IRmWWms8ayJ24p
XV2p7X1tochQJARMXzN6OZvDdALVos0zIH0fKmowHGDNISuwOH6BxfMByVOm
dl+3E9fMx5yB4RBnkohuhOeNiUqhb7xA5Yy2RX4K5tLPNGmobtCqQBtcMge7
VpEa0SSe2MwagNP5lNwYgiNBQInBfy7QCvi5KC7b+RDsh1ZD3DJhrSAboP1a
3azh0i04FhgZpPosxFbDiEImARw+ht8UkxVofTadDPkjYICUFcgKmkg/1UXD
M7gokzHZl2miErOijRTYPptMgjMeSFrXOQvJHB1PjrkFBO4DI8wprvdoU73N
LgQ/z4jnewMixHQkQM/hMRQJSDQHC6Ukt05xAcYqql1fr6K8wirY5h/M/Hpa
YMHsv3y23e1++/EjqCFYbyKtExENByek8YGi0QIhjSanTlARrm2HRsLwtZw1
UdQ01creRZfhTh9vW0rnlHGXoenqkVvBxmblBBIISHaKRhG3xflvecsL26LF
ZFOEXS3AoI0mSKGwig+oI63WdqVMzG415rHfVapV1B0fOTOYbcpotUlDnqmF
wz3FlTrOI43TDFMGtJD+Gq/OWglAxzfi2vvG1WGT8iCKJYcPbQPmM6ct34Vr
sU59XDgs+aOs2f7UnRPgnPF5qXHsX6UwawpzpNGvwahEvxgtEqRC58on9zLo
unFbexQwA4EO4tiad4OzaGHZLm3VapAs8doBHpYjCEvepwSISX1ytL1YhRjn
jsA5vowI4dPa+LoAMy9nM027nq09isw4EMvfsdYsU5wWQBnQmdCL0iLPduhk
z62L/ZA2R9xeTuL4onRScueJKzwHw2pm11S5URiBG4rpDJeIRjOgzw7Ez1Rc
6rnaPJmTh+y0GVLahJ3sbhxTGMcpyVlHdwty89B2fTsuRGKIhiAhZvYxjMNn
po8XonGXlwYNMadiYB0feZLIQIktoztepqoDzMy0fESwqBOPtKheyujw2Dxf
wmglUns+pJelNx16ekN5uwWix5UxjBc6uJgSJogons3keO1UlXRlK5oyAlvi
xYq2/Awpo9Ez8IUkWiBng+mo1BESz+bDwD0CzBO04frbRIg0YqrFWw4EKrUk
7xd6DeEN+cyKWUFoo5p8OSI5sEynL2CUJ0UxtkgFMdhnzyCriYlTzwKMwupl
buY0RZOmNYui4Y09iLqJvRMH042TMa3eW5yvR4Gqr3chSqRm6zbSP1oCgBYA
OTU/vyBTDRcShmw9uwNF3SDNf9hXVIQ+dl1Cqqkynh50+VK+Nnc4bLXNwdz6
Ga0x3uOTXlECOM6YRzSGyMGdgf8DoyKqTzpRAgA=

-->

</rfc>