rfc8724xml2.original.xml   rfc8724.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc symrefs="yes"?> <?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<?rfc strict="yes"?> docName="draft-ietf-lpwan-ipv6-static-context-hc-24"
<?rfc compact="yes"?> number="8724" category="std" obsoletes="" updates=""
<?rfc toc="yes"?> submissionType="IETF" consensus='true' xml:lang="en" symRefs="true"
sortRefs="true" tocInclude="true" version="3" >
<rfc ipr="trust200902" docName="draft-ietf-lpwan-ipv6-static-context-hc-24" cate <!-- xml2rfc v2v3 conversion 2.38.0 -->
gory="std">
<front> <front>
<title abbrev="LPWAN SCHC">Static Context Header Compression (SCHC) and frag mentation for LPWAN, application to UDP/IPv6</title>
<title abbrev="LPWAN SCHC">SCHC: Generic Framework for Static Context Header
Compression and Fragmentation</title>
<seriesInfo name="RFC" value="8724"/>
<author initials="A." surname="Minaburo" fullname="Ana Minaburo"> <author initials="A." surname="Minaburo" fullname="Ana Minaburo">
<organization>Acklio</organization> <organization>Acklio</organization>
<address> <address>
<postal> <postal>
<street>1137A avenue des Champs Blancs</street> <street>1137A avenue des Champs Blancs</street>
<city>35510 Cesson-Sevigne Cedex</city> <city>35510 Cesson-Sevigne Cedex</city>
<country>France</country> <country>France</country>
</postal> </postal>
<email>ana@ackl.io</email> <email>ana@ackl.io</email>
</address> </address>
</author> </author>
<author initials="L." surname="Toutain" fullname="Laurent Toutain"> <author initials="L." surname="Toutain" fullname="Laurent Toutain">
<organization>IMT-Atlantique</organization> <organization>IMT Atlantique</organization>
<address> <address>
<postal> <postal>
<street>2 rue de la Chataigneraie</street> <street>CS 17607</street> <street>2 rue de la Chataigneraie</street>
<street>CS 17607</street>
<city>35576 Cesson-Sevigne Cedex</city> <city>35576 Cesson-Sevigne Cedex</city>
<country>France</country> <country>France</country>
</postal> </postal>
<email>Laurent.Toutain@imt-atlantique.fr</email> <email>Laurent.Toutain@imt-atlantique.fr</email>
</address> </address>
</author> </author>
<author initials="C." surname="Gomez" fullname="Carles Gomez"> <author initials="C." surname="Gomez" fullname="Carles Gomez">
<organization>Universitat Politècnica de Catalunya</organization> <organization>Universitat Politecnica de Catalunya</organization>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>08860 Castelldefels</str <street>C/Esteve Terradas, 7</street>
eet> <street>08860 Castelldefels</street>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>carlesgo@entel.upc.edu</email> <email>carlesgo@entel.upc.edu</email>
</address> </address>
</author> </author>
<author initials="D." surname="Barthel" fullname="Dominique Barthel"> <author initials="D." surname="Barthel" fullname="Dominique Barthel">
<organization>Orange Labs</organization> <organization>Orange Labs</organization>
<address> <address>
<postal> <postal>
<street>28 chemin du Vieux Chêne</street> <street>38243 Meylan</street <street>28 chemin du Vieux Chene</street>
> <street>38243 Meylan</street>
<country>France</country> <country>France</country>
</postal> </postal>
<email>dominique.barthel@orange.com</email> <email>dominique.barthel@orange.com</email>
</address> </address>
</author> </author>
<author initials="JC." surname="Zuniga" fullname="Juan Carlos Zuniga"> <author initials="JC." surname="Zuniga" fullname="Juan Carlos Zuniga">
<organization>SIGFOX</organization> <organization>SIGFOX</organization>
<address> <address>
<postal> <postal>
<street>425 rue Jean Rostand</street> <street>Labege 31670</street> <street>425 rue Jean Rostand</street>
<street>31670 Labege</street>
<country>France</country> <country>France</country>
</postal> </postal>
<email>JuanCarlos.Zuniga@sigfox.com</email> <email>JuanCarlos.Zuniga@sigfox.com</email>
</address> </address>
</author> </author>
<date year="2020" month="April"/>
<date year="2019" month="December" day="05"/>
<workgroup>lpwan Working Group</workgroup> <workgroup>lpwan Working Group</workgroup>
<abstract> <keyword>header compression</keyword>
<keyword>compression</keyword>
<t>This document defines the Static Context Header Compression (SCHC) framework, <keyword>fragmentation</keyword>
which provides both a header compression mechanism and an optional fragmentatio <keyword>static context</keyword>
n mechanism. SCHC has been designed for Low Power Wide Area Networks (LPWAN).</t <keyword>rule-based</keyword>
> <keyword>LPWAN</keyword>
<keyword>LPWANs</keyword>
<t>SCHC compression is based on a common static context stored both in the LPWAN <keyword>low power</keyword>
device and in the network infrastructure side. This document defines a generic <keyword>low-power</keyword>
header compression mechanism and its application to compress IPv6/UDP headers.</ <keyword>6LoWPAN</keyword>
t> <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>
<t>This document also specifies an optional fragmentation and reassembly mechani <abstract>
sm. It can be used to support the IPv6 MTU requirement over the LPWAN technologi <t>This document defines the Static Context Header Compression
es. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or w and fragmentation (SCHC) framework, which provides both a header compressi
hen such compression was not possible, still exceed the layer-2 maximum payload on
size.</t> mechanism and an optional fragmentation mechanism. SCHC has been
designed with Low-Power Wide Area Networks (LPWANs) in mind.</t>
<t>The SCHC header compression and fragmentation mechanisms are independent of t <t>SCHC compression is based on a common static context stored both in the
he specific LPWAN technology over which they are used. This document defines gen LPWAN device and in the network infrastructure side. This document defines a ge
eric functionalities and offers flexibility with regard to parameter settings an neric header compression mechanism and its application to compress IPv6/UDP head
d mechanism choices. ers.</t>
<t>This document also specifies an optional fragmentation and
reassembly mechanism. It can be used to support the IPv6 MTU
requirement over the LPWAN technologies. Fragmentation is needed
for IPv6 datagrams that, after SCHC compression or when such
compression was not possible, still exceed the Layer 2 maximum payload siz
e.</t>
<t>The SCHC header compression and fragmentation mechanisms are independen
t of the specific LPWAN technology over which they are used. This document defin
es generic functionalities and offers flexibility with regard to parameter setti
ngs and mechanism choices.
This document standardizes the exchange over the LPWAN between two SCHC entities . 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 gr ouped into profiles, which are specified in other documents. Settings and choices specific to a technology or a product are expected to be gr ouped into profiles, which are specified in other documents.
Data models for the context and profiles are out of scope.</t> Data models for the context and profiles are out of scope.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" numbered="true" toc="default">
<section anchor="Introduction" title="Introduction"> <name>Introduction</name>
<t>This document defines the Static Context Header Compression and fragmen
<t>This document defines the Static Context Header Compression (SCHC) framework, tation (SCHC) framework, which provides both a header compression mechanism and
which provides both a header compression mechanism and an optional fragmentatio an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide
n mechanism. SCHC has been designed for Low Power Wide Area Networks (LPWAN).</t Area Networks (LPWANs) in mind.</t>
> <t>LPWAN technologies impose some strict limitations on traffic. For insta
nce, devices sleep most of the time and may only receive data during short perio
<t>LPWAN technologies impose some strict limitations on traffic. For instance, d ds of time after transmission, in order to preserve battery.
evices sleep most of the time and may only receive data during short periods of LPWAN technologies are also characterized by a greatly reduced data unit and/or
time after transmission, in order to preserve battery. payload size (see <xref target="RFC8376" format="default"/>).</t>
LPWAN technologies are also characterized by a greatly reduced data unit and/or <t>Header compression is needed for efficient Internet connectivity to a n
payload size (see <xref target="RFC8376"/>).</t> ode within an LPWAN. The following properties of LPWANs can be exploited to get
an efficient header compression:</t>
<t>Header compression is needed for efficient Internet connectivity to a node wi <ul spacing="normal">
thin an LPWAN network. The following properties of LPWAN networks can be exploit <li>The network topology is star-oriented, which means that all packets
ed to get an efficient header compression:</t> 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) exchang
<t><list style="symbols"> ing information with LPWAN Application Servers (Apps) through a Network Gateway
<t>The network topology is star-oriented, which means that all packets between (NGW).</li>
the same source-destination pair follow the same path. For the needs of this do <li>Because devices embed built-in applications, the traffic flows to be
cument, the architecture can simply be described as Devices (Dev) exchanging inf compressed are known in advance. Indeed, new applications are less frequently i
ormation with LPWAN Application Servers (App) through a Network Gateway (NGW).</ nstalled in an LPWAN device than they are in a general-purpose computer or smart
t> phone.</li>
<t>Because devices embed built-in applications, the traffic flows to be compre </ul>
ssed are known in advance. Indeed, new applications are less frequently installe <t>SCHC compression uses a Context (a set of Rules) in which information a
d in an LPWAN device, than they are in a general-purpose computer or smartphone. bout header fields is stored. This Context is static: the values of the header f
</t> ields and the actions to do compression/decompression do not change over time. T
</list></t> his avoids the need for complex resynchronization mechanisms.
Indeed, a return path may be more restricted/expensive, or may
<t>SCHC compression uses a Context (a set of Rules) in which information about h sometimes be completely unavailable <xref target="RFC8376" format="default"/>.
eader 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 av
oids the need for complex resynchronization mechanisms.
Indeed, a return path may be more restricted/expensive, sometimes completely una
vailable <xref target="RFC8376"/>.
A compression protocol that relies on feedback is not compatible with the charac teristics of such LPWANs.</t> A compression protocol that relies on feedback is not compatible with the charac teristics of such LPWANs.</t>
<t>In most cases, a small Rule identifier is enough to represent the full
<t>In most cases, a small Rule identifier is enough to represent the full IPv6/U IPv6/UDP headers. The SCHC header compression mechanism is independent of the sp
DP headers. The SCHC header compression mechanism is independent of the specific ecific LPWAN technology over which it is used.</t>
LPWAN technology over which it is used.</t> <t>Furthermore, some LPWAN technologies do not provide a fragmentation fun
ctionality; to support the IPv6 MTU requirement of 1280 bytes <xref target="RFC8
<t>Furthermore, some LPWAN technologies do not provide a fragmentation functiona 200" format="default"/>, they require a fragmentation protocol at the adaptation
lity; to support the IPv6 MTU requirement of 1280 bytes <xref target="RFC8200"/> layer below IPv6.
, they require a fragmentation protocol at the adaptation layer below IPv6. Accordingly, this document defines an optional fragmentation/reassembly mechanis
Accordingly, this document defines an optional fragmentation/reassembly mechanis m to help LPWAN technologies support the IPv6 MTU requirement.</t>
m for LPWAN technologies to support the IPv6 MTU requirement.</t> <t>This document defines generic functionality and offers flexibility with
regard to parameter settings
<t>This document defines generic functionality and offers flexibility with regar
d to parameters settings
and mechanism choices. Technology-specific settings are expected to be grouped i nto Profiles specified in other documents.</t> and mechanism choices. Technology-specific settings are expected to be grouped i nto Profiles specified in other documents.</t>
</section>
</section> <section anchor="requirements-notation" numbered="true" toc="default">
<section anchor="requirements-notation" title="Requirements Notation"> <name>Requirements Notation</name>
<t>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
“OPTIONAL” in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appe RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ar in all capitals, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
<section anchor="LPWAN-Archi" title="LPWAN Architecture"> </t>
</section>
<t>LPWAN network architectures are similar among them, but each LPWAN technology <section anchor="LPWAN-Archi" numbered="true" toc="default">
names architecture elements differently. <name>LPWAN Architecture</name>
In this document, we use terminology from <xref target="RFC8376"/>, <t>LPWAN architectures are similar among them, but each LPWAN technology n
which identifies the following entities in a typical LPWAN network (see <xref ta ames architecture elements differently.
rget="Fig-LPWANarchi"/>):</t> In this document, we use terminology from <xref target="RFC8376" format="default
"/>,
<t>o Devices (Dev) are the end-devices or hosts (e.g., sensors, actuators, etc. which identifies the following entities in a typical LPWAN
). There can be a very high density of devices per radio gateway.</t> (see <xref target="Fig-LPWANarchi" format="default"/>):</t>
<t>o The Radio Gateway (RGW) is the end point of the constrained link.</t>
<t>o The Network Gateway (NGW) is the interconnection node between the Radio Ga
teway and the Internet.</t>
<t>o Application Server (App) is the end point of the application level protoco
l on the Internet side.</t>
<figure title="LPWAN Architecture, simplified from that shown in RFC8376" anchor <ul spacing="normal">
="Fig-LPWANarchi"><artwork><![CDATA[ <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.</li>
<li>The Radio Gateway (RGW) is the endpoint of the constrained link.</li>
<li>The Network Gateway (NGW) is the interconnection node between the Radi
o Gateway and the Internet.</li>
<li>The Application Server (App) is the endpoint of the application-level
protocol on the Internet side.</li></ul>
<figure anchor="Fig-LPWANarchi">
<name>LPWAN Architecture (Simplified from That Shown in RFC 8376)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
() () () | () () () |
() () () () / \ +---------+ () () () () / \ +---------+
() () () () () () / \======| ^ | +-----------+ () () () () () () / \======| ^ | +-----------+
() () () | | <--|--> | |Application| () () () | | <--|--> | |Application|
() () () () / \==========| v |=============| (App) | () () () () / \==========| v |=============| Server |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
Dev RGWs NGW Dev RGWs NGW App]]></artwork>
</figure>
]]></artwork></figure> </section>
<section anchor="Term" numbered="true" toc="default">
</section> <name>Terminology</name>
<section anchor="Term" title="Terminology"> <t>This section defines terminology and abbreviations used in this documen
<t>This section defines the terminology and acronyms used in this document. t.
It extends the terminology of <xref target="RFC8376"/>.</t> It extends the terminology of <xref target="RFC8376" format="default"/>.</t>
<t>The SCHC acronym is pronounced like "sheek" in English (or "chic" in Fr
<t>The SCHC acronym is pronounced like “sheek” in English (or “chic” in French). ench). Therefore, this document writes "a SCHC Packet" instead of "an SCHC Packe
Therefore, this document writes “a SCHC Packet” instead of “an SCHC Packet”.</t t".</t>
> <dl spacing="normal" indent="9">
<t><list style="symbols"> <dt>App:</dt><dd>LPWAN Application Server, as defined by <xref target="R
<t>App: LPWAN Application, as defined by <xref target="RFC8376"/>. An applicat FC8376" format="default"/>. It runs an application sending/receiving packets to/
ion sending/receiving packets to/from the Dev.</t> from the Dev.</dd>
<t>AppIID: Application Interface Identifier. The IID that identifies the appli <dt>AppIID:</dt><dd>Application Interface Identifier. The IID that
cation server interface.</t> identifies the App interface.</dd>
<t>Bi: Bidirectional. Characterizes a Field Descriptor that applies to headers <dt>Compression Residue:</dt><dd>The bits that remain to be sent (beyond
of packets traveling in either direction (Up and Dw, see this glossary).</t> the RuleID itself) after applying the SCHC compression.</dd>
<t>CDA: Compression/Decompression Action. Describes the pair of actions that a <dt>Context:</dt><dd>A set of Rules used to compress/decompress headers,
re performed at the compressor to compress a header field and at the decompresso or to fragment/reassemble a packet.</dd>
r to recover the original value of the header field.</t> <dt>Dev:</dt><dd>Device, as defined by <xref target="RFC8376" format="de
<t>Compression Residue. The bits that remain to be sent (beyond the Rule ID it fault"/>.</dd>
self) after applying the SCHC compression.</t> <dt>DevIID:</dt><dd>Device Interface Identifier. The IID that identifies
<t>Context: A set of Rules used to compress/decompress headers.</t> the Dev interface.</dd>
<t>Dev: Device, as defined by <xref target="RFC8376"/>.</t> <dt>Downlink:</dt><dd>From the App to the Dev.</dd>
<t>DevIID: Device Interface Identifier. The IID that identifies the Dev interf <dt>IID:</dt><dd>Interface Identifier. See the IPv6 addressing architect
ace.</t> ure <xref target="RFC7136" format="default"/>.</dd>
<t>DI: Direction Indicator. This field tells which direction of packet travel <dt>L2:</dt><dd>Layer 2. The immediate lower layer that SCHC interfaces
(Up, Dw or Bi) a Field Description applies to. This allows for asymmetric proces with, for example an underlying LPWAN technology. It does not necessarily corres
sing, using the same Rule.</t> pond to the OSI model definition of Layer 2.</dd>
<t>Dw: Downlink direction for compression/decompression, from SCHC C/D in the <dt>L2 Word:</dt><dd>This is the minimum subdivision of payload data tha
network to SCHC C/D in the Dev.</t> t the L2 will carry. In most L2 technologies, the L2 Word is an octet.
<t>Field Description. A tuple containing identifier, value, matching operator
and actions to be applied to a field.</t>
<t>FID: Field Identifier. This identifies the protocol and field a Field Descr
iption applies to.</t>
<t>FL: Field Length is the length of the original packet header field. It is e
xpressed as a number of bits for header fields 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 pro
tocol specification (such as IPv6 or UDP).</t>
<t>FP: when a Field is expected to appear multiple times in a header, Field Po
sition specifies the occurrence this Field Description applies to
(for example, first uri-path option, second uri-path, etc. in a CoAP header), co
unting 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 targe
t="RFC7136"/>.</t>
<t>L2: Layer two. The immediate lower layer SCHC interfaces with. It is provid
ed 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 that the L2 will c
arry. In most L2 technologies, the L2 Word is an octet.
In bit-oriented radio technologies, the L2 Word might be a single bit. 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> The L2 Word size is assumed to be constant over time for each device.</dd>
<t>MO: Matching Operator. An operator used to match a value contained in a hea
der field with a value contained in a Rule.</t> <dt>Padding:</dt><dd>Extra bits that may be appended by SCHC to a data u
<t>Padding (P). Extra bits that may be appended by SCHC to a data unit that it nit that it passes down to L2 for transmission.
passes to the underlying Layer 2 for transmission. SCHC itself operates on bits, not bytes, and does not have any alignment prerequ
SCHC itself operates on bits, not bytes, and does not have any alignment prerequ isite. See <xref target="Padding" format="default"/>.</dd>
isite. See <xref target="Padding"/>.</t> <dt>Profile:</dt><dd>SCHC offers variations in the way it is operated, w
<t>Profile: SCHC offers variations in the way it is operated, with a number of ith a number of parameters listed in <xref target="SCHCParams" format="default"/
parameters listed in <xref target="SCHCParams"/>. >.
A Profile indicates a particular setting of all these parameters. A Profile indicates a particular setting of all these parameters.
Both ends of a SCHC communication must be provisioned with the same Profile info rmation and with the same set of Rules before the communication starts, Both ends of a SCHC communication must be provisioned with the same Profile info rmation and with the same set of Rules before the communication starts,
so that there is no ambiguity in how they expect to communicate.</t> so that there is no ambiguity in how they expect to communicate.</dd>
<t>Rule: A set of Field Descriptions.</t> <dt>Rule:</dt><dd>Part of the Context that describes how a packet is com
<t>Rule ID (Rule Identifier): An identifier for a Rule. SCHC C/D on both sides pressed/decompressed or fragmented/reassembled.</dd>
share the same Rule ID for a given packet. A set of Rule IDs are used to suppor <dt>RuleID:</dt><dd>Rule Identifier. An identifier for a Rule.</dd>
t SCHC F/R functionality.</t> <dt>SCHC:</dt><dd>Static Context Header Compression and fragmentation (S
<t>SCHC C/D: SCHC Compressor/Decompressor. A mechanism used on both sides, at CHC), a generic framework.</dd>
the Dev and at the network, to achieve Compression/Decompression of headers.</t> <dt>SCHC C/D:</dt><dd>SCHC Compressor/Decompressor, or SCHC Compression/
<t>SCHC F/R: SCHC Fragmentation / Reassembly. A mechanism used on both sides, Decompression. The SCHC entity or mechanism used on both sides, at the Dev and a
at the Dev and at the network, to achieve Fragmentation / Reassembly of SCHC Pac t the network, to achieve compression/decompression of headers.</dd>
kets.</t> <dt>SCHC F/R:</dt><dd>SCHC Fragmenter/Reassembler or SCHC Fragmentation/
<t>SCHC Packet: A packet (e.g., an IPv6 packet) whose header has been compress Reassembly. The SCHC entity or mechanism used on both sides, at the Dev and at t
ed as per the header compression mechanism defined in this document. If the head he network, to achieve fragmentation/reassembly of SCHC Packets.</dd>
er compression process is unable to actually compress the packet header, the pac <dt>SCHC Packet:</dt><dd>A packet (e.g., an IPv6 packet) whose header ha
ket with the uncompressed header is still called a SCHC Packet (in this case, a s been compressed as per the header compression mechanism defined in this docume
Rule ID is used to indicate that the packet header has not been compressed). See nt. If the header compression process is unable to actually compress the packet
<xref target="SCHComp"/> for more details.</t> header, the packet with the uncompressed header is still called a SCHC Packet (i
<t>TV: Target value. A value contained in a Rule that will be matched with the n this case, a RuleID is used to indicate that the packet header has not been co
value of a header field.</t> mpressed). See <xref target="SCHComp" format="default"/> for more details.</dd>
<t>Up: Uplink direction for compression/decompression, from the Dev SCHC C/D t <dt>Uplink:</dt><dd>From the Dev to the App.</dd>
o the network SCHC C/D.</t> </dl>
</list></t> <t>Additional terminology for the optional SCHC F/R is found in <xref targ
et="FragTools" format="default"/>.</t>
<t>Additional terminology for the optional SCHC Fragmentation / Reassembly mecha <t>Additional terminology for SCHC C/D is found in <xref target="schc-cd-r
nism (SCHC F/R) is found in <xref target="FragTools"/>.</t> ules" format="default"/>.</t>
</section>
</section> <section anchor="Overview" numbered="true" toc="default">
<section anchor="Overview" title="SCHC overview"> <name>SCHC Overview</name>
<t>SCHC can be characterized as an adaptation layer between an upper layer
<t>SCHC can be characterized as an adaptation layer between an upper layer (typi (for example, IPv6) and an underlying layer (for example, an LPWAN technology).
cally, IPv6) and an underlying layer (typically, an LPWAN technology). SCHC comprises two sublayers (i.e., the Compression sublayer and the Fragmentati
SCHC comprises two sublayers (i.e. the Compression sublayer and the Fragmentatio on sublayer), as shown in <xref target="Fig-IntroLayers" format="default"/>.</t>
n sublayer), as shown in <xref target="Fig-IntroLayers"/>.</t> <figure anchor="Fig-IntroLayers">
<name>Example of Protocol Stack Comprising IPv6, SCHC, and an LPWAN Tech
<figure title="Protocol stack comprising IPv6, SCHC and an LPWAN technology" anc nology</name>
hor="Fig-IntroLayers"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+----------------+ +----------------+
| IPv6 | | IPv6 |
+- +----------------+ +- +----------------+
| | Compression | | | Compression |
SCHC < +----------------+ SCHC < +----------------+
| | Fragmentation | | | Fragmentation |
+- +----------------+ +- +----------------+
|LPWAN technology| |LPWAN technology|
+----------------+ +----------------+]]></artwork>
</figure>
]]></artwork></figure> <t>Before an upper layer packet (e.g., an IPv6 packet) is transmitted to t
he underlying layer, header compression is first attempted. The resulting packet
<t>Before an upper layer packet (e.g., an IPv6 packet) is transmitted to the und is called a "SCHC Packet", whether or not any compression is performed.
erlying layer, header compression is first attempted. The resulting packet is ca If needed by the underlying layer, the optional SCHC fragmentation <bcp14>MAY</b
lled a SCHC Packet, whether or not any compression is performed. cp14> be applied to the SCHC Packet.
If needed by the underlying layer, the optional SCHC Fragmentation MAY be applie The inverse operations take place at the receiver. This process is illustrated i
d to the SCHC Packet. n <xref target="Fig-Operations" format="default"/>.</t>
The inverse operations take place at the receiver. This process is illustrated i <figure anchor="Fig-Operations">
n <xref target="Fig-Operations"/>.</t> <name>SCHC Operations at the Sender and the Receiver</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="SCHC operations at the Sender and the Receiver" anchor="Fig-Opera
tions"><artwork><![CDATA[
A packet (e.g., an IPv6 packet) A packet (e.g., an IPv6 packet)
| ^ | ^
v | v |
+------------------+ +--------------------+ +------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression | | SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+ +------------------+ +--------------------+
| ^ | ^
| If no fragmentation (*) | | If no fragmentation (*) |
+-------------- SCHC Packet -------------->| +-------------- SCHC Packet -------------->|
| | | |
skipping to change at line 248 skipping to change at line 266
| SCHC Fragmentation | | SCHC Reassembly | | SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| +---------- SCHC ACK (+) -------------+ | | +---------- SCHC ACK (+) -------------+ |
| | | |
+-------------- SCHC Fragments -------------------+ +-------------- SCHC Fragments -------------------+
Sender Receiver Sender Receiver
*: the decision to not use SCHC Fragmentation is left to each Profile. *: the decision not to use SCHC fragmentation is left to each Profile
+: optional, depends on Fragmentation mode. +: optional, depends on Fragmentation mode]]></artwork>
</figure>
]]></artwork></figure> <section anchor="schc-packet-format" numbered="true" toc="default">
<name>SCHC Packet Format</name>
<section anchor="schc-packet-format" title="SCHC Packet format"> <t>The SCHC Packet is composed of the Compressed Header followed by the
payload from the original packet (see <xref target="Fig-SCHCpckt" format="defaul
<t>The SCHC Packet is composed of the Compressed Header followed by the payload t"/>).
from the original packet (see <xref target="Fig-SCHCpckt"/>). The Compressed Header itself is composed of the RuleID and a Compression Residue
The Compressed Header itself is composed of the Rule ID and a Compression Residu , which is the output of compressing the packet header with the Rule identified
e, which is the output of compressing the packet header with that Rule (see <xre by that RuleID (see <xref target="SCHComp" format="default"/>).
f target="SCHComp"/>). The Compression Residue may be empty. Both the RuleID and the Compression Residu
The Compression Residue may be empty. Both the Rule ID and the Compression Resid e potentially have a variable size, and are not necessarily a multiple of bytes
ue potentially have a variable size, and are not necessarily a multiple of bytes in size.</t>
in size.</t> <figure anchor="Fig-SCHCpckt">
<name>SCHC Packet</name>
<figure title="SCHC Packet" anchor="Fig-SCHCpckt"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
|------- Compressed Header -------| |------- Compressed Header -------|
+---------------------------------+--------------------+ +---------------------------------+--------------------+
| Rule ID | Compression Residue | Payload | | RuleID | Compression Residue | Payload |
+---------------------------------+--------------------+ +---------------------------------+--------------------+]]></artwork>
</figure>
]]></artwork></figure> </section>
<section anchor="FunctionalMapping" numbered="true" toc="default">
</section> <name>Functional Mapping</name>
<section anchor="FunctionalMapping" title="Functional mapping"> <t><xref target="Fig-archi" format="default"/> maps the
functional elements of <xref target="Fig-Operations"
<t><xref target="Fig-archi"/> maps the functional elements of <xref target="Fig- format="default"/> onto the LPWAN architecture elements of
Operations"/> onto the LPWAN architecture elements of <xref target="Fig-LPWANarc <xref target="Fig-LPWANarchi" format="default"/>.</t>
hi"/>.</t>
<figure title="Architecture" anchor="Fig-archi"><artwork><![CDATA[ <figure anchor="Fig-archi">
<name>Architectural Mapping</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Dev App Dev App
+----------------+ +----+ +----+ +----+ +----------------+ +----+ +----+ +----+
| App1 App2 App3 | |App1| |App2| |App3| | App1 App2 App3 | |App1| |App2| |App3|
| | | | | | | | | | | | | | | |
| UDP | |UDP | |UDP | |UDP | | UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6| | IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | | | | | | | | | |
|SCHC C/D and F/R| | | | | | | |SCHC C/D and F/R| | | | | | |
+--------+-------+ +----+ +----+ +----+ +--------+-------+ +----+ +----+ +----+
| +---+ +---+ +----+ +----+ . . . | +---+ +---+ +----+ +----+ . . .
+~ |RGW| === |NGW| == |SCHC| == |SCHC|...... Internet .... +~ |RGW| === |NGW| == |SCHC| == |SCHC|..... Internet ....
+---+ +---+ |F/R | |C/D | +---+ +---+ |F/R | |C/D |
+----+ +----+ +----+ +----+]]></artwork>
]]></artwork></figure> </figure>
<t>SCHC C/D and SCHC F/R are located on both sides of the LPWAN transmis
<t>SCHC C/D and SCHC F/R are located on both sides of the LPWAN transmission, he sion, hereafter called the "Dev side" and the "Network Infrastructure side".</t>
reafter called “the Dev side” and “the Network infrastructure side”.</t> <t>The operation in the Uplink direction is as follows. The Device appli
cation uses IPv6 or IPv6/UDP protocols. Before sending the packets, the Dev comp
<t>The operation in the Uplink direction is as follows. The Device application u resses their headers using SCHC C/D;
ses IPv6 or IPv6/UDP protocols. Before sending the packets, the Dev compresses t if the SCHC Packet resulting from the compression needs to be fragmented by SCHC
heir headers using SCHC C/D and, , SCHC F/R is performed (see <xref target="Frag" format="default"/>).
if the SCHC Packet resulting from the compression needs to be fragmented by SCHC The resulting SCHC Fragments are sent to an LPWAN Radio Gateway (RGW), which for
, SCHC F/R is performed (see <xref target="Frag"/>). wards them to a Network Gateway (NGW).
The resulting SCHC Fragments are sent to an LPWAN Radio Gateway (RGW) which forw The NGW sends the data to a SCHC F/R for reassembly (if needed) and then to the
ards them to a Network Gateway (NGW). SCHC C/D for decompression.
The NGW sends the data to a SCHC F/R for re-assembly (if needed) and then to the
SCHC C/D for decompression.
After decompression, the packet can be sent over the Internet After decompression, the packet can be sent over the Internet
to one or several LPWAN Application Servers (App).</t> to one or several Apps.</t>
<t>The SCHC F/R and SCHC C/D on the Network Infrastructure side can
be part of the NGW or located in the Internet as long as a
tunnel is established between them and the NGW.
<t>The SCHC F/R and C/D on the Network infrastructure side can be part of the NG W, or located in the Internet as long as a tunnel is established between them an d the NGW.
For some LPWAN technologies, it may be suitable to locate the SCHC F/R 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 s uch technologies.</t> functionality nearer the NGW, in order to better deal with time constraints of s uch technologies.</t>
<t>The SCHC C/Ds on both sides <bcp14>MUST</bcp14> share the same set of
<t>The SCHC C/Ds on both sides MUST share the same set of Rules. Rules.
So MUST the SCHC F/Rs on both sides.</t> So <bcp14>MUST</bcp14> the SCHC F/Rs on both sides.</t>
<t>The operation in the Downlink direction is similar to that in the Upl
<t>The operation in the Downlink direction is similar to that in the Uplink dire ink direction, only reversing the order in which the architecture elements are t
ction, only reversing the order in which the architecture elements are traversed raversed.</t>
.</t> </section>
</section>
</section> <section anchor="RuleID" numbered="true" toc="default">
</section> <name>RuleID</name>
<section anchor="RuleID" title="Rule ID"> <t>RuleIDs identify the Rules used for compression/decompression or
for fragmentation/reassembly.</t>
<t>Rule IDs identify the Rules used for Compression/Decompression or <t>The scope of the RuleID of a compression/decompression Rule is the link
for Fragmentation/Reassembly.</t> between the SCHC C/D in a given Dev and the corresponding SCHC C/D in the Netwo
rk Infrastructure side.
<t>The scope of the Rule ID of a Compression/Decompression Rule is the link betw The scope of the RuleID of a fragmentation/reassembly Rule is the link between t
een the SCHC C/D in a given Dev and the corresponding SCHC C/D in the Network in he SCHC F/R in a given Dev and the corresponding SCHC F/R in the Network Infrast
frastructure side. ructure side.
The scope of the Rule ID of a Fragmentation/Reassembly Rule is the link between
the SCHC F/R in a given Dev and the corresponding SCHC F/R in the Network infras
tructure side.
If such a link is bidirectional, the scope includes both directions.</t> 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. H
<t>Inside their scopes, Rules for Compression/Decompression and Rules for Fragme ence, multiple Dev instances, which refer to different Contexts, <bcp14>MAY</bcp
ntation/Reassembly share the same Rule ID space.</t> 14> reuse the same RuleID for different Rules.
On the Network Infrastructure side, in order to identify the correct Rule
<t>The size of the Rule IDs is not specified in this document, as it is implemen to be applied to Uplink traffic, the SCHC C/D or SCHC F/R needs to associate the
tation-specific and can vary according to the LPWAN technology and the number of RuleID with the Dev identifier.
Rules, among others. It is defined in Profiles.</t> Similarly, for Downlink traffic, the SCHC C/D or SCHC F/R on the Network I
nfrastructure side first needs to identify the destination Dev before looking fo
<t>The Rule IDs are used:</t> r the appropriate Rule (and associated RuleID) in the Context of that Dev.</t>
<t>Inside their scopes, Rules for compression/decompression and Rules for
<t><list style="symbols"> fragmentation/reassembly share the same RuleID space.</t>
<t>For SCHC C/D, to identify the Rule (i.e., the set of Field Descriptions) th <t>The size of the RuleIDs is not specified in this document,
at is used to compress a packet header. <list style="symbols"> as it is implementation-specific and can vary according to the
<t>At least one Rule ID MUST be allocated to tagging packets for which SCH LPWAN technology and the number of Rules, among other things. It is define
C compression was not possible (i.e., no matching compression Rule was found).</ d in Profiles.</t>
t> <t>The RuleIDs are used:</t>
</list></t> <ul spacing="normal">
<t>In SCHC F/R, to identify the specific mode and settings of F/R for one dire <li>
ction of traffic (Up or Dw). <list style="symbols"> <t>For SCHC C/D, to identify the Rule that is used to compress a packe
<t>When F/R is used for both communication directions, at least two Rule I t header. </t>
D values are needed for F/R, one per direction of traffic. <ul spacing="normal">
This is because F/R may entail control messages flowing in the reverse direction <li>At least one RuleID <bcp14>MUST</bcp14> be allocated to tagging
compared to data traffic.</t> packets for which SCHC compression was not possible (i.e., no matching compressi
</list></t> on Rule was found).</li>
</list></t> </ul>
</li>
</section> <li>
<section anchor="SCHComp" title="Compression/Decompression"> <t>In SCHC F/R, to identify the specific mode and settings of fragment
ation/reassembly for one direction of data traffic (Uplink or Downlink). </t>
<t>Compression with SCHC <ul spacing="normal">
is based on using a set of Rules, called the Context, to compress or decompress <li>When SCHC F/R is used for both communication directions, at leas
headers. SCHC avoids Context synchronization traffic, which consumes considerabl t two RuleID values are needed for fragmentation/reassembly: one per direction o
e bandwidth in other header compression mechanisms such as RoHC <xref target="RF f data traffic.
C5795"/>. Since the content of packets is highly predictable in LPWAN networks, This is because fragmentation/reassembly may entail control messages flowing in
static Contexts can be stored beforehand. The Contexts MUST be stored at both en the reverse direction compared to data traffic.</li>
ds, and they can be learned by a provisioning protocol or by out of band means, </ul>
or they can be pre-provisioned. The way the Contexts are provisioned is out of t </li>
he scope of this document.</t> </ul>
</section>
<section anchor="schc-cd-rules" title="SCHC C/D Rules"> <section anchor="SCHComp" numbered="true" toc="default">
<name>Compression/Decompression</name>
<t>The main idea of the SCHC compression scheme is to transmit the Rule ID to th <t>Compression with SCHC
e other end instead of sending known field values. This Rule ID identifies a Rul is based on using a set of Rules, which constitutes the Context of SCHC C/D, to
e that matches the original packet values. Hence, when a value is known by both compress or
ends, it is only necessary to send the corresponding Rule ID over the LPWAN netw decompress headers. SCHC avoids Context synchronization traffic,
ork. which consumes considerable bandwidth in other header
The manner by which Rules are generated is out of the scope of this document. Th compression mechanisms such as RObust Header Compression (RoHC)
e Rules MAY be changed at run-time but the mechanism is out of scope of this doc <xref target="RFC5795" format="default"/>. Since the content of
ument.</t> packets is highly predictable in LPWANs, static Contexts
can be stored beforehand. The Contexts <bcp14>MUST</bcp14> be
<t>The Context is a set of Rules. stored at both ends, and they can be learned by a provisioning
See <xref target="Fig-ctxt"/> for a high level, abstract representation of the C protocol, by out-of-band means, or by pre-provisioning. The way the Contex
ontext. ts are provisioned is out of the scope of this document.</t>
<section anchor="schc-cd-rules" numbered="true" toc="default">
<name>SCHC C/D Rules</name>
<t>The main idea of the SCHC compression scheme is to transmit the RuleI
D to the other end instead of sending known field values. This 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 RuleID over the LPWAN
.
The manner by which Rules are generated is out of the scope of this document. Th
e Rules <bcp14>MAY</bcp14> be changed at run-time, but the mechanism is out of s
cope of this document.</t>
<t>The SCHC C/D Context is a set of Rules.
See <xref target="Fig-ctxt" format="default"/> for a high-level, abstract repres
entation of the Context.
The formal specification of the representation of the Rules is outside the scope of this document.</t> 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 Descriptors composed of a F
<t>Each Rule itself contains a list of Field Descriptions composed of a Field Id ield Identifier (FID), a Field Length (FL), a Field Position (FP), a Direction I
entifier (FID), a Field Length (FL), a Field Position (FP), a Direction Indicato ndicator (DI), a Target Value (TV), a Matching Operator (MO), and a Compression/
r (DI), a Target Value (TV), a Matching Operator (MO) and a Compression/Decompre Decompression Action (CDA).</t>
ssion Action (CDA).</t> <figure anchor="Fig-ctxt">
<name>A SCHC C/D Context</name>
<figure title="A Compression/Decompression Context" anchor="Fig-ctxt"><artwork>< <artwork name="" type="" align="left" alt=""><![CDATA[
![CDATA[
/-----------------------------------------------------------------\ /-----------------------------------------------------------------\
| Rule N | | Rule N |
/-----------------------------------------------------------------\| /-----------------------------------------------------------------\|
| Rule i || | Rule i ||
/-----------------------------------------------------------------\|| /-----------------------------------------------------------------\||
| (FID) Rule 1 ||| | (FID) Rule 1 |||
|+-------+--+--+--+------------+-----------------+---------------+||| |+-------+--+--+--+------------+-----------------+---------------+|||
||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| ||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 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||||
|+-------+--+--+--+------------+-----------------+---------------+||| |+-------+--+--+--+------------+-----------------+---------------+|||
||... |..|..|..| ... | ... | ... |||| ||... |..|..|..| ... | ... | ... ||||
|+-------+--+--+--+------------+-----------------+---------------+||/ |+-------+--+--+--+------------+-----------------+---------------+||/
||Field N|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 Destinatio
<t>A Rule does not describe how the compressor parses a packet header to find an n Port, or a CoAP URI path option).
d identify each field (e.g., the IPv6 Source Address, the UDP Destination Port o
r a CoAP URI path option).
It is assumed that there is a protocol parser alongside SCHC that is able to ide ntify It is assumed that there is a protocol parser alongside SCHC that is able to ide ntify
all the fields encountered in the headers to be compressed, all the fields encountered in the headers to be compressed,
and to label them with a Field ID. 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> Rules only describe the compression/decompression behavior for each header field , after it has been identified.</t>
<t>In a Rule, the Field Descriptors are listed in the order in which the
<t>In a Rule, the Field Descriptions are listed in the order in which the fields fields appear in the packet header.
appear in the packet header. The Field Descriptors describe the header fields with the following entries:</t>
The Field Descriptions describe the header fields with the following entries:</t <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 proc
<t><list style="symbols"> esses. In the presence of protocol nesting, the Field ID also identifies the nes
<t>Field ID (FID) designates a protocol and field (e.g., UDP Destination Port) ting.</li>
, unambiguously among all protocols that a SCHC compressor processes. In the pre <li>Field Length (FL) represents the length of the original field. It
sence of protocol nesting, the Field ID also identifies the nesting.</t> can be either a fixed value (in bits) if the length is known when the Rule is cr
<t>Field Length (FL) represents the length of the original field. It can be ei eated or a type if the length is variable. The length of a header field is defin
ther a fixed value (in bits) if the length is known when the Rule is created or ed by its own protocol specification (e.g., IPv6 or UDP). If the length is varia
a type if the length is variable. The length of a header field is defined by its ble, the type defines the process to compute the length and its unit (bits, byte
own protocol specification (e.g., IPv6 or UDP). If the length is variable, the s...).</li>
type defines the process to compute the length and its unit (bits, bytes…).</t> <li>Field Position (FP): most often, a field only occurs once in a pac
<t>Field Position (FP): most often, a field only occurs once in a packet heade ket header.
r.
However, some fields may occur multiple times. An example is the uri-path of CoA P. However, some fields may occur multiple times. An example is the uri-path of CoA P.
FP indicates which occurrence this Field Description applies to. FP indicates which occurrence this Field Descriptor applies to.
If FP is not specified in the Field Description, it takes the default value of 1 The default value is 1.
.
The value 1 designates the first occurrence. The value 1 designates the first occurrence.
The value 0 is special. It means “don’t care”, see <xref target="PProcessing"/>. The value 0 is special. It means "don't care", see <xref target="PProcessing" fo
</t> rmat="default"/>.</li>
<t>A Direction Indicator (DI) indicates the packet direction(s) this Field Des <li>
cription applies to. Three values are possible: <list style="symbols"> <t>A Direction Indicator (DI) indicates the packet direction(s) this
<t>UPLINK (Up): this Field Description is only applicable to packets sent Field Descriptor applies to. It allows for asymmetric processing, using the sam
by the Dev to the App,</t> e Rule. Three values are possible: </t>
<t>DOWNLINK (Dw): this Field Description is only applicable to packets sen <dl spacing="normal" newline="false">
t from the App to the Dev,</t> <dt>Up:</dt><dd>this Field Descriptor is only applicable to packet
<t>BIDIRECTIONAL (Bi): this Field Description is applicable to packets tra s traveling Uplink.</dd>
veling both Up and Dw.</t> <dt>Dw:</dt><dd>this Field Descriptor is only applicable to packet
</list></t> s traveling Downlink.</dd>
<t>Target Value (TV) is the value used to match against the packet header fiel <dt>Bi:</dt><dd>this Field Descriptor is applicable to packets tra
d. The Target Value can be a scalar value of any type (integer, strings, etc.) o veling Uplink or Downlink.</dd>
r a more complex structure (array, list, etc.). The types and representations ar </dl>
e out of scope for this document.</t> </li>
<t>Matching Operator (MO) is the operator used to match the Field Value and th <li>Target Value (TV) is the value used to match against the packet he
e Target Value. The Matching Operator may require some parameters. MO is only us ader field. The Target Value can be a scalar value of any type (integer, strings
ed during the compression phase. The set of MOs defined in this document can be , etc.) or a more complex structure (array, list, etc.). The types and represent
found in <xref target="chap-MO"/>.</t> ations are out of scope for this document.</li>
<t>Compression Decompression Action (CDA) describes the compression and decomp <li>Matching Operator (MO) is the operator used to match the field val
ression processes to be performed after the MO is applied. Some CDAs might use p ue and the Target Value. The Matching Operator may require some parameters. The
arameter values for their operation. CDAs are used in both the compression and t set of MOs defined in this document can be found in <xref target="chap-MO" forma
he decompression functions. The set of CDAs defined in this document can be foun t="default"/>.</li>
d in <xref target="chap-CDA"/>.</t> <li>Compression/Decompression Action (CDA) describes the pair of actio
</list></t> ns that are performed at the compressor to compress a header field and at the de
compressor to recover the original value of the header field. Some CDAs might us
</section> e parameter values for their operation. The set of CDAs defined in this document
<section anchor="IDComp" title="Rule ID for SCHC C/D"> can be found in <xref target="chap-CDA" format="default"/>.</li>
</ul>
<t>Rule IDs are sent by the compression function in one side and are received fo </section>
r 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, M
AY 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 ident
ifier.
Similarly, the SCHC Compressor on the Network infrastructure side first identifi
es the destination Dev before looking for the appropriate compression Rule (and
associated Rule ID) in the Context of that Dev.</t>
</section>
<section anchor="PProcessing" title="Packet processing">
<t>The compression/decompression process follows several phases:</t> <section anchor="PProcessing" numbered="true" toc="default">
<name>Packet Processing</name>
<t>The compression/decompression process follows several phases:</t>
<dl spacing="normal">
<t><list style="symbols"> <dt>Compression Rule selection:</dt><dd><t>the general idea is to br
<t>Compression Rule selection: the general idea is to browse the Rule set to f owse the Rule set to find a Rule that has a matching
ind 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. 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"> The detailed algorithm is the following: </t>
<t>The first step is to check the Field Identifiers (FID). <ul spacing="normal">
If any header field of the packet being examined cannot be matched with a Field <li>The first step is to check the FIDs.
Description with the correct FID, the Rule MUST be disregarded. If any header field of the packet being examined cannot be matched with a Field
If any Field Description in the Rule has a FID that cannot be matched to one of Descriptor with the correct FID, the Rule <bcp14>MUST</bcp14> be disregarded.
the header fields of the packet being examined, the Rule MUST be disregarded.</t If any Field Descriptor in the Rule has a FID that cannot be matched to one of t
> he header fields of the packet being examined, the Rule <bcp14>MUST</bcp14> be d
<t>The next step is to match the Field Descriptions by their direction, us isregarded.</li>
ing the Direction Indicator (DI). If any field of the packet header cannot be ma <li>The next step is to match the Field Descriptors by their direc
tched with a Field Description with the correct FID and DI, the Rule MUST be dis tion, using the DI. If any field of the packet header cannot be matched with a F
regarded.</t> ield Descriptor with the correct FID and DI, the Rule <bcp14>MUST</bcp14> be dis
<t>Then the Field Descriptions are further selected according to Field Pos regarded.</li>
ition (FP). If any field of the packet header cannot be matched with a Field Des <li>
cription with the correct FID, DI and FP, the Rule MUST be disregarded. <vs <t>Then, the Field Descriptors are further selected according to
pace blankLines='1'/> FP. If any field of the packet header cannot be matched with a Field Descriptor
The value 0 for FP means “don’t care”, i.e. the comparison of this Field Descrip with the correct FID, DI and FP, the Rule <bcp14>MUST</bcp14> be disregarded.
tion’s FP with </t>
the position of the field of the packet header being compressed returns True, wh <t>
atever that position. The value 0 for FP means "don't care", i.e., the comparison of this Field Descri
FP=0 can be useful to build compression Rules for protocols headers in which ptor'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 R
ules for protocol headers in which
some fields order is irrelevant. An example could be uri-queries in CoAP. 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. 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> Indeed, it may result in decompressed packets having fields ordered differently compared to the original packet.</t>
<t>Once each header field has been associated with a Field Description wit </li>
h matching FID, DI and FP, each packet field’s value is then compared to the cor <li>
responding Target Value (TV) stored in the Rule for that specific field, using t <t>Once each header field has been associated with a Field Descr
he matching operator (MO). iptor with matching FID, DI, and FP, each packet field's value is then compared
If every field in the packet header satisfies the corresponding matching operato to the corresponding TV stored in the Rule for that specific field, using the MO
rs (MO) of a Rule (i.e. all MO results are True), that Rule is valid for use to .
compress the header. If every field in the packet header satisfies the corresponding MOs of a Rule (i
Otherwise, the Rule MUST be disregarded. <vspace blankLines='1'/> .e., all MO results are True), that Rule is valid for use to compress the header
This specification does not prevent multiple Rules from matching the above steps .
and therefore being valid for use. Otherwise, the Rule <bcp14>MUST</bcp14> be disregarded. </t>
<t>
This specification does not prevent multiple Rules from matching the above steps
and, therefore, being valid for use.
Which Rule to use among multiple valid Rules is left to the implementation. 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 d oes not constitute an interoperability issue.</t> As long as the same Rule set is installed at both ends, this degree of freedom d oes not constitute an interoperability issue.</t>
<t>If no valid compression Rule is found, then the packet MUST be sent unc </li>
ompressed <li>If no valid compression Rule is found, then the packet <bcp14>
using the Rule ID dedicated to this purpose (see <xref target="RuleID"/>). MUST</bcp14> be sent uncompressed
The entire packet header is the Compression Residue (see <xref target="Fig-SCHCp using the RuleID dedicated to this purpose (see <xref target="RuleID" format="de
ckt"/>). fault"/>).
Sending an uncompressed header is likely to require SCHC F/R.</t> The entire packet header is the Compression Residue (see <xref target="Fig-SCHCp
</list></t> ckt" format="default"/>).
<t>Compression: if a valid Rule was found, each field of the header is compres Sending an uncompressed header is likely to require SCHC F/R.</li>
sed according to the Compression/Decompression Actions (CDAs) of the Rule. </ul></dd>
The fields are compressed in the order that the Field Descriptions 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-em
pty residues for each field of the header, in the order the Field Descriptions a
ppear in the Rule.
The order in which the Field Descriptions appear in the Rule is therefore semant
ically important.</t>
</list></t>
<figure title="Compression Residue structure" anchor="Fig-CompRes"><artwork><![C <dt>Compression:</dt><dd>if a valid Rule is found, each field of the h
DATA[ eader is compressed according to the CDAs of the Rule.
The fields are compressed in the order that the Field 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-em
pty residues for each field of the header, in the order the Field Descriptors ap
pear in the Rule.
The order in which the Field Descriptors appear in the Rule is therefore semanti
cally important.</dd>
</dl>
<figure anchor="Fig-CompRes">
<name>Compression Residue Structure</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|------------------- Compression Residue -------------------| |------------------- Compression Residue -------------------|
+-----------------+-----------------+-----+-----------------+ +-----------------+-----------------+-----+-----------------+
| field 1 residue | field 2 residue | ... | field N residue | | field 1 residue | field 2 residue | ... | field N residue |
+-----------------+-----------------+-----+-----------------+ +-----------------+-----------------+-----+-----------------+]]></artwork>
</figure>
]]></artwork></figure> <dl spacing="normal">
<dt>Sending:</dt><dd>The RuleID is sent to the other end jointly with
<t><list style="symbols"> the Compression Residue (which could be empty) or the uncompressed header, and d
<t>Sending: The Rule ID is sent to the other end followed by the Compression R irectly followed by the payload (see <xref target="Fig-SCHCpckt" format="default
esidue (which could be empty) or the uncompressed header, and directly followed "/>).
by the payload (see <xref target="Fig-SCHCpckt"/>). The way the RuleID is sent will be specified in the Profile and is out of the sc
The way the Rule ID is sent will be specified in the Profile and is out of the s ope of the present document.
cope of the present document. For example, it could be included in an L2 header or sent as part of the L2 payl
For example, it could be included in an L2 header or sent as part of the L2 payl oad.</dd>
oad.</t>
<t>Decompression: when decompressing, on the Network infrastructure side the S
CHC C/D needs to find the correct Rule based on the L2 address of the Dev; in th
is way, it can use the DevIID and the Rule ID. On the Dev side, only the Rule ID
is needed to identify the correct Rule since the Dev typically only holds Rules
that apply to itself. <vspace blankLines='1'/>
This Rule describes the compressed header format. From this, the decompressor de
termines the order of the residues, the fixed-sized or variable-sized nature of
each residue (see <xref target="var-length-field"/>),
and the size of the fixed-sized residues. <vspace blankLines='1'/>
From the received compressed header, it can therefore retrieve all the residue v
alues and associate them to the corresponding header fields. <vspace blankLines
='1'/>
For each field in the header, the receiver applies the CDA action associated to
that field in order to reconstruct the original header field value. The CDA appl
ication order can be different from the order in which the fields are listed in
the Rule. In particular, Compute-* MUST be applied after the application of the
CDAs of all the fields it computes on.</t>
</list></t>
</section>
<section anchor="chap-MO" title="Matching operators">
<t>Matching Operators (MOs) are functions used by both SCHC C/D endpoints. 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. MOs are defined as follows:
</t>
<t><list style="symbols">
<t>equal: The match result is True if the field value in the packet matches th
e TV.</t>
<t>ignore: 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 match is obtained if the most significant (leftmost) x bits of th
e 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 ex
ample, x must be multiple of 8 if the unit of the variable length is bytes.</t>
<t>match-mapping: With match-mapping, the Target Value is a list of values. Ea
ch value of the list is identified by an index. Compression is achieved by sendi
ng the index instead of the original header field value. This operator matches i
f the header field value is equal to one of the values in the target list.</t>
</list></t>
</section>
<section anchor="chap-CDA" title="Compression Decompression Actions (CDA)">
<t>The Compression Decompression Action (CDA) describes the actions taken during
the compression of header fields and the inverse action taken by the decompress
or to restore the original value.</t>
<texttable title="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 TV stored in Rule</c>
<c>value-sent</c>
<c>send</c>
<c>use received value</c>
<c>mapping-sent</c>
<c>send index</c>
<c>retrieve value from TV list</c>
<c>LSB</c>
<c>send LSB</c>
<c>concat. TV and received value</c>
<c>compute-*</c>
<c>elided</c>
<c>recompute at decompressor</c>
<c>DevIID</c>
<c>elided</c>
<c>build IID from L2 Dev addr</c>
<c>AppIID</c>
<c>elided</c>
<c>build IID from L2 App addr</c>
</texttable>
<t><xref target="Fig-function"/> summarizes the basic actions that can be used t
o compress and decompress a field. The first column shows the action’s name. The
second and third columns show the compression and decompression behaviors for e
ach action.</t>
<section anchor="fixed-length-field" title="processing fixed-length fields"> <dt>Decompression:</dt><dd><t>when decompressing, on the Network Inf
rastructure side, the SCHC C/D needs to find the correct Rule based on the L2 ad
dress of the Dev.&nbsp; On the Dev side, only the RuleID is needed to identify t
he correct Rule since the Dev typically only holds Rules that apply to itself.
</t>
<t>
This Rule describes the compressed header format. From this, the decompressor de
termines the order of the residues, the fixed-size or variable-size nature of ea
ch residue (see <xref target="var-length-field" format="default"/>),
and the size of the fixed-size residues. </t>
<t>
Therefore, from the received compressed header, it can retrieve all the residue
values and associate them to the corresponding header fields. </t>
<t>
For each field in the header, the receiver applies the CDA action associated wit
h that field in order to reconstruct the original header field value. The CDA ap
plication order can be different from the order in which the fields are listed i
n the Rule. In particular, Compute-* <bcp14>MUST</bcp14> be applied after the ap
plication of the CDAs of all the fields it computes on.</t>
</dd>
</dl>
</section>
<section anchor="chap-MO" numbered="true" toc="default">
<name>Matching Operators</name>
<t>MOs are functions used at the compression side of SCHC C/D. They are
not typed and can be applied to integer, string or any other data type. The resu
lt of the operation can either be True or False. The following MOs are defined:<
/t>
<dl spacing="normal">
<dt>equal:</dt><dd>The match result is True if the field value in the
packet matches the 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.</dd>
<t>If the field is identified in the Field Description as being of fixed length, <dt>MSB(x):</dt><dd>A match is obtained if the most significant (leftm
then applying the CDA to compress this field results in a fixed amount of bits. ost) x bits of the packet header field value are equal to the TV in the Rule. Th
e x parameter of the MSB MO indicates how many bits are involved in the comparis
on. If the FL is described as variable, the x parameter must be a multiple of th
e FL unit. For example, x must be multiple of 8 if the unit of the variable leng
th is bytes.</dd>
<dt>match-mapping:</dt><dd>With match-mapping, TV is a list of values.
Each value of the list is identified by an index. Compression is achieved by se
nding the index instead of the original header field value. This operator matche
s if the header field value is equal to one of the values in the target list.</d
d>
</dl>
</section>
<section anchor="chap-CDA" numbered="true" toc="default">
<name>Compression/Decompression Actions (CDA)</name>
<t>The CDA specifies the actions taken during the compression of header
fields and the inverse action taken by the decompressor to restore the original
value.
The CDAs defined by this document are described in detail in <xref targe
t="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</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</td>
</tr>
<tr>
<td align="left">value-sent</td>
<td align="left">send</td>
<td align="left">use received value</td>
</tr>
<tr>
<td align="left">mapping-sent</td>
<td align="left">send index</td>
<td align="left">retrieve value from TV 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</td>
</tr>
<tr>
<td align="left">compute-*</td>
<td align="left">elided</td>
<td align="left">recompute at decompressor</td>
</tr>
<tr>
<td align="left">DevIID</td>
<td align="left">elided</td>
<td align="left">build IID from L2 Dev addr</td>
</tr>
<tr>
<td align="left">AppIID</td>
<td align="left">elided</td>
<td align="left">build IID from L2 App addr</td>
</tr>
</tbody>
</table>
<t>The first column shows the action's name. The second and third column
s show the compression and decompression behaviors for each action.</t>
<section anchor="fixed-length-field" numbered="true" toc="default">
<name>Processing Fixed-Length Fields</name>
<t>If the field is identified in the Field Descriptor as being of fixe
d 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. 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> This value may be empty (e.g., not-sent CDA), in which case the field residue is absent from the Compression Residue.</t>
<figure anchor="Fig-FieldResFixLength">
<figure title="fixed sized field residue structure" anchor="Fig-FieldResFixLengt <name>Fixed-Size Field Residue Structure</name>
h"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
|- field residue -| |- field residue -|
+-----------------+ +-----------------+
| value | | value |
+-----------------+ +-----------------+]]></artwork>
</figure>
]]></artwork></figure> </section>
<section anchor="var-length-field" numbered="true" toc="default">
</section> <name>Processing Variable-Length Fields</name>
<section anchor="var-length-field" title="processing variable-length fields"> <t>If the field is identified in the Field Descriptor as being of vari
able length,
<t>If the field is identified in the Field Description as being of variable leng
th,
then applying the CDA to compress this field may result in a value of fixed size then applying the CDA to compress this field may result in a value of fixed size
(e.g., not-sent or mapping-sent) (e.g., not-sent or mapping-sent)
or of variable size (e.g., value-sent or LSB). 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 appl ying the CDA to the field, preceded with the size of the value. In the latter case, the residue for that field is the bits that result from appl ying 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> The most significant bit of the size is stored to the left (leftmost bit of the residue field).</t>
<figure anchor="Fig-FieldResVarLength">
<figure title="variable sized field residue structure" anchor="Fig-FieldResVarLe <name>Variable-Size Field Residue Structure</name>
ngth"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
|--- field residue ---| |--- field residue ---|
+-------+-------------+ +-------+-------------+
| size | value | | size | value |
+-------+-------------+ +-------+-------------+]]></artwork>
</figure>
]]></artwork></figure> <t>The size (using the unit defined in the FL) is encoded on 4, 12, or
28 bits as follows:</t>
<t>The size (using the unit defined in the FL) is encoded on 4, 12 or 28 bits as <ul spacing="normal">
follows:</t> <li>If the size is between 0 and 14, it is encoded as a 4-bit unsign
ed integer.</li>
<t><list style="symbols"> <li>Sizes between 15 and 254 are encoded as 0b1111 followed by the 8
<t>If the size is between 0 and 14, it is encoded as a 4 bits unsigned integer -bit unsigned integer.</li>
.</t> <li>Larger sizes are encoded as 0xfff followed by the 16-bit unsigne
<t>Sizes between 15 and 254 are encoded as 0b1111 followed by the 8 bits unsig d integer.</li>
ned integer.</t> </ul>
<t>Larger sizes are encoded as 0xfff followed by the 16 bits unsigned integer. <t>If the field is identified in the Field Descriptor as being of vari
</t> able length and this field is not present in the packet header being compressed,
</list></t> size 0 <bcp14>MUST</bcp14> be sent to denote its absence.</t>
</section>
<t>If the field is identified in the Field Description as being of variable leng <section anchor="NotSentCDA" numbered="true" toc="default">
th and this field is not present in the packet header being compressed, size 0 M <name>Not-Sent CDA</name>
UST be sent to denote its absence.</t> <t>The not-sent action can be used when the field value is
specified in a Rule and, therefore, known by both the
</section> Compressor and the Decompressor. This action
<section anchor="NotSentCDA" title="not-sent CDA"> <bcp14>SHOULD</bcp14> be used with the "equal" MO. If MO is
"ignore", there is a risk of having a decompressed field
<t>The not-sent action can be used when the field value is specified in a Rule a value that is different from the original field that was compressed.</t
nd therefore known by both the Compressor and the Decompressor. This action SHOU >
LD be used with the “equal” MO. If MO is “ignore”, there is a risk to have a dec <t>The compressor does not send any residue for a field on which not-s
ompressed field value different from the original field that was compressed.</t> ent compression is applied.</t>
<t>The decompressor restores the field value with the TV stored in the
<t>The compressor does not send any residue for a field on which not-sent compre matched Rule identified by the received RuleID.</t>
ssion is applied.</t> </section>
<section anchor="value-sent-cda" numbered="true" toc="default">
<t>The decompressor restores the field value with the Target Value stored in the <name>Value-Sent CDA</name>
matched Rule identified by the received Rule ID.</t> <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,
</section> using the same bit order as in the original packet header.</t>
<section anchor="value-sent-cda" title="value-sent CDA"> <t>If this action is performed on a variable-length field, the size of
the residue value (using the units defined in FL) <bcp14>MUST</bcp14> be sent a
<t>The value-sent action can be used when the field value is not known by both t s described in <xref target="var-length-field" format="default"/>.</t>
he Compressor and the Decompressor. The field is sent in its entirety, using the <t>This action is generally used with the "ignore" MO.</t>
same bit order as in the original packet header.</t> </section>
<section anchor="mapping-sent-cda" numbered="true" toc="default">
<t>If this action is performed on a variable length field, the size of the resid <name>Mapping-Sent CDA</name>
ue value (using the units defined in FL) MUST be sent as described in <xref targ <t>The mapping-sent action is used to send an index (the index into th
et="var-length-field"/>.</t> e TV list of values) instead of the original value. This action is used together
with the "match-mapping" MO.</t>
<t>This action is generally used with the “ignore” MO.</t> <t>On the compressor side, the match-mapping MO searches the TV for a
match with the header field value. The mapping-sent CDA then sends the correspon
</section> ding index as the field residue.
<section anchor="mapping-sent-cda" title="mapping-sent CDA">
<t>The mapping-sent action is used to send an index (the index into the Target V
alue list of values) instead of the original value. This action is used together
with the “match-mapping” MO.</t>
<t>On the compressor side, the match-mapping Matching Operator searches the TV f
or a match with the header field value. The mapping-sent CDA then sends the corr
esponding index as the field residue.
The most significant bit of the index is stored to the left (leftmost bit of the residue field).</t> 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 restor
<t>On the decompressor side, the CDA uses the received index to restore the fiel e the field value by looking up the list in the TV.</t>
d value by looking up the list in the TV.</t> <t>The number of bits sent is the minimal size for coding all the poss
ible indices.</t>
<t>The number of bits sent is the minimal size for coding all the possible indic <t>The first element in the list <bcp14>MUST</bcp14> be represented by
es.</t> index value 0, and successive elements in the list <bcp14>MUST</bcp14> have ind
ices incremented by 1.</t>
<t>The first element in the list MUST be represented by index value 0, and succe </section>
ssive elements in the list MUST have indices incremented by 1.</t> <section anchor="lsb-cda" numbered="true" toc="default">
<name>LSB CDA</name>
</section> <t>The LSB action is used together with the "MSB(x)" MO to avoid sendi
<section anchor="lsb-cda" title="LSB CDA"> ng the most significant part of the packet field if that part is already known b
y the receiving end.</t>
<t>The LSB action is used together with the “MSB(x)” MO to avoid sending the mos <t>The compressor sends the LSBs as the field residue value.
t significant part of the packet field if that part is already known by the rece
iving end.</t>
<t>The compressor sends the Least Significant Bits as the field residue value.
The number of bits sent is the original header field length minus the length spe cified in the MSB(x) MO. The number of bits sent is the original header field length minus the length spe cified in the MSB(x) MO.
The bits appear in the residue in the same bit order as in the original packet h eader.</t> The bits appear in the residue in the same bit order as in the original packet h eader.</t>
<t>The decompressor concatenates the x most significant bits
<t>The decompressor concatenates the x most significant bits of Target Value and of the TV and the received residue value.</t>
the received residue value.</t> <t>If this action is performed on a variable-length field, the size of
the residue value (using the units defined in FL) <bcp14>MUST</bcp14> be sent a
<t>If this action is performed on a variable length field, the size of the resid s described in <xref target="var-length-field" format="default"/>.</t>
ue value (using the units defined in FL) MUST be sent as described in <xref targ </section>
et="var-length-field"/>.</t> <section anchor="deviid-appiid-cda" numbered="true" toc="default">
<name>DevIID, AppIID CDA</name>
</section> <t>These actions are used to process the DevIID and AppIID of the IPv6
<section anchor="deviid-appiid-cda" title="DevIID, AppIID CDA"> addresses, respectively. AppIID CDA is less common since most current LPWAN tec
hnologies frames contain a single L2 address, which is the Dev's address.</t>
<t>These actions are used to process respectively the Dev and the App Interface <t>The DevIID value <bcp14>MAY</bcp14> be computed from the Dev ID pre
Identifiers (DevIID and AppIID) of the IPv6 addresses. AppIID CDA is less common sent in the L2 header, or from some other stable identifier. The computation is
since most current LPWAN technologies frames contain a single L2 address, which specific to each Profile and <bcp14>MAY</bcp14> depend on the Dev ID size.</t>
is the Dev’s address.</t> <t>In the Downlink direction, at the compressor, the DevIID CDA may be
used to generate the L2 addresses on the LPWAN, based on the packet's Destinati
<t>The IID value MAY be computed from the Device ID present in the L2 header, or on Address.</t>
from some other stable identifier. The computation is specific to each Profile </section>
and MAY depend on the Device ID size.</t> <section anchor="compute-" numbered="true" toc="default">
<name>Compute-*</name>
<t>In the downlink direction (Dw), at the compressor, the DevIID CDA may be used <t>Some fields can be elided at the compressor and recomputed locally
to generate the L2 addresses on the LPWAN, based on the packet’s Destination Ad at the decompressor.</t>
dress.</t> <t>Because the field is uniquely identified by its FID (e.g., IPv6 len
gth), the relevant protocol specification unambiguously defines the algorithm fo
</section> r such computation.</t>
<section anchor="compute-" title="Compute-*"> <t>An example of a field that knows how to recompute itself is IPv6 le
ngth.</t>
<t>Some fields can be elided at the compressor and recomputed locally at the dec </section>
ompressor.</t> </section>
</section>
<t>Because the field is uniquely identified by its Field ID (e.g., UDP length), <section anchor="Frag" numbered="true" toc="default">
the relevant protocol specification unambiguously defines the algorithm for such <name>Fragmentation/Reassembly</name>
computation.</t> <section anchor="overview" numbered="true" toc="default">
<name>Overview</name>
<t>Examples of fields that know how to recompute themselves are UDP length, IPv6 <t>In LPWAN technologies, the L2 MTU typically ranges from tens to hundr
length and UDP checksum.</t> eds of bytes.
</section>
</section>
</section>
<section anchor="Frag" title="Fragmentation/Reassembly">
<section anchor="overview" title="Overview">
<t>In LPWAN technologies, the L2 MTU typically ranges from tens to hundreds of b
ytes.
Some of these technologies do not have an internal fragmentation/reassembly mech anism.</t> Some of these technologies do not have an internal fragmentation/reassembly mech anism.</t>
<t>The optional SCHC F/R functionality enables such LPWAN technologies t
<t>The optional SCHC Fragmentation/Reassembly (SCHC F/R) functionality enables s o comply with the IPv6 MTU requirement of 1280 bytes <xref target="RFC8200" form
uch LPWAN technologies to comply with the IPv6 MTU requirement of 1280 bytes <xr at="default"/>.
ef target="RFC8200"/>. It is <bcp14>OPTIONAL</bcp14> to implement per this specification, but Profiles
It is OPTIONAL to implement per this specification, but Profiles may specify tha may specify that it is <bcp14>REQUIRED</bcp14>.</t>
t it is REQUIRED.</t> <t>This specification includes several SCHC F/R modes, which allow for a
range of reliability options such as optional SCHC Fragment retransmission.
<t>This specification includes several SCHC F/R modes, which allow for a range o
f reliability options such as optional SCHC Fragment retransmission.
More modes may be defined in the future.</t> More modes may be defined in the future.</t>
<t>The same SCHC F/R mode <bcp14>MUST</bcp14> be used for all SCHC Fragm
<t>The same SCHC F/R mode MUST be used for all SCHC Fragments of a given SCHC Pa ents of a given SCHC Packet.
cket.
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> 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
<t>SCHC allows transmitting non-fragmented SCHC Packet concurrently with fragmen fragmented SCHC Packets.
ted SCHC Packets. In addition, SCHC F/R provides protocol elements that allow transmitting several
In addition, SCHC F/R provides protocol elements that allow transmitting several fragmented SCHC Packets concurrently, i.e., interleaving the transmission of fr
fragmented SCHC Packets concurrently, i.e. interleaving the transmission of fra agments from different fragmented SCHC Packets.
gments from different fragmented SCHC Packets. A Profile <bcp14>MAY</bcp14> restrict the latter behavior.</t>
A Profile MAY restrict the latter behavior.</t> <t>The L2 Word size (see <xref target="Term" format="default"/>) determi
nes the encoding of some messages.
<t>The L2 Word size (see <xref target="Term"/>) determines the encoding of some
messages.
SCHC F/R usually generates SCHC Fragments and SCHC ACKs that are multiples of L2 Words.</t> SCHC F/R usually generates SCHC Fragments and SCHC ACKs that are multiples of L2 Words.</t>
</section>
</section> <section anchor="FragTools" numbered="true" toc="default">
<section anchor="FragTools" title="SCHC F/R Protocol Elements"> <name>SCHC F/R Protocol Elements</name>
<t>This subsection describes the different elements that are used to ena
<t>This subsection describes the different elements that are used to enable the ble the SCHC F/R functionality defined in this document.
SCHC F/R functionality defined in this document. These elements include the SCHC F/R messages, tiles, windows, bitmaps, counters,
These elements include the SCHC F/R messages, tiles, windows, bitmaps, counters, timers, and header fields.</t>
timers and header fields.</t> <t>The elements are described here in a generic manner. Their applicatio
n to each SCHC F/R mode is found in <xref target="FragModes" format="default"/>.
<t>The elements are described here in a generic manner. Their application to eac </t>
h SCHC F/R mode is found in <xref target="FragModes"/>.</t> <section anchor="messages" numbered="true" toc="default">
<name>Messages</name>
<section anchor="messages" title="Messages"> <t>SCHC F/R defines the following messages:</t>
<dl spacing="normal">
<t>SCHC F/R defines the following messages:</t> <dt>SCHC Fragment:</dt><dd>A message that carries part of a SCHC Pac
ket from the sender to the receiver.</dd>
<t><list style="symbols"> <dt>SCHC ACK:</dt><dd>An acknowledgement for fragmentation, by the r
<t>SCHC Fragment: A message that carries part of a SCHC Packet from the sender eceiver to the sender.
to the receiver.</t>
<t>SCHC ACK: An acknowledgement for fragmentation, by the receiver to the send
er.
This message is used to indicate whether or not the reception of pieces of, This message is used to indicate whether or not the reception of pieces of,
or the whole of the fragmented SCHC Packet, was successful.</t> or the whole of, the fragmented SCHC Packet was successful.</dd>
<t>SCHC ACK REQ: A request by the sender for a SCHC ACK from the receiver.</t> <dt>SCHC ACK REQ:</dt><dd>A request by the sender for a SCHC ACK fro
<t>SCHC Sender-Abort: A message by the sender telling the receiver that it has m the receiver.</dd>
aborted the transmission of a fragmented SCHC Packet.</t> <dt>SCHC Sender-Abort:</dt><dd>A message by the sender telling the r
<t>SCHC Receiver-Abort: A message by the receiver to tell the sender to abort eceiver that it has aborted the transmission of a fragmented SCHC Packet.</dd>
the transmission of a fragmented SCHC Packet.</t> <dt>SCHC Receiver-Abort:</dt><dd>A message by the receiver to tell t
</list></t> he sender to abort the transmission of a fragmented SCHC Packet.</dd>
</dl>
<t>The format of these messages is provided in <xref target="Fragfor"/>.</t> <t>The format of these messages is provided in <xref target="Fragfor"
format="default"/>.</t>
</section> </section>
<section anchor="OtherTools" title="Tiles, Windows, Bitmaps, Timers, Counters"> <section anchor="OtherTools" numbered="true" toc="default">
<name>Tiles, Windows, Bitmaps, Timers, Counters</name>
<section anchor="tiles" title="Tiles"> <section anchor="tiles" numbered="true" toc="default">
<name>Tiles</name>
<t>The SCHC Packet is fragmented into pieces, hereafter called tiles. <t>The SCHC Packet is fragmented into pieces, hereafter called "tile
The tiles MUST be non-empty and pairwise disjoint. s".
Their union MUST be equal to the SCHC Packet.</t> The tiles <bcp14>MUST</bcp14> be non-empty and pairwise disjoint.
Their union <bcp14>MUST</bcp14> be equal to the SCHC Packet.</t>
<t>See <xref target="Fig-TilesExample"/> for an example.</t> <t>See <xref target="Fig-TilesExample" format="default"/> for an exa
mple.</t>
<figure title="a SCHC Packet fragmented in tiles" anchor="Fig-TilesExample"><art <figure anchor="Fig-TilesExample">
work><![CDATA[ <name>SCHC Packet Fragmented in Tiles</name>
SCHC Packet <artwork name="" type="" align="left" alt=""><![CDATA[
+----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ SCHC Packet
Tiles | | | | | | | | | | | | | | +----+--+-----+---+----+-+---+-----+...-----+----+---+------+
+----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ Tiles | | | | | | | | | | | | |
+----+--+-----+---+----+-+---+-----+...-----+----+---+------+]]></artwor
]]></artwork></figure> k>
</figure>
<t>Modes (see <xref target="FragModes"/>) MAY place additional constraints on ti <t>Modes (see <xref target="FragModes" format="default"/>) <bcp14>MA
le sizes.</t> Y</bcp14> place additional constraints on tile sizes.</t>
<t>Each SCHC Fragment message carries at least one tile in its Paylo
<t>Each SCHC Fragment message carries at least one tile in its Payload, if the P ad, if the Payload field is present.</t>
ayload field is present.</t> </section>
<section anchor="Windows" numbered="true" toc="default">
</section> <name>Windows</name>
<section anchor="Windows" title="Windows"> <t>Some SCHC F/R modes may handle successive tiles in groups, called
windows.</t>
<t>Some SCHC F/R modes may handle successive tiles in groups, called windows.</t <t>If windows are used:</t>
> <ul spacing="normal">
<li>all the windows of a SCHC Packet, except the last one, <bcp14>
<t>If windows are used</t> MUST</bcp14> contain the same number of tiles.
This number is WINDOW_SIZE.</li>
<t><list style="symbols"> <li>WINDOW_SIZE <bcp14>MUST</bcp14> be specified in a Profile.</li
<t>all the windows of a SCHC Packet, except the last one, MUST contain the sam >
e number of tiles. <li>the windows are numbered.</li>
This number is WINDOW_SIZE.</t> <li>their numbers <bcp14>MUST</bcp14> increment by 1 from 0 upward
<t>WINDOW_SIZE MUST be specified in a Profile.</t> , from the start of the SCHC Packet to its end.</li>
<t>the windows are numbered.</t> <li>the last window <bcp14>MUST</bcp14> contain WINDOW_SIZE tiles
<t>their numbers MUST increment by 1 from 0 upward, from the start of the SCHC or less.</li>
Packet to its end.</t> <li>tiles are numbered within each window.</li>
<t>the last window MUST contain WINDOW_SIZE tiles or less.</t> <li>the tile indices <bcp14>MUST</bcp14> decrement by 1 from WINDO
<t>tiles are numbered within each window.</t> W_SIZE - 1 downward, looking from the start of the SCHC Packet toward its end.</
<t>the tile indices MUST decrement by 1 from WINDOW_SIZE - 1 downward, looking li>
from the start of the SCHC Packet toward its end.</t> <li>therefore, each tile of a SCHC Packet is uniquely identified b
<t>each tile of a SCHC Packet is therefore uniquely identified by a window num y a window number and a tile index within this window.</li>
ber and a tile index within this window.</t> </ul>
</list></t> <t>See <xref target="Fig-WindowsExample" format="default"/> for an e
xample.</t>
<t>See <xref target="Fig-WindowsExample"/> for an example.</t> <figure anchor="Fig-WindowsExample">
<name>SCHC Packet Fragmented in Tiles Grouped in 29 Windows, with
<figure title="a SCHC Packet fragmented in tiles grouped in 29 windows, with WIN WINDOW_SIZE = 5</name>
DOW_SIZE = 5" anchor="Fig-WindowsExample"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------------...-------------+ +---------------------------------------------...-----------+
| SCHC Packet | | SCHC Packet |
+---------------------------------------------...-------------+ +---------------------------------------------...-----------+
Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 |
Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -|
]]></artwork></figure>
<t><xref target="MultWinSizes"/> discusses the benefits of selecting one among m
ultiple 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 (see <xref target="Bitmap"/>) MAY be sent back by the receiver to t
he sender in a SCHC ACK message.</t>
<t>A Bitmap corresponds to exactly one Window.</t>
</list></t>
</section>
<section anchor="Bitmap" title="Bitmaps">
<t>Each bit in the Bitmap for a window corresponds to a tile in the window. Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Each Bitmap has therefore WINDOW_SIZE bits. Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|]]></artwor
The bit at the left-most position corresponds to the tile numbered WINDOW_SIZE - k>
1. </figure>
<t><xref target="MultWinSizes" format="default"/> discusses the bene
fits of selecting one among multiple window sizes depending on the size of the S
CHC Packet to be fragmented.</t>
<t>When windows are used:</t>
<ul spacing="normal">
<li>Bitmaps (see <xref target="Bitmap" format="default"/>) <bcp14>
MAY</bcp14> be sent back by the receiver to the sender in a SCHC ACK message.</l
i>
<li>A Bitmap corresponds to exactly one Window.</li>
</ul>
</section>
<section anchor="Bitmap" numbered="true" toc="default">
<name>Bitmaps</name>
<t>Each bit in the Bitmap for a window corresponds to a tile in the
window.
Therefore, each Bitmap has WINDOW_SIZE bits.
The bit at the leftmost position corresponds to the tile numbered WINDOW_SIZE -
1.
Consecutive bits, going right, correspond to sequentially decreasing tile indice s. Consecutive bits, going right, correspond to sequentially decreasing tile indice s.
In Bitmaps for windows that are not the last one of a SCHC Packet, In Bitmaps for windows that are not the last one of a SCHC Packet,
the bit at the right-most position corresponds to the tile numbered 0. the bit at the rightmost position corresponds to the tile numbered 0.
In the Bitmap for the last window, In the Bitmap for the last window,
the bit at the right-most position corresponds either to the tile numbered 0 or the bit at the rightmost position corresponds either to the tile numbered 0 or t
to a tile that is sent/received as “the last one of the SCHC Packet” without exp o a tile that is sent/received as "the last one of the SCHC Packet" without expl
licitly stating its number (see <xref target="LastFrag"/>).</t> icitly stating its number (see <xref target="LastFrag" format="default"/>).</t>
<t>At the receiver:</t>
<t>At the receiver</t> <ul spacing="normal">
<li>a bit set to 1 in the Bitmap indicates that a tile associated
<t><list style="symbols"> with that bit position has been correctly received for that window.</li>
<t>a bit set to 1 in the Bitmap indicates that a tile associated with that bit <li>a bit set to 0 in the Bitmap indicates that there has been no
position has been correctly received for that window.</t> tile correctly received, associated with that bit position, for that window.
<t>a bit set to 0 in the Bitmap indicates that there has been no tile correctl Possible reasons include that the tile was not sent at all, not received, or rec
y received, associated with that bit position, for that window. eived with errors.</li>
Possible reasons include that the tile was not sent at all, not received, or rec </ul>
eived with errors.</t> </section>
</list></t> <section anchor="MiscTools" numbered="true" toc="default">
<name>Timers and Counters</name>
</section> <t>Some SCHC F/R modes can use the following timers and counters:</t
<section anchor="MiscTools" title="Timers and counters"> >
<dl spacing="normal">
<t>Some SCHC F/R modes can use the following timers and counters</t> <dt>Inactivity Timer:</dt><dd>a SCHC Fragment receiver uses this t
imer to abort waiting for a SCHC F/R message.</dd>
<t><list style="symbols"> <dt>Retransmission Timer:</dt><dd>a SCHC Fragment sender uses this
<t>Inactivity Timer: a SCHC Fragment receiver uses this timer to abort waiting timer to abort waiting for an expected SCHC ACK.</dd>
for a SCHC F/R message.</t> <dt>Attempts:</dt><dd>this counter counts the requests for SCHC AC
<t>Retransmission Timer: a SCHC Fragment sender uses this timer to abort waiti Ks, up to MAX_ACK_REQUESTS.</dd>
ng for an expected SCHC ACK.</t> </dl>
<t>Attempts: this counter counts the requests for SCHC ACKs, up to MAX_ACK_REQ </section>
UESTS.</t> </section>
</list></t> <section anchor="IntegrityChecking" numbered="true" toc="default">
<name>Integrity Checking</name>
</section> <t>The integrity of the fragmentation-reassembly process of a SCHC Pac
</section> ket <bcp14>MUST</bcp14> be checked at the receive end.
<section anchor="IntegrityChecking" title="Integrity Checking"> A Profile <bcp14>MUST</bcp14> specify how integrity checking is performed.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that integrity checking be perform
<t>The integrity of the fragmentation-reassembly process of a SCHC Packet MUST b ed by computing a Reassembly Check Sequence (RCS)
e checked at the receive end.
A Profile MUST specify how integrity checking is performed.</t>
<t>It is RECOMMENDED that integrity checking be performed by computing a Reassem
bly Check Sequence (RCS)
based on the SCHC Packet at the sender side 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> 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
<t>The RCS supports UDP checksum elision by SCHC C/D (see <xref target="UDPcheck ="UDPchecksum" format="default"/>).</t>
sum"/>).</t> <t>The CRC32 polynomial 0xEDB88320 (i.e., the reversed polynomial repr
esentation, which is
<t>The CRC32 polynomial 0xEDB88320 (i.e., the reversed polynomial representation used in the Ethernet standard <xref target="ETHERNET" format="default"/>) is <bc
, which is p14>RECOMMENDED</bcp14> as the default algorithm for computing the
used in the Ethernet standard <xref target="ETHERNET"/>) is RECOMMENDED as the d
efault algorithm for computing the
RCS.</t> RCS.</t>
<t>The RCS <bcp14>MUST</bcp14> be computed on the full SCHC Packet con
<t>The RCS MUST be computed on the full SCHC Packet concatenated with the paddin catenated with the padding bits, if any, of the SCHC Fragment carrying the last
g bits, if any, of the SCHC Fragment carrying the last tile. tile.
The rationale is that the SCHC reassembler has no way of knowing the boundary be tween the last tile and the padding bits. The rationale is that the SCHC reassembler has no way of knowing the boundary be tween the last tile and the padding bits.
Indeed, this requires decompressing the SCHC Packet, which is out of the scope o f the SCHC reassembler.</t> Indeed, this requires decompressing the SCHC Packet, which is out of the scope o f the SCHC reassembler.</t>
<t>The concatenation of the complete SCHC Packet and any padding bits,
<t>The concatenation of the complete SCHC Packet and any padding bits, if presen if present, of the last SCHC Fragment does not
t, of the last SCHC Fragment does not
generally constitute an integer number of bytes. generally constitute an integer number of bytes.
CRC libraries are usually byte-oriented. CRC libraries are usually byte oriented.
It is RECOMMENDED that the concatenation of the It is <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 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> that the RCS be computed on that byte array.</t>
</section>
<section anchor="HeaderFields" 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" format="default"/>):</t>
<dl spacing="normal">
</section> <dt>RuleID:</dt><dd><t>this field is present in all the SCHC F/R m
<section anchor="HeaderFields" title="Header Fields"> essages. The Rule identifies:</t>
<ul spacing="normal">
<t>The SCHC F/R messages contain the following fields (see the formats in <xref <li>that a SCHC F/R message is being carried, as opposed to an u
target="Fragfor"/>):</t> nfragmented SCHC Packet,</li>
<li>which SCHC F/R mode is used,</li>
<t><list style="symbols"> <li>in case this mode uses windows, what the value of
<t>Rule ID: this field is present in all the SCHC F/R messages. The Rule ident WINDOW_SIZE is, and</li>
ifies <list style="symbols"> <li>what other optional fields are present and what the field si
<t>that a SCHC F/R message is being carried, as opposed to an unfragmented zes are.</li>
SCHC Packet,</t> </ul>
<t>which SCHC F/R mode is used</t> <t>
<t>in case this mode uses windows, what the value of WINDOW_SIZE is,</t>
<t>what other optional fields are present and what the field sizes are.</t
>
</list>
The Rule tells apart a non-fragmented SCHC Packet from SCHC Fragments. 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 diffe rent SCHC F/R modes or different parameters. It will also tell apart SCHC Fragments of fragmented SCHC Packets that use diffe rent SCHC F/R modes or different parameters.
Interleaved transmission of these is therefore possible. <vspace blankLines='1' Therefore, interleaved transmission of these is possible. </t>
/> <t>
All SCHC F/R messages pertaining to the same SCHC Packet MUST bear the same Rule All SCHC F/R messages pertaining to the same SCHC Packet <bcp14>MUST</bcp14> bea
ID.</t> r the same RuleID.</t>
<t>Datagram Tag (DTag). </dd>
This field allows differentiating SCHC F/R messages belonging to different SCHC
Packets <dt>Datagram Tag (DTag):</dt><dd><t>This field allows differentiat
that may be using the same Rule ID simultaneously. ing SCHC F/R messages belonging to different SCHC Packets
Hence, it allows interleaving fragments of a new SCHC Packet with fragments of a that may be using the same RuleID simultaneously.
previous SCHC Packet under the same Rule ID. <vspace blankLines='1'/> Hence, it allows interleaving fragments of a new SCHC Packet with fragments of a
The size of the DTag field (called T, in bits) is defined by each Profile for ea previous SCHC Packet under the same RuleID. </t>
ch Rule ID. <t>
When T is 0, the DTag field does not appear in the SCHC F/R messages and the DTa The size of the DTag field (called "T", in bits) is defined by each Profile for
g value is defined as 0. <vspace blankLines='1'/> each RuleID.
When T is 0, there can be no more than one fragmented SCHC Packet in transit for When T is 0, the DTag field does not appear in the SCHC F/R messages and the DTa
each fragmentation Rule ID. <vspace blankLines='1'/> g value is defined as 0. </t>
If T is not 0, DTag <list style="symbols"> <t>
<t>MUST be set to the same value for all the SCHC F/R messages related to When T is 0, there can be no more than one fragmented SCHC Packet in transit for
the same fragmented SCHC Packet,</t> each fragmentation RuleID. </t>
<t>MUST be set to different values for SCHC F/R messages related to differ <t>
ent SCHC Packets that are being fragmented under the same Rule ID, and whose tra If T is not 0, DTag: </t>
nsmission may overlap.</t>
</list></t> <ul spacing="normal">
<t>W: The W field is optional. It is only present if windows are used. <li><bcp14>MUST</bcp14> be set to the same value for all the SCH
Its presence and size (called M, in bits) is defined by each SCHC F/R mode and e C F/R messages related to the same fragmented SCHC Packet, and</li>
ach Profile for each Rule ID. <vspace blankLines='1'/> <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 s
ame RuleID and whose transmission may overlap.</li>
</ul>
</dd>
<dt>W:</dt><dd><t>The W field is optional. It is only present if w
indows are used.
Its presence and size (called "M", in bits) is defined by each SCHC F/R mode and
each Profile for each RuleID. </t>
<t>
This field carries information pertaining to the window a SCHC F/R message relat es to. This field carries information pertaining to the window a SCHC F/R message relat es to.
If present, W MUST carry the same value for all the SCHC F/R messages related to If present, W <bcp14>MUST</bcp14> carry the same value for all the SCHC F/R mess
the same window. ages related to the same window.
Depending on the mode and Profile, W may carry the full window number, or just t Depending on the mode and Profile, W may carry the full window number, or just t
he least significant bit or any other partial representation of the window numbe he LSB or any other partial representation of the window number.</t>
r.</t> </dd>
<t>Fragment Compressed Number (FCN). The FCN field is present in the SCHC Frag
ment Header. <dt>Fragment Compressed Number (FCN):</dt><dd><t>The FCN field is
Its size (called N, in bits) is defined by each Profile for each Rule ID. <vspa present in the SCHC Fragment Header.
ce blankLines='1'/> Its size (called "N", in bits) is defined by each Profile for each RuleID. </t>
<t>
This field conveys information about the progress in the sequence of tiles being transmitted by SCHC Fragment messages. 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-size d tile index. For example, it can contain a partial, efficient representation of a larger-size d tile index.
The description of the exact use of the FCN field is left to each SCHC F/R mode. 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 SCH However, two values are reserved for special purposes. They help control the SCH
C F/R process: <list style="symbols"> C F/R process: </t>
<t>The FCN value with all the bits equal to 1 (called All-1) signals that <ul spacing="normal">
the very last tile of a SCHC Packet has been transmitted. <li>The FCN value with all the bits equal to 1 (called "All-1")
By extension, if windows are used, the last window of a packet is called the All signals that the very last tile of a SCHC Packet has been transmitted.
-1 window.</t> By extension, if windows are used, the last window of a packet is called the "Al
<t>If windows are used, the FCN value with all the bits equal to 0 (called l-1" window.</li>
All-0) signals <li>If windows are used, the FCN value with all the bits equal t
o 0 (called "All-0") signals
the last tile of a window that is not the last one of the SCHC packet. 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> By extension, such a window is called an "All-0 window".</li>
</list></t> </ul>
<t>Reassembly Check Sequence (RCS). </dd>
This field only appears in the All-1 SCHC Fragments.
Its size (called U, in bits) is defined by each Profile for each Rule ID. <vspa
ce blankLines='1'/>
See <xref target="IntegrityChecking"/> for the RCS default size, default polynom
ial and details on RCS computation.</t>
<t>C (integrity Check): C is a 1-bit field.
This field is used in the SCHC ACK message to report on the reassembled SCHC Pac
ket integrity check (see <xref target="IntegrityChecking"/>). <vspace blankLine
s='1'/>
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, or that is was a
failure.</t>
<t>Compressed Bitmap. The Compressed Bitmap is used together with windows and
Bitmaps (see <xref target="Bitmap"/>).
Its presence and size is defined for each F/R mode for each Rule ID. <vspace bl
ankLines='1'/>
This field appears in the SCHC ACK message to report on the receiver Bitmap (see
<xref target="BitmapTrunc"/>).</t>
</list></t>
</section>
</section>
<section anchor="Fragfor" title="SCHC F/R Message Formats">
<t>This section defines the SCHC Fragment formats, the SCHC ACK format, the SCHC <dt>Reassembly Check Sequence (RCS):</dt><dd><t>This field only ap
ACK REQ format and the SCHC Abort formats.</t> pears in the All-1 SCHC Fragments.
Its size (called "U", in bits) is defined by each Profile for each RuleID. </t>
<t>
See <xref target="IntegrityChecking" format="default"/> for the RCS default size
, default polynomial and details on RCS computation.</t>
</dd>
<section anchor="schc-fragment-format" title="SCHC Fragment format"> <dt>C (integrity 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 Pac
ket integrity check (see <xref 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 or that it was a f
ailure.</t>
</dd>
<t>A SCHC Fragment conforms to the general format shown in <xref target="Fig-Fra <dt>Compressed Bitmap:</dt><dd><t>The Compressed Bitmap is used to
gFormat"/>. gether with windows and Bitmaps (see <xref target="Bitmap" format="default"/>).
Its presence and size is defined for each SCHC F/R mode for each RuleID. </t>
<t>
This field appears in the SCHC ACK message to report on the receiver Bitmap (see
<xref target="BitmapTrunc" format="default"/>).</t>
</dd>
</dl>
</section>
</section>
<section anchor="Fragfor" numbered="true" toc="default">
<name>SCHC F/R Message 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" numbered="true" toc="default">
<name>SCHC Fragment Format</name>
<t>A SCHC Fragment conforms to the general format shown in <xref targe
t="Fig-FragFormat" format="default"/>.
It comprises a SCHC Fragment Header and a SCHC Fragment Payload. It comprises a SCHC Fragment Header and a SCHC Fragment Payload.
The SCHC Fragment Payload carries one or several tile(s).</t> The SCHC Fragment Payload carries one or several tile(s).</t>
<figure anchor="Fig-FragFormat">
<figure title="SCHC Fragment general format" anchor="Fig-FragFormat"><artwork><! <name>SCHC Fragment General Format</name>
[CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
| Fragment Header |   Fragment Payload | padding (as needed)
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
]]></artwork></figure> | Fragment Header | Fragment Payload | padding (as needed)
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~]]></artwork>
<section anchor="NotLastFrag" title="Regular SCHC Fragment"> </figure>
<t>The Regular SCHC Fragment format is shown in <xref target="Fig-NotLastFrag"/> <section anchor="NotLastFrag" numbered="true" toc="default">
. <name>Regular SCHC Fragment</name>
<t>The Regular SCHC Fragment format is shown in <xref target="Fig-No
tLastFrag" format="default"/>.
Regular SCHC Fragments are generally used to carry tiles that are not the last o ne of a SCHC Packet. Regular SCHC Fragments are generally used to carry tiles that are not the last o ne of a SCHC Packet.
The DTag field and the W field are OPTIONAL, their presence is specified by each The DTag field and the W field are <bcp14>OPTIONAL</bcp14>, their presence is sp
mode and Profile.</t> ecified by each mode and Profile.</t>
<figure anchor="Fig-NotLastFrag">
<figure title="Detailed Header Format for Regular SCHC Fragments" anchor="Fig-No <name>Detailed Header Format for Regular SCHC Fragments</name>
tLastFrag"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC Fragment Header ----| |-- SCHC Fragment Header ----|
|-- T --|-M-|-- N --| |-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed) | RuleID | DTag | W | FCN | Fragment Payload | padding (as needed)
+-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~]]></artwor
]]></artwork></figure> k>
</figure>
<t>The FCN field MUST NOT contain all bits set to 1.</t> <t>The FCN field <bcp14>MUST NOT</bcp14> contain all bits set to 1.<
/t>
<t>Profiles MUST ensure that <t>Profiles <bcp14>MUST</bcp14> ensure that
a SCHC Fragment with FCN equal to 0 (called an All-0 SCHC Fragment) is distingui a SCHC Fragment with FCN equal to 0 (called an "All-0 SCHC Fragment") is disting
shable by size, uishable by size,
even in the presence of padding, even in the presence of padding,
from a SCHC ACK REQ message (see <xref target="ACKREQ"/>) with the same Rule ID value and with the same T, M and N values. from a SCHC ACK REQ message (see <xref target="ACKREQ" format="default"/>) with the same RuleID value and with the same T, M, and N values.
This condition is met if the Payload is at least the size of an L2 Word. 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> This condition is also met if the SCHC Fragment Header is a multiple of L2 Words .</t>
</section>
</section> <section anchor="LastFrag" numbered="true" toc="default">
<section anchor="LastFrag" title="All-1 SCHC Fragment"> <name>All-1 SCHC Fragment</name>
<t>The All-1 SCHC Fragment format is shown in <xref target="Fig-Last
<t>The All-1 SCHC Fragment format is shown in <xref target="Fig-LastFrag"/>. Frag" format="default"/>.
The sender uses the All-1 SCHC Fragment format for the message that completes th e emission of a fragmented SCHC Packet. The sender uses the All-1 SCHC Fragment format for the message that completes th e emission of a fragmented SCHC Packet.
The DTag field, the W field, the RCS field and the Payload are OPTIONAL, their p The DTag field, the W field, the RCS field and the Payload are <bcp14>OPTIONAL</
resence is specified by each mode and Profile. bcp14>, their presence is specified by each mode and Profile.
At least one of RCS field or Payload MUST be present. At least one of RCS field or Fragment Payload <bcp14>MUST</bcp14> be present.
The FCN field is all ones.</t> The FCN field is all ones.</t>
<figure anchor="Fig-LastFrag">
<figure title="Detailed Header Format for the All-1 SCHC Fragment" anchor="Fig-L <name>Detailed Header Format for the All-1 SCHC Fragment</name>
astFrag"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
|-------- SCHC Fragment Header -------| |------- SCHC Fragment Header -------|
|-- T --|-M-|-- N --|-- U --| |-- T --|-M-|-- N --|-- U --|
+-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+- ... -+-----...-----+~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 11..1 | RCS | Frag Payload | pad. (as needed) | RuleID | DTag | W | 11..1 | RCS | FragPayload | pad. (as needed)
+-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+- ... -+-----...-----+~~~~~~~~~~~~~~~~~
(FCN) (FCN)]]></artwork>
]]></artwork></figure> </figure>
<t>Profiles <bcp14>MUST</bcp14> ensure that
<t>Profiles MUST ensure that
an All-1 SCHC Fragment message is distinguishable by size, an All-1 SCHC Fragment message is distinguishable by size,
even in the presence of padding, even in the presence of padding,
from a SCHC Sender-Abort message (see <xref target="SenderAbort"/>) with the sam from a SCHC Sender-Abort message (see <xref target="SenderAbort" format="default
e Rule ID value and with the same T, M and N values. "/>) with the same RuleID value and with the same T, M, and N values.
This condition is met if the RCS is present and is at least the size of an L2 Wo This condition is met if the RCS is present and is at least the size of an L2 Wo
rd, rd
or if the Payload is present and at least the size an L2 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 W ords.</t> This condition is also met if the SCHC Sender-Abort Header is a multiple of L2 W ords.</t>
</section>
</section>
<section anchor="ACK" numbered="true" toc="default">
<name>SCHC ACK Format</name>
<t>The SCHC ACK message is shown in <xref target="Fig-ACK-Format" form
at="default"/>.
The DTag field and the W field are <bcp14>OPTIONAL</bcp14>, their presence is sp
ecified by each mode and Profile.
The Compressed Bitmap field <bcp14>MUST</bcp14> be present in SCHC F/R modes tha
t use windows and <bcp14>MUST NOT</bcp14> be present in other modes.</t>
<figure anchor="Fig-ACK-Format">
<name>Format of the SCHC ACK Message</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|
|-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
| RuleID | DTag | W |C=1| padding as needed (success)
+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
</section> +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
</section> | RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
<section anchor="ACK" title="SCHC ACK format"> +-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~]]></artwork>
</figure>
<t>The SCHC ACK message is shown in <xref target="Fig-ACK-Format"/>. <t>The SCHC ACK Header contains a C bit (see <xref target="HeaderField
The DTag field and the W field are OPTIONAL, their presence is specified by each s" format="default"/>).</t>
mode and Profile. <t>If the C bit is set to 1 (integrity check successful),
The Compressed Bitmap field MUST be present in SCHC F/R modes that use windows,
and MUST NOT be present in other modes.</t>
<figure title="Format of the SCHC ACK message" anchor="Fig-ACK-Format"><artwork>
<![CDATA[
|---- SCHC ACK Header ----|
|-- T --|-M-| 1 |
+--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W |C=1| padding as needed (success)
+--- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
+--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
| Rule ID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
+--- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
]]></artwork></figure>
<t>The SCHC ACK Header contains a C bit (see <xref target="HeaderFields"/>).</t>
<t>If the C bit is set to 1 (integrity check successful),
no Bitmap is carried.</t> no Bitmap is carried.</t>
<t>If the C bit is set to 0 (integrity check not performed or failed)
<t>If the C bit is set to 0 (integrity check not performed or failed) and if win and if windows are used,
dows are used,
a Compressed Bitmap for the window referred to by the W field is transmitted a Compressed Bitmap for the window referred to by the W field is transmitted
as specified in <xref target="BitmapTrunc"/>.</t> as specified in <xref target="BitmapTrunc" format="default"/>.</t>
<section anchor="BitmapTrunc" numbered="true" toc="default">
<section anchor="BitmapTrunc" title="Bitmap Compression"> <name>Bitmap Compression</name>
<t>For transmission, the Compressed Bitmap in the SCHC ACK message is defined by <t>For transmission, the Compressed Bitmap in the SCHC ACK message i
the following algorithm (see <xref target="Fig-Localbitmap"/> for a follow-alon s defined by the following algorithm (see <xref target="Fig-Localbitmap" format=
g example):</t> "default"/> for a follow-along example):</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Build a temporary SCHC ACK message that contains the Header fo
<t>Build a temporary SCHC ACK message that contains the Header followed by the llowed by the original Bitmap
original Bitmap (see <xref target="Bitmap" format="default"/> for a description of Bitmaps).</l
(see <xref target="Bitmap"/> for a description of Bitmaps).</t> i>
<t>Position scissors at the end of the Bitmap, after its last bit.</t> <li>Position scissors at the end of the Bitmap, after
<t>While the bit on the left of the scissors is 1 and belongs to the Bitmap, k its last bit.</li>
eep moving left, then stop. When this is done,</t>
<t>While the scissors are not on an L2 Word boundary of the SCHC ACK message a
nd there is a Bitmap bit on the right of the scissors, keep moving right, then s
top.</t>
<t>At this point, cut and drop off any bits to the right of the scissors</t>
</list></t>
<t>When one or more bits have effectively been dropped off as a result of the ab
ove algorithm, the SCHC ACK message is a multiple of L2 Words, no padding bits w
ill be appended.</t>
<t>Because the SCHC Fragment sender knows the size of the original Bitmap, it ca
n reconstruct the original Bitmap from the Compressed Bitmap received in the SCH
ACK message.</t>
<t><xref target="Fig-Localbitmap"/> 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 ACK Header plus uncompressed Bitmap" anchor="Fig-Localbitmap
"><artwork><![CDATA[
|---- SCHC ACK Header ----|-------- Bitmap --------|
|-- T --|-M-| 1 |
+--- ... -+- ... -+---+---+---------------------------------+
| Rule ID | 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>
<t><xref target="Fig-transmittedbitmap"/> shows that the last 14 bits are not se
nt.</t>
<figure title="Resulting SCHC ACK message with Compressed Bitmap" anchor="Fig-tr
ansmittedbitmap"><artwork><![CDATA[
|---- SCHC ACK Header ----|CpBmp|
|-- T --|-M-| 1 |
+--- ... -+- ... -+---+---+-----+
| Rule ID | DTag | W |C=0|1 0 1|
+--- ... -+- ... -+---+---+-----+
next L2 Word boundary ->|
]]></artwork></figure>
<t><xref target="Fig-Bitmap-Win"/> shows an example of a SCHC ACK with tile indi
ces 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 of a SCHC ACK message, missing tiles" anchor="Fig-Bitmap-
Win"><artwork><![CDATA[
|---- SCHC ACK Header ----|--- Bitmap --|
|-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
+---------+-------+---+---+-------------+
| Rule ID | DTag | W |C=0|1 0 1 0 1 1 1| uncompressed Bitmap
+---------+-------+---+---+-------------+
next L2 Word boundary ->|<-- L2 Word -->|
+---------+-------+---+---+-------------+~~~+
| Rule ID | DTag | W |C=0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK
+---------+-------+---+---+-------------+~~~+
next L2 Word boundary ->|<-- L2 Word -->|
]]></artwork></figure>
<t><xref target="Fig-Bitmap-lastWin"/> shows an example of a SCHC ACK with FCN r
anging from 6 down to 0, where integrity check has not been performed or has fai
led and the Bitmap indicates that there is no missing tile in that window.</t>
<figure title="Example of a SCHC ACK message, no missing tile" anchor="Fig-Bitma
p-lastWin"><artwork><![CDATA[
|---- SCHC ACK Header ----|--- Bitmap --|
|-- T --|-M-| 1 |6 5 4 3 2 1 0| (tile #)
+---------+-------+---+---+-------------+
| Rule ID | DTag | W |C=0|1 1 1 1 1 1 1| with uncompressed Bitmap
+---------+-------+---+---+-------------+
next L2 Word boundary ->|
+--- ... -+- ... -+---+---+-+ <li>While the bit on the left of the scissors is 1 and belongs to
| Rule ID | DTag | W |C=0|1| transmitted SCHC ACK the Bitmap, keep moving left, then stop.</li>
+--- ... -+- ... -+---+---+-+ <li>Then, while the scissors are not on an L2 Word boundary of the
next L2 Word boundary ->| SCHC ACK message and there is a Bitmap bit on the right of the scissors, keep m
]]></artwork></figure> oving right, then stop.</li>
<li>At this point, cut and drop off any bits to the right of the s
cissors.</li>
</ul>
<t>When one or more bits have effectively been dropped off as a resu
lt of the above algorithm, the SCHC ACK message is a multiple of L2 Words; no pa
dding bits will be appended.</t>
<t>Because the SCHC Fragment sender knows the size of the original B
itmap, it can reconstruct the original Bitmap from the Compressed Bitmap receive
d in the SCHC ACK message.</t>
<t><xref target="Fig-Localbitmap" format="default"/> shows an exampl
e where L2 Words are actually bytes and where the original Bitmap contains 17 bi
ts, the last 15 of which are all set to 1.</t>
<figure anchor="Fig-Localbitmap">
<name>SCHC ACK Header Plus Uncompressed Bitmap</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|-------- Bitmap --------|
|-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+---------------------------------+
| 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>
<t><xref target="Fig-transmittedbitmap" format="default"/> shows tha
t the last 14 bits are not sent.</t>
<figure anchor="Fig-transmittedbitmap">
<name>Resulting SCHC ACK Message with Compressed Bitmap</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
|--- SCHC ACK Header ----|CpBmp|
|-- T --|-M-| 1 |
+-- ... -+- ... -+---+---+-----+
| RuleID | DTag | W |C=0|1 0 1|
+-- ... -+- ... -+---+---+-----+
next L2 Word boundary ->|]]></artwork>
</figure>
<t><xref 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 indi
cates that the second and the fourth tile of the window have not been correctly
received.</t>
<figure anchor="Fig-Bitmap-Win">
<name>Example of a SCHC ACK 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 #)
+--------+-------+---+---+-------------+
| RuleID | DTag | W |C=0|1 0 1 0 1 1 1| uncompressed Bitmap
+--------+-------+---+---+-------------+
next L2 Word boundary ->|<-- L2 Word --->|
</section> +--------+-------+---+---+-------------+~~~~+
</section> | RuleID | DTag | W |C=0|1 0 1 0 1 1 1|pad.| transmitted SCHC ACK
<section anchor="ACKREQ" title="SCHC ACK REQ format"> +--------+-------+---+---+-------------+~~~~+
next L2 Word boundary ->|<-- L2 Word --->|]]></artwork>
</figure>
<t><xref target="Fig-Bitmap-lastWin" format="default"/> shows an exa
mple of a SCHC ACK with tile indices ranging from 6 down to 0, where integrity c
heck has not been performed or has failed and the Bitmap indicates that there is
no missing tile in that window.</t>
<figure anchor="Fig-Bitmap-lastWin">
<name>Example of a SCHC ACK 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 #)
+--------+-------+---+---+-------------+
| RuleID | DTag | W |C=0|1 1 1 1 1 1 1| with uncompressed Bitmap
+--------+-------+---+---+-------------+
next L2 Word boundary ->|
<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"/>. | RuleID | DTag | W |C=0|1| transmitted SCHC ACK
The DTag field and the W field are OPTIONAL, their presence is specified by each +-- ... -+- ... -+---+---+-+
mode and Profile. next L2 Word boundary ->|]]></artwork>
</figure>
</section>
</section>
<section anchor="ACKREQ" numbered="true" toc="default">
<name>SCHC ACK REQ 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" format="default"/>.
The DTag field and the W field are <bcp14>OPTIONAL</bcp14>, their presence is sp
ecified by each mode and Profile.
The FCN field is all zero.</t> The FCN field is all zero.</t>
<figure anchor="Fig-ACKREQ">
<figure title="SCHC ACK REQ format" anchor="Fig-ACKREQ"><artwork><![CDATA[ <name>SCHC ACK REQ Format</name>
|---- SCHC ACK REQ Header ----| <artwork name="" type="" align="left" alt=""><![CDATA[
|-- T --|-M-|-- N --| |--- SCHC ACK REQ Header ----|
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ |-- T --|-M-|-- N --|
| Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) +-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ | RuleID | DTag | W | 0..0 | padding (as needed) (no payload)
]]></artwork></figure> +-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~]]></artwork>
</figure>
</section> </section>
<section anchor="SenderAbort" title="SCHC Sender-Abort format"> <section anchor="SenderAbort" numbered="true" toc="default">
<name>SCHC Sender-Abort Format</name>
<t>When a SCHC Fragment sender needs to abort an on-going fragmented SCHC Packet <t>When a SCHC Fragment sender needs to abort an ongoing fragmented SC
transmission, it sends a SCHC Sender-Abort message to the SCHC Fragment receive HC Packet transmission, it sends a SCHC Sender-Abort message to the SCHC Fragmen
r.</t> t receiver.</t>
<t>The SCHC Sender-Abort format is shown in <xref target="Fig-SenderAb
<t>The SCHC Sender-Abort format is shown in <xref target="Fig-SenderAbort"/>. ort" format="default"/>.
The DTag field and the W field are OPTIONAL, their presence is specified by each The DTag field and the W field are <bcp14>OPTIONAL</bcp14>, their presence is sp
mode and Profile. ecified by each mode and Profile.
The FCN field is all ones.</t> The FCN field is all ones.</t>
<figure anchor="Fig-SenderAbort">
<figure title="SCHC Sender-Abort format" anchor="Fig-SenderAbort"><artwork><![CD <name>SCHC Sender-Abort Format</name>
ATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
|---- Sender-Abort Header ----| |--- Sender-Abort Header ----|
|-- T --|-M-|-- N --| |-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 11..1 | padding (as needed) | RuleID | DTag | W | 11..1 | padding (as needed)
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ +-- ... -+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~]]></artwork>
]]></artwork></figure> </figure>
<t>If the W field is present:</t>
<t>If the W field is present,</t> <ul spacing="normal">
<li>the fragment sender <bcp14>MUST</bcp14> set it to all ones.
<t><list style="symbols"> Other values are RESERVED.</li>
<t>the fragment sender MUST set it to all ones. <li>the fragment receiver <bcp14>MUST</bcp14> check its value.
Other values are RESERVED.</t> If the value is different from all ones, the message <bcp14>MUST</bcp14> be igno
<t>the fragment receiver MUST check its value. red.</li>
If the value is different from all ones, the message MUST be ignored.</t> </ul>
</list></t> <t>The SCHC Sender-Abort <bcp14>MUST NOT</bcp14> be acknowledged.</t>
</section>
<t>The SCHC Sender-Abort MUST NOT be acknowledged.</t> <section anchor="schc-receiver-abort-format" numbered="true" toc="defaul
t">
</section> <name>SCHC Receiver-Abort Format</name>
<section anchor="schc-receiver-abort-format" title="SCHC Receiver-Abort format"> <t>When a SCHC Fragment receiver needs to abort an ongoing fragmented
SCHC Packet transmission, it transmits a SCHC Receiver-Abort message to the SCHC
<t>When a SCHC Fragment receiver needs to abort an on-going fragmented SCHC Pack Fragment sender.</t>
et transmission, it transmits a SCHC Receiver-Abort message to the SCHC Fragment <t>The SCHC Receiver-Abort format is shown in <xref target="Fig-Receiv
sender.</t> erAbort" format="default"/>.
The DTag field and the W field are <bcp14>OPTIONAL</bcp14>, their presence is sp
<t>The SCHC Receiver-Abort format is shown in <xref target="Fig-ReceiverAbort"/> ecified by each mode and Profile.</t>
. <figure anchor="Fig-ReceiverAbort">
The DTag field and the W field are OPTIONAL, their presence is specified by each <name>SCHC Receiver-Abort Format</name>
mode and Profile.</t> <artwork name="" type="" align="left" alt=""><![CDATA[
|-- Receiver-Abort Header ---|
<figure title="SCHC Receiver-Abort format" anchor="Fig-ReceiverAbort"><artwork>< |--- T ---|-M-| 1 |
![CDATA[ +--- ... --+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
|--- Receiver-Abort Header ---| | RuleID | DTag | W |C=1| 1..1| 1..1 |
|--- T ---|-M-| 1 | +--- ... --+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+
+--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ next L2 Word boundary ->|<-- L2 Word -->|]]></artwork>
| Rule ID | DTag | W |C=1| 1..1| 1..1 | </figure>
+--- ... ---+-- ... --+---+---+-+-+-+-+-+-+-+-+-+-+-+ <t>If the W field is present:</t>
next L2 Word boundary ->|<-- L2 Word -->| <ul spacing="normal">
]]></artwork></figure> <li>the fragment receiver <bcp14>MUST</bcp14> set it to all ones.
Other values are RESERVED.</li>
<t>If the W field is present,</t> <li>if the value is different from all ones, the fragment sender <bc
p14>MUST</bcp14> ignore the message.</li>
<t><list style="symbols"> </ul>
<t>the fragment receiver MUST set it to all ones. <t>The SCHC Receiver-Abort has the same header as a SCHC ACK message.
Other values are RESERVED.</t> The bits that follow the SCHC Receiver-Abort Header <bcp14>MUST</bcp14> be as fo
<t>if the value is different from all ones, the fragment sender MUST ignore th llows:</t>
e message.</t> <ul spacing="normal">
</list></t> <li>if the Header does not end at an L2 Word boundary, append bits s
et to 1 as needed to reach the next L2 Word boundary.</li>
<t>The SCHC Receiver-Abort has the same header as a SCHC ACK message. <li>append exactly one more L2 Word with bits all set to ones.</li>
The bits that follow the SCHC Receiver-Abort Header MUST be as follows</t> </ul>
<t>Such a bit pattern never occurs in a legitimate SCHC ACK. This is h
<t><list style="symbols"> ow the fragment sender recognizes a SCHC Receiver-Abort.</t>
<t>if the Header does not end at an L2 Word boundary, append bits set to 1 as <t>The SCHC Receiver-Abort <bcp14>MUST NOT</bcp14> be acknowledged.</t
needed to reach the next L2 Word boundary</t> >
<t>append exactly one more L2 Word with bits all set to ones</t> </section>
</list></t> </section>
<section anchor="FragModes" numbered="true" toc="default">
<t>Such a bit pattern never occurs in a legitimate SCHC ACK. This is how the fra <name>SCHC F/R Modes</name>
gment sender recognizes a SCHC Receiver-Abort.</t> <t>This specification includes several SCHC F/R modes that:</t>
<ul spacing="normal">
<t>The SCHC Receiver-Abort MUST NOT be acknowledged.</t> <li>allow for a range of reliability options, such as optional SCHC Fr
agment retransmission.</li>
</section> <li>support various LPWAN characteristics, such as links with variable
</section> MTU or unidirectional links.</li>
<section anchor="FragModes" title="SCHC F/R modes"> </ul>
<t>More modes may be defined in the future.</t>
<t>This specification includes several SCHC F/R modes, which</t> <t><xref target="FragExamples" format="default"/> provides examples of f
ragmentation sessions based on the modes described hereafter.</t>
<t><list style="symbols"> <t><xref target="FSM" format="default"/> provides examples of Finite Sta
<t>allow for a range of reliability options, such as optional SCHC Fragment re te Machines implementing the SCHC F/R modes described hereafter.</t>
transmission</t> <section anchor="No-ACK-subsection" numbered="true" toc="default">
<t>support various LPWAN characteristics, such as links with variable MTU or u <name>No-ACK Mode</name>
nidirectional links.</t> <t>The No-ACK mode has been designed under the assumption that data un
</list></t> it out-of-sequence delivery does not occur between the entity performing fragmen
tation and the entity performing reassembly.
<t>More modes may be defined in the future.</t> This mode supports L2 technologies that have a variable MTU.</t>
<t>In No-ACK mode, there is no communication from the fragment receive
<t><xref target="FragExamples"/> provides examples of fragmentation sessions bas r to the fragment sender.
ed on the modes described hereafter.</t>
<t><xref target="FSM"/> provides examples of Finite State Machines implementing
the SCHC F/R modes described hereafter.</t>
<section anchor="No-ACK-subsection" title="No-ACK mode">
<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 technologies that have a variable MTU.</t>
<t>In No-ACK mode, there is no communication from the fragment receiver to the f
ragment sender.
The sender transmits all the SCHC Fragments without expecting any acknowledgemen t. The sender transmits all the SCHC Fragments without expecting any acknowledgemen t.
Therefore, No-ACK does not require bidirectional links: unidirectional links are just fine.</t> 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. T
<t>In No-ACK mode, only the All-1 SCHC Fragment is padded as needed. The other S he other SCHC Fragments are intrinsically aligned to L2 Words.</t>
CHC Fragments are intrinsically aligned to L2 Words.</t> <t>The tile sizes are not required to be uniform.
<t>The tile sizes are not required to be uniform.
Windows are not used. Windows are not used.
The Retransmission Timer is not used. The Retransmission Timer is not used.
The Attempts counter is not used.</t> The Attempts counter is not used.</t>
<t>Each Profile <bcp14>MUST</bcp14> specify which RuleID value(s) corr
<t>Each Profile MUST specify which Rule ID value(s) correspond to SCHC F/R messa esponds to SCHC F/R messages operating in this mode.</t>
ges operating in this mode.</t> <t>The W field <bcp14>MUST NOT</bcp14> be present in the SCHC F/R mess
ages.
<t>The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK <bcp14>MUST NOT</bcp14> be sent.
SCHC ACK MUST NOT be sent. SCHC ACK REQ <bcp14>MUST NOT</bcp14> be sent.
SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort <bcp14>MAY</bcp14> be sent.
SCHC Sender-Abort MAY be sent. SCHC Receiver-Abort <bcp14>MUST NOT</bcp14> be sent.</t>
SCHC Receiver-Abort MUST NOT be sent.</t> <t>The value of N (size of the FCN field) is <bcp14>RECOMMENDED</bcp14
> to be 1.</t>
<t>The value of N (size of the FCN field) is RECOMMENDED to be 1.</t> <t>Each Profile, for each RuleID value, <bcp14>MUST</bcp14> define:</t
>
<t>Each Profile, for each Rule ID value, MUST define</t> <ul spacing="normal">
<li>the size of the DTag field,</li>
<t><list style="symbols"> <li>the size and algorithm for the RCS field, and</li>
<t>the size of the DTag field,</t> <li>the expiration time of the Inactivity Timer.</li>
<t>the size and algorithm for the RCS field,</t> </ul>
<t>the expiration time of the Inactivity Timer</t> <t>Each Profile, for each RuleID value, <bcp14>MAY</bcp14> define</t>
</list></t> <ul spacing="normal">
<li>a value of N different from the recommended one, and</li>
<t>Each Profile, for each Rule ID value, MAY define</t> <li>the meaning of values sent in the FCN field, for values differen
t from the All-1 value.</li>
<t><list style="symbols"> </ul>
<t>a value of N different from the recommended one,</t> <t>For each active pair of RuleID and DTag values, the receiver <bcp14
<t>the meaning of values sent in the FCN field, for values different from the >MUST</bcp14> maintain an Inactivity Timer.
All-1 value.</t> If the receiver is under-resourced to do this, it <bcp14>MUST</bcp14> silently d
</list></t> rop the related messages.</t>
<section anchor="sender-behavior" numbered="true" toc="default">
<t>For each active pair of Rule ID and DTag values, the receiver MUST maintain a <name>Sender Behavior</name>
n Inactivity Timer. <t>At the beginning of the fragmentation of a new SCHC Packet, the f
If the receiver is under-resourced to do this, it MUST silently drop the related ragment sender <bcp14>MUST</bcp14> select a RuleID and DTag value pair for this
messages.</t> SCHC Packet.</t>
<t>Each SCHC Fragment <bcp14>MUST</bcp14> contain exactly one tile i
<section anchor="sender-behavior" title="Sender behavior"> n its Payload.
The tile <bcp14>MUST</bcp14> be at least the size of an L2 Word.
<t>At the beginning of the fragmentation of a new SCHC Packet, the fragment send The sender <bcp14>MUST</bcp14> transmit the SCHC Fragments messages in the order
er MUST select a Rule ID and DTag value pair for this SCHC Packet.</t> that the tiles appear in the SCHC Packet.
Except for the last tile of a SCHC Packet, each tile <bcp14>MUST</bcp14> be of a
<t>Each SCHC Fragment MUST contain exactly one tile in its Payload. size
The tile MUST be at least the size of an L2 Word.
The sender MUST 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 be of a size
that complements the SCHC Fragment Header so that complements the SCHC Fragment Header so
that the SCHC Fragment is a multiple of L2 Words without the need for padding bi ts. that the SCHC Fragment is a multiple of L2 Words without the need for padding bi ts.
Except for the last one, the SCHC Fragments MUST use the Regular SCHC Fragment f Except for the last one, the SCHC Fragments <bcp14>MUST</bcp14> use the Regular
ormat specified in <xref target="NotLastFrag"/>. SCHC Fragment format specified in <xref target="NotLastFrag" format="default"/>.
The SCHC Fragment that carries the last tile MUST be an All-1 SCHC Fragment, des The SCHC Fragment that carries the last tile <bcp14>MUST</bcp14> be an All-1 SCH
cribed in <xref target="LastFrag"/>.</t> C Fragment, described in <xref target="LastFrag" format="default"/>.</t>
<t>The sender <bcp14>MAY</bcp14> transmit a SCHC Sender-Abort.</t>
<t>The sender MAY transmit a SCHC Sender-Abort.</t> <t><xref target="Fig-NoACKModeSnd" format="default"/> shows an examp
le of a corresponding state machine.</t>
<t><xref target="Fig-NoACKModeSnd"/> shows an example of a corresponding state m </section>
achine.</t> <section anchor="receiver-behavior" numbered="true" toc="default">
<name>Receiver Behavior</name>
</section> <t>Upon receiving each Regular SCHC Fragment:</t>
<section anchor="receiver-behavior" title="Receiver behavior"> <ul spacing="normal">
<li>the receiver <bcp14>MUST</bcp14> reset the Inactivity Timer.</
<t>Upon receiving each Regular SCHC Fragment,</t> li>
<li>the receiver assembles the payloads of the SCHC Fragments.</li
<t><list style="symbols"> >
<t>the receiver MUST reset the Inactivity Timer,</t> </ul>
<t>the receiver assembles the payloads of the SCHC Fragments</t> <t>On receiving an All-1 SCHC Fragment:</t>
</list></t> <ul spacing="normal">
<li>the receiver <bcp14>MUST</bcp14> append the All-1 SCHC Fragmen
<t>On receiving an All-1 SCHC Fragment,</t> t Payload and the padding bits to the
previously received SCHC Fragment Payloads for this SCHC Packet.</li>
<t><list style="symbols"> <li>the receiver <bcp14>MUST</bcp14> perform the integrity check.<
<t>the receiver MUST append the All-1 SCHC Fragment Payload and the padding bi /li>
ts to the <li>if integrity checking fails,
previously received SCHC Fragment Payloads for this SCHC Packet</t> the receiver <bcp14>MUST</bcp14> drop the reassembled SCHC Packet.</li>
<t>the receiver MUST perform the integrity check</t> <li>the reassembly operation concludes.</li>
<t>if integrity checking fails, </ul>
the receiver MUST drop the reassembled SCHC Packet</t> <t>On expiration of the Inactivity Timer,
<t>the reassembly operation concludes.</t> the receiver <bcp14>MUST</bcp14> drop the SCHC Packet being reassembled.</t>
</list></t> <t>On receiving a SCHC Sender-Abort,
the receiver <bcp14>MAY</bcp14> drop the SCHC Packet being reassembled.</t>
<t>On expiration of the Inactivity Timer, <t><xref target="Fig-NoACKModeRcv" format="default"/> shows an examp
the receiver MUST drop the SCHC Packet being reassembled.</t> le of a corresponding state machine.</t>
</section>
<t>On receiving a SCHC Sender-Abort, </section>
the receiver MAY drop the SCHC Packet being reassembled.</t> <section anchor="ACK-Always-subsection" numbered="true" toc="default">
<name>ACK-Always Mode</name>
<t><xref target="Fig-NoACKModeRcv"/> shows an example of a corresponding state m <t>The ACK-Always mode has been designed under the following assumptio
achine.</t> ns:</t>
<ul spacing="normal">
</section> <li>Data unit out-of-sequence delivery does not occur between the en
</section> tity performing fragmentation and the entity performing reassembly,</li>
<section anchor="ACK-Always-subsection" title="ACK-Always mode"> <li>The L2 MTU value does not change while the fragments of a SCHC P
acket are being transmitted, and</li>
<t>The ACK-Always mode has been designed under the following assumptions</t> <li>There is a feedback path from the reassembler to the fragmenter.
See <xref target="AsymLinks" format="default"/> for a discussion on using ACK-Al
<t><list style="symbols"> ways mode on quasi-bidirectional links.</li>
<t>Data unit out-of-sequence delivery does not occur between the entity perfor </ul>
ming fragmentation and the entity performing reassembly</t> <t>In ACK-Always mode, windows are used.
<t>The L2 MTU value does not change while the fragments of a SCHC Packet are b
eing transmitted.</t>
<t>There is a feedback path from the reassembler to the fragmenter.
See <xref target="AsymLinks"/> for a discussion on using ACK-Always mode on quas
i-bidirectional links.</t>
</list></t>
<t>In ACK-Always mode, windows are used.
An acknowledgement, positive or negative, is transmitted by the fragment receive r to the fragment sender at the end of the transmission of each window of SCHC F ragments.</t> An acknowledgement, positive or negative, is transmitted by the fragment receive r to the fragment sender at the end of the transmission of each window of SCHC F ragments.</t>
<t>The tiles are not required to be of uniform size. In ACK-Always mod
<t>The tiles are not required to be of uniform size. In ACK-Always mode, only th e, only the All-1 SCHC Fragment is padded as needed. The other SCHC Fragments ar
e All-1 SCHC Fragment is padded as needed. The other SCHC Fragments are intrinsi e intrinsically aligned to L2 Words.</t>
cally aligned to L2 Words.</t> <t>Briefly, the algorithm is as follows: after a first blind transmiss
ion of all the tiles of a window, the fragment sender iterates retransmitting th
<t>Briefly, the algorithm is as follows: after a first blind transmission of all e tiles that are reported missing until the fragment receiver reports that all t
the tiles of a window, the fragment sender iterates retransmitting the tiles th he tiles belonging to the window have been correctly received or until too many
at are reported missing until the fragment receiver reports that all the tiles b attempts were made.
elonging to the window have been correctly received, or until too many attempts
were made.
The fragment sender only advances to the next window of tiles when it has ascert ained that all the tiles belonging to the current window have been fully and cor rectly received. This results in a per-window lock-step behavior between the sen der and the receiver.</t> The fragment sender only advances to the next window of tiles when it has ascert ained that all the tiles belonging to the current window have been fully and cor rectly received. This results in a per-window lock-step behavior between the sen der and the receiver.</t>
<t>Each Profile <bcp14>MUST</bcp14> specify which RuleID value(s) corr
<t>Each Profile MUST specify which Rule ID value(s) correspond to SCHC F/R messa espond to SCHC F/R messages operating in this mode.</t>
ges operating in this mode.</t> <t>The W field <bcp14>MUST</bcp14> be present and its size M <bcp14>MU
ST</bcp14> be 1 bit.</t>
<t>The W field MUST be present and its size M MUST be 1 bit.</t> <t>Each Profile, for each RuleID value, <bcp14>MUST</bcp14> define:</t
>
<t>Each Profile, for each Rule ID value, MUST define</t> <ul spacing="normal">
<li>the value of N,</li>
<t><list style="symbols"> <li>the value of WINDOW_SIZE, which <bcp14>MUST</bcp14> be strictly
<t>the value of N (size of the FCN field),</t> less than 2^N,</li>
<t>the value of WINDOW_SIZE, which MUST be strictly less than 2^N,</t> <li>the size and algorithm for the RCS field,</li>
<t>the size and algorithm for the RCS field,</t> <li>the value of T,</li>
<t>the size of the DTag field,</t> <li>the value of MAX_ACK_REQUESTS,</li>
<t>the value of MAX_ACK_REQUESTS,</t> <li>the expiration time of the Retransmission Timer, and</li>
<t>the expiration time of the Retransmission Timer</t> <li>the expiration time of the Inactivity Timer.</li>
<t>the expiration time of the Inactivity Timer</t> </ul>
</list></t> <t>For each active pair of RuleID and DTag values, the sender <bcp14>M
UST</bcp14> maintain:</t>
<t>For each active pair of Rule ID and DTag values, the sender MUST maintain</t> <ul spacing="normal">
<li>one Attempts counter</li>
<t><list style="symbols"> <li>one Retransmission Timer</li>
<t>one Attempts counter</t> </ul>
<t>one Retransmission Timer</t> <t>For each active pair of RuleID and DTag values, the receiver <bcp14
</list></t> >MUST</bcp14> maintain</t>
<ul spacing="normal">
<t>For each active pair of Rule ID and DTag values, the receiver MUST maintain</ <li>one Inactivity Timer, and</li>
t> <li>one Attempts counter.</li>
</ul>
<t><list style="symbols"> <section anchor="sender-behavior-1" numbered="true" toc="default">
<t>one Inactivity Timer</t> <name>Sender Behavior</name>
<t>one Attempts counter</t> <t>At the beginning of the fragmentation of a new SCHC Packet, the f
</list></t> ragment sender <bcp14>MUST</bcp14> select a RuleID and DTag value pair for this
SCHC Packet.</t>
<section anchor="sender-behavior-1" title="Sender behavior"> <t>Each SCHC Fragment <bcp14>MUST</bcp14> contain exactly one tile i
n its Payload.
<t>At the beginning of the fragmentation of a new SCHC Packet, the fragment send All tiles with the index 0, as well as the last tile, <bcp14>MUST</bcp14> be at
er MUST select a Rule ID and DTag value pair for this SCHC Packet.</t> least the size of an L2 Word.</t>
<t>In all SCHC Fragment messages, the W field <bcp14>MUST</bcp14> be
<t>Each SCHC Fragment MUST contain exactly one tile in its Payload. filled with the LSB of the window number that the sender is currently processin
All tiles with the index 0, as well as the last tile, MUST be at least the size g.</t>
of an L2 Word.</t> <t>For a SCHC Fragment that carries a tile other than the last one o
f the SCHC Packet:</t>
<t>In all SCHC Fragment messages, the W field MUST be filled with the least sign <ul spacing="normal">
ificant bit of the window number that the sender is currently processing.</t> <li>the Fragment <bcp14>MUST</bcp14> be of the Regular type specif
ied in <xref target="NotLastFrag" format="default"/>.</li>
<t>For a SCHC Fragment that carries a tile other than the last one of the SCHC P <li>the FCN field <bcp14>MUST</bcp14> contain the tile index.</li>
acket,</t> <li>each tile <bcp14>MUST</bcp14> be of a size
<t><list style="symbols">
<t>the Fragment MUST be of the Regular type specified in <xref target="NotLast
Frag"/></t>
<t>the FCN field MUST contain the tile index</t>
<t>each tile MUST be of a size
that complements the SCHC Fragment Header so that complements the SCHC Fragment Header so
that the SCHC Fragment is a multiple of L2 Words without the need for padding bi that the SCHC Fragment is a multiple of L2 Words without the need for padding bi
ts.</t> ts.</li>
</list></t> </ul>
<t>The SCHC Fragment that carries the last tile <bcp14>MUST</bcp14>
<t>The SCHC Fragment that carries the last tile MUST be an All-1 SCHC Fragment, be an All-1 SCHC Fragment, described in <xref target="LastFrag" format="default"
described in <xref target="LastFrag"/>.</t> />.</t>
<t>The fragment sender <bcp14>MUST</bcp14> start by transmitting the
<t>The fragment sender MUST start by transmitting the window numbered 0.</t> window numbered 0.</t>
<t>All message receptions being discussed in the rest of this sectio
<t>All message receptions being discussed in the rest of this section are to be n are to be understood as
understood as "matching the RuleID and DTag pair being processed", even if not spelled out, fo
“matching the RuleID and DTag pair being processed”, even if not spelled out, fo r brevity.</t>
r brevity.</t> <t>The sender starts by a "blind transmission" phase, in which it <b
cp14>MUST</bcp14> transmit all the tiles composing the window, in decreasing til
<t>The sender starts by a “blind transmission” phase, in which it MUST transmit e index order.</t>
all the tiles composing the window, in decreasing tile index order.</t> <t>Then, it enters a "retransmission phase" in which
it <bcp14>MUST</bcp14> initialize an Attempts counter to 0,
<t>Then, it enters a “retransmission phase” in which it <bcp14>MUST</bcp14> start a Retransmission Timer
it MUST initialize an Attempts counter to 0, and it <bcp14>MUST</bcp14> await a SCHC ACK. </t>
it MUST start a Retransmission Timer <ul spacing="normal">
and it MUST await a SCHC ACK. Then,</t> <li>
<t>Then, upon receiving a SCHC ACK:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>upon receiving a SCHC ACK, <list style="symbols"> <li>if the SCHC ACK indicates that some tiles are missing at t
<t>if the SCHC ACK indicates that some tiles are missing at the receiver, he receiver, then
then the sender <bcp14>MUST</bcp14> transmit all the tiles that have been reported mi
the sender MUST transmit all the tiles that have been reported missing, ssing,
it MUST increment Attempts, it <bcp14>MUST</bcp14> increment Attempts,
it MUST reset the Retransmission Timer it <bcp14>MUST</bcp14> reset the Retransmission Timer,
and MUST await the next SCHC ACK.</t> and <bcp14>MUST</bcp14> await the next SCHC ACK.</li>
<t>if the current window is not the last one and the SCHC ACK indicates th <li>if the current window is not the last one and the SCHC ACK
at all tiles were correctly received, indicates that all tiles were correctly received,
the sender MUST stop the Retransmission Timer, the sender <bcp14>MUST</bcp14> stop the Retransmission Timer,
it MUST advance to the next fragmentation window it <bcp14>MUST</bcp14> advance to the next fragmentation window,
and it MUST start a blind transmission phase as described above.</t> and it <bcp14>MUST</bcp14> start a blind transmission phase as described above.<
<t>if the current window is the last one and the SCHC ACK indicates that m /li>
ore tiles were received than the sender sent, <li>if the current window is the last one and the SCHC ACK ind
the fragment sender MUST send a SCHC Sender-Abort, icates that more tiles were received than the sender sent,
and it MAY exit with an error condition.</t> the fragment sender <bcp14>MUST</bcp14> send a SCHC Sender-Abort,
<t>if the current window is the last one and the SCHC ACK indicates that a and it <bcp14>MAY</bcp14> exit with an error condition.</li>
ll tiles were correctly received yet integrity check was a failure, <li>if the current window is the last one and the
the fragment sender MUST send a SCHC Sender-Abort, SCHC ACK indicates that all tiles were correctly
and it MAY exit with an error condition.</t> received, yet the integrity check was a failure,
<t>if the current window is the last one and the SCHC ACK indicates that i the fragment sender <bcp14>MUST</bcp14> send a SCHC Sender-Abort,
ntegrity checking was successful, and it <bcp14>MAY</bcp14> exit with an error condition.</li>
the sender exits successfully.</t> <li>if the current window is the last one and the SCHC ACK ind
</list></t> icates that integrity checking was successful,
<t>on Retransmission Timer expiration, <list style="symbols"> the sender exits successfully.</li>
<t>if Attempts is strictly less that MAX_ACK_REQUESTS, </ul>
the fragment sender MUST send a SCHC ACK REQ </li>
and MUST increment the Attempts counter.</t> <li>
<t>otherwise <t>on Retransmission Timer expiration: </t>
the fragment sender MUST send a SCHC Sender-Abort, <ul spacing="normal">
and it MAY exit with an error condition.</t> <li>if Attempts is strictly less that MAX_ACK_REQUESTS,
</list></t> the fragment sender <bcp14>MUST</bcp14> send a SCHC ACK REQ
</list></t> and <bcp14>MUST</bcp14> increment the Attempts counter.</li>
<li>otherwise,
<t>At any time,</t> the fragment sender <bcp14>MUST</bcp14> send a SCHC Sender-Abort,
and it <bcp14>MAY</bcp14> exit with an error condition.</li>
<t><list style="symbols"> </ul>
<t>on receiving a SCHC Receiver-Abort, the fragment sender MAY exit with an er </li>
ror condition.</t> </ul>
<t>on receiving a SCHC ACK that bears a W value different from the W value tha <t>At any time:</t>
t it currently uses, the fragment sender MUST silently discard and ignore that S <ul spacing="normal">
CHC ACK.</t> <li>on receiving a SCHC Receiver-Abort, the fragment sender <bcp14
</list></t> >MAY</bcp14> exit with an error condition.</li>
<li>on receiving a SCHC ACK that bears a W value different from th
<t><xref target="Fig-ACKAlwaysSnd"/> shows an example of a corresponding state m e W value that it currently uses, the fragment sender <bcp14>MUST</bcp14> silent
achine.</t> ly discard and ignore that SCHC ACK.</li>
</ul>
</section> <t><xref target="Fig-ACKAlwaysSnd" format="default"/> shows an examp
<section anchor="receiver-behavior-1" title="Receiver behavior"> le of a corresponding state machine.</t>
</section>
<t>On receiving a SCHC Fragment with a Rule ID and DTag pair not being processed <section anchor="receiver-behavior-1" numbered="true" toc="default">
at that time</t> <name>Receiver Behavior</name>
<t>On receiving a SCHC Fragment with a RuleID and DTag pair not bein
<t><list style="symbols"> g processed at that time:</t>
<t>the receiver SHOULD check if the DTag value has not recently been used for <ul spacing="normal">
that Rule ID value, <li>the receiver <bcp14>SHOULD</bcp14> check if the DTag value has
not recently been used for that RuleID value,
thereby ensuring that the received SCHC Fragment is not a remnant of a prior fra gmented SCHC Packet transmission. thereby ensuring that the received SCHC Fragment is not a remnant of a prior fra gmented SCHC Packet transmission.
The initial value of the Inactivity Timer is the RECOMMENDED lifetime for the DT The initial value of the Inactivity Timer is the <bcp14>RECOMMENDED</bcp14> life
ag value at the receiver. time for the DTag value at the receiver.
If the SCHC Fragment is determined to be such a remnant, the receiver MAY silent If the SCHC Fragment is determined to be such a remnant, the receiver <bcp14>MAY
ly ignore it and discard it.</t> </bcp14> silently ignore it and discard it.</li>
<t>the receiver MUST start a process to assemble a new SCHC Packet with that R <li>the receiver <bcp14>MUST</bcp14> start a process to assemble a
ule ID and DTag value pair.</t> new SCHC Packet with that RuleID and DTag value pair.</li>
<t>the receiver MUST start an Inactivity Timer for that RuleID and DTag pair. <li>the receiver <bcp14>MUST</bcp14> start an Inactivity Timer for
It MUST initialize an Attempts counter to 0 for that RuleID and DTag pair. that RuleID and DTag pair.
It MUST initialize a window counter to 0. It <bcp14>MUST</bcp14> initialize an Attempts counter to 0 for that RuleID and D
If the receiver is under-resourced to do this, it MUST respond to the sender wit Tag pair.
h a SCHC Receiver Abort.</t> It <bcp14>MUST</bcp14> initialize a window counter to 0.
</list></t> If the receiver is under-resourced to do this, it <bcp14>MUST</bcp14> respond to
the sender with a SCHC Receiver-Abort.</li>
<t>In the rest of this section, “local W bit” means the least significant bit of </ul>
the window counter of the receiver.</t> <t>In the rest of this section, "local W bit" means the least signif
icant 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 proce <t>On reception of any SCHC F/R message for the RuleID and DTag pair
ssed, the receiver MUST reset the Inactivity Timer pertaining to that RuleID and being processed, the receiver <bcp14>MUST</bcp14> reset the Inactivity Timer pe
DTag pair.</t> rtaining to that RuleID and DTag pair.</t>
<t>All message receptions being discussed in the rest of this sectio
<t>All message receptions being discussed in the rest of this section are to be n are to be understood as
understood as "matching the RuleID and DTag pair being processed", even if not spelled out, fo
“matching the RuleID and DTag pair being processed”, even if not spelled out, fo r brevity.</t>
r brevity.</t> <t>The receiver <bcp14>MUST</bcp14> first initialize an empty Bitmap
for the first window then
<t>The receiver MUST first initialize an empty Bitmap for the first window, then enter an "acceptance phase", in which:</t>
enter an “acceptance phase”, in which</t> <ul spacing="normal">
<li>on receiving a SCHC Fragment or a SCHC ACK REQ, either one hav
<t><list style="symbols"> ing the W bit different from the local W bit,
<t>on receiving a SCHC Fragment or a SCHC ACK REQ, either one having the W bit the receiver <bcp14>MUST</bcp14> silently ignore and discard that message.</li>
different from the local W bit, <li>on receiving a SCHC ACK REQ with the W bit equal to the local
the receiver MUST silently ignore and discard that message.</t> W bit,
<t>on receiving a SCHC ACK REQ with the W bit equal to the local W bit, the receiver <bcp14>MUST</bcp14> send a SCHC ACK for this window.</li>
the receiver MUST send a SCHC ACK for this window.</t> <li>
<t>on receiving a SCHC Fragment with the W bit equal to the local W bit, <t>on receiving a SCHC Fragment with the W bit equal to the loca
the receiver MUST assemble the received tile based on the window counter and on l W bit,
the FCN field in the SCHC Fragment the receiver <bcp14>MUST</bcp14> assemble the received tile based on the window
and it MUST update the Bitmap. counter and on the FCN field in the SCHC Fragment,
<list style="symbols"> and it <bcp14>MUST</bcp14> update the Bitmap.
<t>if the SCHC Fragment received is an All-0 SCHC Fragment, </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 current window is determined to be a not-last window,
the receiver MUST send a SCHC ACK for this window the receiver <bcp14>MUST</bcp14> send a SCHC ACK for this window
and it MUST enter the “retransmission phase” for this window.</t> and it <bcp14>MUST</bcp14> enter the "retransmission phase" for this window.</li
<t>if the SCHC Fragment received is an All-1 SCHC Fragment, >
the padding bits of the All-1 SCHC Fragment MUST be assembled after the received <li>
tile,
the current window is determined to be the last window,
the receiver MUST perform the integrity check
and it MUST send a SCHC ACK for this window. Then, <list style="symbols">
<t>If the integrity check indicates that the full SCHC Packet has been
correctly reassembled,
the receiver MUST enter the “clean-up phase” for this window.</t>
<t>If the integrity check indicates that the full SCHC Packet has not
been correctly reassembled,
the receiver enters the “retransmission phase” for this window.</t>
</list></t>
</list></t>
</list></t>
<t>In the “retransmission phase”:</t>
<t><list style="symbols"> <t>if the SCHC Fragment received is an All-1 SCHC Fragment,
<t>if the window is a not-last window <list style="symbols"> the current window is determined to be the last window,
<t>on receiving a SCHC Fragment that is not All-0 or All-1 and that has a the padding bits of the All-1 SCHC Fragment <bcp14>MUST</bcp14> be assembled aft
W bit different from the local W bit, er the received tile,
the receiver MUST increment its window counter and allocate a fresh Bitmap, the receiver <bcp14>MUST</bcp14> perform the integrity check
it MUST assemble the tile received and update the Bitmap and it <bcp14>MUST</bcp14> send a SCHC ACK for this window. Then: </t>
and it MUST enter the “acceptance phase” for that new window.</t> <ul spacing="normal">
<t>on receiving a SCHC ACK REQ with a W bit different from the local W bit <li>If the integrity check indicates that the full SCHC Pa
, cket has been correctly reassembled,
the receiver MUST increment its window counter and allocate a fresh Bitmap, the receiver <bcp14>MUST</bcp14> enter the "clean-up phase" for this window.</li
it MUST send a SCHC ACK for that new window >
and it MUST enter the “acceptance phase” for that new window.</t> <li>If the integrity check indicates that the full SCHC Pa
<t>on receiving a SCHC All-0 Fragment with a W bit different from the loca cket has not been correctly reassembled,
l W bit, the receiver enters the "retransmission phase" for this window.</li>
the receiver MUST increment its window counter and allocate a fresh Bitmap, </ul>
it MUST assemble the tile received and update the Bitmap, </li>
it MUST send a SCHC ACK for that new window </ul>
and it MUST stay in the “retransmission phase” for that new window.</t> </li>
<t>on receiving a SCHC All-1 Fragment with a W bit different from the loca </ul>
l W bit, <t>In the "retransmission phase":</t>
the receiver MUST increment its window counter and allocate a fresh Bitmap, <ul spacing="normal">
it MUST assemble the tile received, <li>
including the padding bits, <t>if the window is a not-last window:</t>
it MUST update the Bitmap and perform the integrity check, <ul spacing="normal">
it MUST send a SCHC ACK for the new window, <li>on receiving a SCHC Fragment that is not All-0 or All-1 an
which is determined to be the last window. Then, <list style="symbols"> d that has a W bit different from the local W bit,
<t>If the integrity check indicates that the full SCHC Packet has been the receiver <bcp14>MUST</bcp14> increment its window counter and allocate a fre
correctly reassembled, sh Bitmap,
the receiver MUST enter the “clean-up phase” for that new window.</t> it <bcp14>MUST</bcp14> assemble the tile received and update the Bitmap,
<t>If the integrity check indicates that the full SCHC Packet has not and it <bcp14>MUST</bcp14> enter the "acceptance phase" for that new window.</li
been correctly reassembled, >
the receiver enters the “retransmission phase” for that new window.</t> <li>on receiving a SCHC ACK REQ with a W bit different from th
</list></t> e local W bit,
<t>on receiving a SCHC Fragment with a W bit equal to the local W bit, the receiver <bcp14>MUST</bcp14> increment its window counter and allocate a fre
<list style="symbols"> sh Bitmap,
<t>if the SCHC Fragment received is an All-1 SCHC Fragment, it <bcp14>MUST</bcp14> send a SCHC ACK for that new window,
the receiver MUST silently ignore it and discard it.</t> and it <bcp14>MUST</bcp14> enter the "acceptance phase" for that new window.</li
<t>otherwise, >
the receiver MUST assemble the tile received and update the Bitmap. <li>on receiving a SCHC All-0 Fragment with a W bit different
If the Bitmap becomes fully populated with 1’s or if the SCHC Fragment is an All from the local W bit,
-0, the receiver <bcp14>MUST</bcp14> increment its window counter and allocate a fre
the receiver MUST send a SCHC ACK for this window.</t> sh Bitmap,
</list></t> it <bcp14>MUST</bcp14> assemble the tile received and update the Bitmap,
<t>on receiving a SCHC ACK REQ with the W bit equal to the local W bit, it <bcp14>MUST</bcp14> send a SCHC ACK for that new window,
the receiver MUST send a SCHC ACK for this window.</t> and it <bcp14>MUST</bcp14> stay in the "retransmission phase" for that new windo
</list></t> w.</li>
<t>if the window is the last window <list style="symbols"> <li>
<t>on receiving a SCHC Fragment or a SCHC ACK REQ, either one having a W b <t>on receiving a SCHC All-1 Fragment with a W bit different
it different from the local W bit, from the local W bit,
the receiver MUST silently ignore and discard that message.</t> the receiver <bcp14>MUST</bcp14> increment its window counter and allocate a fre
<t>on receiving a SCHC ACK REQ with the W bit equal to the local W bit, sh Bitmap;
the receiver MUST send a SCHC ACK for this window.</t> it <bcp14>MUST</bcp14> assemble the tile received,
<t>on receiving a SCHC Fragment with a W bit equal to the local W bit, including the padding bits;
<list style="symbols"> it <bcp14>MUST</bcp14> update the Bitmap and perform the integrity check;
<t>if the SCHC Fragment received is an All-0 SCHC Fragment, it <bcp14>MUST</bcp14> send a SCHC ACK for the new window,
the receiver MUST silently ignore it and discard it.</t> which is determined to be the last window. Then:</t>
<t>otherwise, the receiver MUST update the Bitmap <ul spacing="normal">
and it MUST assemble the tile received. <li>If the integrity check indicates that the full SCHC Pa
cket has been correctly reassembled,
the receiver <bcp14>MUST</bcp14> enter the "clean-up phase" for that new window.
</li>
<li>If the integrity check indicates that the full SCHC Pa
cket has not been correctly reassembled,
the receiver enters the "retransmission phase" for that new window.</li>
</ul>
</li>
<li>
<t>on receiving a SCHC Fragment with a W bit equal to the lo
cal W bit:</t>
<ul spacing="normal">
<li>if the SCHC Fragment received is an All-1 SCHC Fragmen
t,
the receiver <bcp14>MUST</bcp14> silently ignore it and discard it.</li>
<li>otherwise,
the receiver <bcp14>MUST</bcp14> assemble the tile received and update the Bitma
p.
If the Bitmap becomes fully populated with 1's or if the SCHC Fragment is an All
-0,
the receiver <bcp14>MUST</bcp14> send a SCHC ACK for this window.</li>
</ul>
</li>
<li>on receiving a SCHC ACK REQ with the W bit equal to the lo
cal W bit,
the receiver <bcp14>MUST</bcp14> send a SCHC ACK for this window.</li>
</ul>
</li>
<li>
<t>if the window is the last 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 <bcp14>MUST</bcp14> silently ignore and discard that message.</li>
<li>on receiving a SCHC ACK REQ with the W bit equal to the lo
cal W bit,
the receiver <bcp14>MUST</bcp14> send a SCHC ACK for this window.</li>
<li>
<t>on receiving a SCHC Fragment with a W bit equal to the lo
cal W bit:</t>
<ul spacing="normal">
<li>if the SCHC Fragment received is an All-0 SCHC Fragmen
t,
the receiver <bcp14>MUST</bcp14> silently ignore it and discard it.</li>
<li>
<t>otherwise, the receiver <bcp14>MUST</bcp14> update th
e Bitmap,
and it <bcp14>MUST</bcp14> assemble the tile received.
If the SCHC Fragment received is an All-1 SCHC Fragment, If the SCHC Fragment received is an All-1 SCHC Fragment,
the receiver MUST assemble the padding bits of the All-1 SCHC Fragment after the the receiver <bcp14>MUST</bcp14> assemble the padding bits of the All-1 SCHC Fra
received tile, gment after the received tile,
it MUST perform the integrity check and <list style="symbols"> it <bcp14>MUST</bcp14> perform the integrity check and:</t>
<t>if the integrity check indicates that the full SCHC Packet has <ul spacing="normal">
been correctly reassembled, <li>if the integrity check indicates that the full SCH
the receiver MUST send a SCHC ACK C Packet has been correctly reassembled,
and it enters the “clean-up phase”.</t> the receiver <bcp14>MUST</bcp14> send a SCHC ACK
<t>if the integrity check indicates that the full SCHC Packet has and it enters the "clean-up phase".</li>
not been correctly reassembled, <li>
<list style="symbols"> <t>if the integrity check indicates that the full SC
<t>if the SCHC Fragment received was an All-1 SCHC Fragment, t HC Packet has not been correctly reassembled:
he receiver MUST send a SCHC ACK for this window.</t> </t>
</list></t> <ul spacing="normal">
</list></t> <li>if the SCHC Fragment received was an All-1 SCH
</list></t> C Fragment, the receiver <bcp14>MUST</bcp14> send a SCHC ACK for this window.</l
</list></t> i>
</list></t> </ul>
</li>
<t>In the “clean-up phase”:</t> </ul>
</li>
<t><list style="symbols"> </ul>
<t>On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, either one having th </li>
e W bit equal to the local W bit, the receiver MUST send a SCHC ACK.</t> </ul>
<t>Any other SCHC Fragment received MUST be silently ignored and discarded.</t </li>
> </ul>
</list></t> <t>In the "clean-up phase":</t>
<ul spacing="normal">
<t>At any time, <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 <bcp14>MUST</bcp14>
send a SCHC ACK.</li>
<li>Any other SCHC Fragment received <bcp14>MUST</bcp14> be silent
ly ignored and discarded.</li>
</ul>
<t>At any time,
on sending a SCHC ACK, on sending a SCHC ACK,
the receiver MUST increment the Attempts counter.</t> the receiver <bcp14>MUST</bcp14> increment the Attempts counter.</t>
<t>At any time,
<t>At any time,
on incrementing its window counter, on incrementing its window counter,
the receiver MUST reset the Attempts counter.</t> the receiver <bcp14>MUST</bcp14> reset the Attempts counter.</t>
<t>At any time,
<t>At any time,
on expiration of the Inactivity Timer, on expiration of the Inactivity Timer,
on receiving a SCHC Sender-Abort or on receiving a SCHC Sender-Abort or
when Attempts reaches MAX_ACK_REQUESTS, when Attempts reaches MAX_ACK_REQUESTS,
the receiver MUST send a SCHC Receiver-Abort the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort,
and it MAY exit the receive process for that SCHC Packet.</t> and it <bcp14>MAY</bcp14> exit the receive process for that SCHC Packet.</t>
<t><xref target="Fig-ACKAlwaysRcv" format="default"/> shows an examp
<t><xref target="Fig-ACKAlwaysRcv"/> shows an example of a corresponding state m le of a corresponding state machine.</t>
achine.</t> </section>
</section>
</section> <section anchor="ACK-on-Error-subsection" numbered="true" toc="default">
</section> <name>ACK-on-Error Mode</name>
<section anchor="ACK-on-Error-subsection" title="ACK-on-Error mode"> <t>The ACK-on-Error mode supports L2 technologies that have variable M
TU and out-of-order delivery.
<t>The ACK-on-Error mode supports LPWAN technologies that have variable MTU and It requires an L2 that provides a feedback path from the reassembler to the frag
out-of-order delivery. menter.
It operates with links that provide a feedback path from the reassembler to the See <xref target="AsymLinks" format="default"/> for a discussion on using ACK-on
fragmenter. -Error mode on quasi-bidirectional links.</t>
See <xref target="AsymLinks"/> for a discussion on using ACK-on-Error mode on qu <t>In ACK-on-Error mode, windows are used.</t>
asi-bidirectional links.</t> <t>All tiles except the last one and the penultimate one <bcp14>MUST</
bcp14> be of equal size, hereafter called "regular".
<t>In ACK-on-Error mode, windows are used.</t> The size of the last tile <bcp14>MUST</bcp14> be smaller than or equal to the re
gular tile size.
<t>All tiles, but the last one and the penultimate one, MUST be of equal size, h Regarding the penultimate tile, a Profile <bcp14>MUST</bcp14> pick one of the fo
ereafter called “regular”. llowing two options:</t>
The size of the last tile MUST be smaller than or equal to the regular tile size <ul spacing="normal">
. <li>The penultimate tile size <bcp14>MUST</bcp14> be the
Regarding the penultimate tile, a Profile MUST pick one of the following two opt regular tile size, or</li>
ions:</t> <li>the penultimate tile size <bcp14>MUST</bcp14> be either the regu
lar tile size or the regular tile size minus one L2 Word.</li>
<t><list style="symbols"> </ul>
<t>The penultimate tile size MUST be the regular tile size</t> <t>A SCHC Fragment message carries one or several contiguous tiles, wh
<t>or the penultimate tile size MUST be either the regular tile size or the re ich may span multiple windows.
gular tile size minus one L2 Word.</t>
</list></t>
<t>A SCHC Fragment message carries one or several contiguous tiles, which may sp
an multiple windows.
A SCHC ACK reports on the reception of exactly one window of tiles.</t> A SCHC ACK reports on the reception of exactly one window of tiles.</t>
<t>See <xref target="Fig-TilesACKonError" format="default"/> for an ex
ample.</t>
<figure anchor="Fig-TilesACKonError">
<name>SCHC Packet Fragmented in Tiles, ACK-on-Error Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------------------------------------...-----------+
| SCHC Packet |
+---------------------------------------------...-----------+
<t>See <xref target="Fig-TilesACKonError"/> for an example.</t> Tile# | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window# |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
<figure title="a SCHC Packet fragmented in tiles, ACK-on-Error mode" anchor="Fig
-TilesACKonError"><artwork><![CDATA[
+---------------------------------------------...-----------+
| SCHC Packet |
+---------------------------------------------...-----------+
Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3|
Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-|
SCHC Fragment msg |-----------|
]]></artwork></figure>
<t>The W field is wide enough that it unambiguously represents an absolute windo SCHC Fragment msg |-----------|]]></artwork>
w number. </figure>
<t>The W field is wide enough that it unambiguously represents an abso
lute window number.
The fragment receiver sends SCHC ACKs to the fragment sender about windows for w hich tiles are missing. The fragment receiver sends SCHC ACKs to the fragment sender about windows for w hich tiles are missing.
No SCHC ACK is sent by the fragment receiver for windows that it knows have been fully received.</t> 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 r
<t>The fragment sender retransmits SCHC Fragments for tiles that are reported mi eported missing.
ssing.
It can advance to next windows even before it has ascertained that all tiles bel onging to previous windows have been correctly received, It can advance to next windows even before it has ascertained that all tiles bel onging to previous windows have been correctly received,
and can still later retransmit SCHC Fragments with tiles belonging to previous w indows. and it can still later retransmit SCHC Fragments with tiles belonging to previou s windows.
Therefore, the sender and the receiver may operate in a decoupled fashion. Therefore, the sender and the receiver may operate in a decoupled fashion.
The fragmented SCHC Packet transmission concludes when</t> The fragmented SCHC Packet transmission concludes when:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>integrity checking shows that the fragmented SCHC Packet has bee
<t>integrity checking shows that the fragmented SCHC Packet has been correctly n correctly reassembled at the receive end,
reassembled at the receive end, and this information has been conveyed back to the sender, or</li>
and this information has been conveyed back to the sender,</t> <li>too many retransmission attempts were made, or</li>
<t>or too many retransmission attempts were made,</t> <li>the receiver determines that the transmission of this fragmented
<t>or the receiver determines that the transmission of this fragmented SCHC Pa SCHC Packet has been inactive for too long.</li>
cket has been inactive for too long.</t> </ul>
</list></t> <t>Each Profile <bcp14>MUST</bcp14> specify which RuleID value(s) corr
esponds to SCHC F/R messages operating in this mode.</t>
<t>Each Profile MUST specify which Rule ID value(s) correspond to SCHC F/R messa <t>The W field <bcp14>MUST</bcp14> be present in the SCHC F/R messages
ges operating in this mode.</t> .</t>
<t>Each Profile, for each RuleID value, <bcp14>MUST</bcp14> define:</t
<t>The W field MUST be present in the SCHC F/R messages.</t> >
<ul spacing="normal">
<t>Each Profile, for each Rule ID value, MUST define</t> <li>the tile size (a tile does not need to be multiple of an L2 Word
, but it <bcp14>MUST</bcp14> be at least the size of an L2 Word),</li>
<t><list style="symbols"> <li>the value of M,</li>
<t>the tile size (a tile does not need to be multiple of an L2 Word, but it MU <li>the value of N,</li>
ST be at least the size of an L2 Word)</t> <li>the value of WINDOW_SIZE, which <bcp14>MUST</bcp14> be strictly
<t>the value of M (size of the W field),</t> less than 2^N,</li>
<t>the value of N (size of the FCN field),</t> <li>the size and algorithm for the RCS field,</li>
<t>the value of WINDOW_SIZE, which MUST be strictly less than 2^N,</t> <li>the value of T,</li>
<t>the size and algorithm for the RCS field,</t> <li>the value of MAX_ACK_REQUESTS,</li>
<t>the size of the DTag field,</t> <li>the expiration time of the Retransmission Timer,</li>
<t>the value of MAX_ACK_REQUESTS,</t> <li>the expiration time of the Inactivity Timer,</li>
<t>the expiration time of the Retransmission Timer</t> <li>if the last tile is carried in a Regular SCHC Fragment or an All
<t>the expiration time of the Inactivity Timer</t> -1 SCHC Fragment (see <xref target="ACK-on-Error-sender" format="default"/>), an
<t>whether the last tile is carried in a Regular SCHC Fragment or an All-1 SCH d</li>
C Fragment (see <xref target="ACK-on-Error-sender"/>)</t> <li>if the penultimate tile <bcp14>MAY</bcp14> be one L2 Word smalle
<t>if the penultimate tile MAY be one L2 Word smaller than the regular tile si r than the regular tile size. In this case, the regular tile size <bcp14>MUST</b
ze. In this case, the regular tile size MUST be at least twice the L2 Word size. cp14> be at least twice the L2 Word size.</li>
</t> </ul>
</list></t> <t>For each active pair of RuleID and DTag values, the sender <bcp14>M
UST</bcp14> maintain:</t>
<t>For each active pair of Rule ID and DTag values, the sender MUST maintain</t> <ul spacing="normal">
<li>one Attempts counter, and</li>
<t><list style="symbols"> <li>one Retransmission Timer.</li>
<t>one Attempts counter</t> </ul>
<t>one Retransmission Timer</t> <t>For each active pair of RuleID and DTag values, the receiver <bcp14
</list></t> >MUST</bcp14> maintain:</t>
<ul spacing="normal">
<t>For each active pair of Rule ID and DTag values, the receiver MUST maintain</ <li>one Inactivity Timer, and</li>
t> <li>one Attempts counter.</li>
</ul>
<t><list style="symbols"> <section anchor="ACK-on-Error-sender" numbered="true" toc="default">
<t>one Inactivity Timer</t> <name>Sender Behavior</name>
<t>one Attempts counter</t> <t>At the beginning of the fragmentation of a new SCHC Packet:</t>
</list></t> <ul spacing="normal">
<li>the fragment sender <bcp14>MUST</bcp14> select a RuleID and DT
<section anchor="ACK-on-Error-sender" title="Sender behavior"> ag value pair for this SCHC Packet.
A Rule <bcp14>MUST NOT</bcp14> be selected if the values of M and WINDOW_SIZE fo
<t>At the beginning of the fragmentation of a new SCHC Packet,</t> r that Rule are such that the SCHC Packet cannot be fragmented in (2^M) * WINDOW
_SIZE tiles or less.</li>
<t><list style="symbols"> <li>the fragment sender <bcp14>MUST</bcp14> initialize the Attempt
<t>the fragment sender MUST select a Rule ID and DTag value pair for this SCHC s counter to 0 for that RuleID and DTag value pair.</li>
Packet. </ul>
A Rule MUST NOT be selected if the values of M and WINDOW_SIZE for that Rule are <t>A Regular SCHC Fragment message carries in its payload one or mor
such that the SCHC Packet cannot be fragmented in (2^M) * WINDOW_SIZE tiles or e tiles.
less.</t> If more than one tile is carried in one Regular SCHC Fragment:</t>
<t>the fragment sender MUST initialize the Attempts counter to 0 for that Rule <ul spacing="normal">
ID and DTag value pair.</t> <li>the selected tiles <bcp14>MUST</bcp14> be contiguous in the or
</list></t> iginal SCHC Packet, and</li>
<li>they <bcp14>MUST</bcp14> be placed in the SCHC Fragment Payloa
<t>A Regular SCHC Fragment message carries in its payload one or more tiles. d adjacent to one another, in the order they appear in the SCHC Packet, from the
If more than one tile is carried in one Regular SCHC Fragment</t> start of the SCHC Packet toward its end.</li>
</ul>
<t><list style="symbols"> <t>Tiles that are not the last one <bcp14>MUST</bcp14> be sent in Re
<t>the selected tiles MUST be contiguous in the original SCHC Packet</t> gular SCHC Fragments specified in <xref target="NotLastFrag" format="default"/>.
<t>they MUST be placed in the SCHC Fragment Payload adjacent to one another, i The FCN field <bcp14>MUST</bcp14> contain the tile index of the first tile sent
n the order they appear in the SCHC Packet, from the start of the SCHC Packet to in that SCHC Fragment.</t>
ward its end.</t> <t>In a Regular SCHC Fragment message, the sender <bcp14>MUST</bcp14
</list></t> > fill the W field with the window number of the first tile sent in that SCHC Fr
agment.</t>
<t>Tiles that are not the last one MUST be sent in Regular SCHC Fragments specif <t>A Profile <bcp14>MUST</bcp14> define if the last tile of a SCHC P
ied in <xref target="NotLastFrag"/>. acket is sent:</t>
The FCN field MUST contain the tile index of the first tile sent in that SCHC Fr <ul spacing="normal">
agment.</t> <li>in a Regular SCHC Fragment, alone or as part of a multi-tiles
Payload,</li>
<t>In a Regular SCHC Fragment message, the sender MUST fill the W field with the <li>alone in an All-1 SCHC Fragment, or</li>
window number of the first tile sent in that SCHC Fragment.</t> <li>with any of the above two methods.</li>
</ul>
<t>Depending on the Profile, the last tile of a SCHC Packet MUST be sent either< <t>In an All-1 SCHC Fragment message, the sender <bcp14>MUST</bcp14>
/t> fill the W field with the window number of the last tile of the SCHC Packet.</t
>
<t><list style="symbols"> <t>The fragment sender <bcp14>MUST</bcp14> send SCHC Fragments such
<t>in a Regular SCHC Fragment, alone or as part of a multi-tiles Payload</t> that, all together, they contain all the tiles of the fragmented SCHC Packet.</t
<t>alone in an All-1 SCHC Fragment</t> >
</list></t> <t>The fragment sender <bcp14>MUST</bcp14> send at least one All-1 S
CHC Fragment.</t>
<t>In an All-1 SCHC Fragment message, the sender MUST fill the W field with the <t>In doing the two items above, the sender <bcp14>MUST</bcp14> asce
window number of the last tile of the SCHC Packet.</t> rtain that the receiver will not receive the last tile through both a Regular SC
HC Fragment and an All-1 SCHC Fragment.</t>
<t>The fragment sender MUST send SCHC Fragments such that, all together, they co <t>The fragment sender <bcp14>MUST</bcp14> listen for SCHC ACK messa
ntain all the tiles of the fragmented SCHC Packet.</t> ges after having sent:</t>
<ul spacing="normal">
<t>The fragment sender MUST send at least one All-1 SCHC Fragment.</t> <li>an All-1 SCHC Fragment, or</li>
<li>a SCHC ACK REQ.</li>
<t>The fragment sender MUST listen for SCHC ACK messages after having sent</t> </ul>
<t>A Profile <bcp14>MAY</bcp14> specify other times at which the fra
<t><list style="symbols"> gment sender <bcp14>MUST</bcp14> listen for SCHC ACK messages.
<t>an All-1 SCHC Fragment</t>
<t>or a SCHC ACK REQ.</t>
</list></t>
<t>A Profile MAY specify other times at which the fragment sender MUST listen fo
r SCHC ACK messages.
For example, this could be after sending a complete window of tiles.</t> 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 SCH
<t>Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC ACK REQ,</ C ACK REQ:</t>
t> <ul spacing="normal">
<li>it <bcp14>MUST</bcp14> increment the Attempts counter, and</li
<t><list style="symbols"> >
<t>it MUST increment the Attempts counter</t> <li>it <bcp14>MUST</bcp14> reset the Retransmission Timer.</li>
<t>it MUST reset the Retransmission Timer</t> </ul>
</list></t> <t>On Retransmission Timer expiration:</t>
<ul spacing="normal">
<t>On Retransmission Timer expiration</t> <li>if the Attempts counter is strictly less than MAX_ACK_REQUESTS
,
<t><list style="symbols"> the fragment sender <bcp14>MUST</bcp14> send
<t>if Attempts is strictly less than MAX_ACK_REQUESTS,
the fragment sender MUST send
either the All-1 SCHC Fragment or either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window,</t> a SCHC ACK REQ with the W field corresponding to the last window,</li>
<t>otherwise the fragment sender MUST send a SCHC Sender-Abort and <li>otherwise, the fragment sender <bcp14>MUST</bcp14> send a SCHC
it MAY exit with an error condition.</t> Sender-Abort, and
</list></t> it <bcp14>MAY</bcp14> exit with an error condition.</li>
</ul>
<t>All message receptions being discussed in the rest of this section are to be <t>All message receptions being discussed in the rest of this sectio
understood as n are to be understood as
“matching the RuleID and DTag pair being processed”, even if not spelled out, fo "matching the RuleID and DTag pair being processed", even if not spelled out, fo
r brevity.</t> r brevity.</t>
<t>On receiving a SCHC ACK:</t>
<t>On receiving a SCHC ACK,</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>if the W field in the SCHC ACK corresponds to the last window
<t>if the W field in the SCHC ACK corresponds to the last window of the SCHC P of the SCHC Packet:</t>
acket, <list style="symbols"> <ul spacing="normal">
<t>if the C bit is set, the sender MAY exit successfully</t> <li>if the C bit is set, the sender <bcp14>MAY</bcp14> exit su
<t>otherwise, <list style="symbols"> ccessfully.</li>
<t>if the Profile mandates that the last tile be sent in an All-1 SCHC <li>
Fragment, <list style="symbols"> <t>otherwise: </t>
<t>if the SCHC ACK shows no missing tile at the receiver, the send <ul spacing="normal">
er <list style="symbols"> <li>
<t>MUST send a SCHC Sender-Abort</t> <t>if the Profile mandates that the last tile be sent in
<t>MAY exit with an error condition</t> an All-1 SCHC Fragment:</t>
</list></t> <ul spacing="normal">
<t>otherwise <list style="symbols"> <li>
<t>the fragment sender MUST send SCHC Fragment messages contai <t>if the SCHC ACK shows no missing tile at the rece
ning all the tiles that are reported missing in the SCHC ACK.</t> iver, the sender:</t>
<t>if the last of these SCHC Fragment messages is not an All-1 <ul spacing="normal">
SCHC Fragment, <li><bcp14>MUST</bcp14> send a SCHC Sender-Abort,
then the fragment sender MUST in addition send after it a SCHC ACK REQ with the and</li>
W field corresponding to the last window.</t> <li><bcp14>MAY</bcp14> exit with an error conditio
</list></t> n.</li>
</list></t> </ul>
<t>otherwise, <list style="symbols"> </li>
<t>if the SCHC ACK shows no missing tile at the receiver, the send <li>
er <t>otherwise:</t>
MUST send the All-1 SCHC Fragment</t> <ul spacing="normal">
<t>otherwise <list style="symbols"> <li>the fragment sender <bcp14>MUST</bcp14> send S
<t>the fragment sender MUST send SCHC Fragment messages contai CHC Fragment messages containing all the tiles that are reported missing in the
ning all the tiles that are reported missing in the SCHC ACK.</t> SCHC ACK.</li>
<t>the fragment sender MUST then send <li>if the last of these SCHC Fragment messages is
not an All-1 SCHC Fragment,
then the fragment sender <bcp14>MUST</bcp14> in addition send after it a SCHC AC
K REQ with the W field corresponding to the last window.</li>
<li>in doing the two items above, the sender <bcp1
4>MUST</bcp14> ascertain that the receiver will not receive the last tile throug
h 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 recei
ver, the sender
<bcp14>MUST</bcp14> send the All-1 SCHC Fragment</li>
<li>
<t>otherwise:</t>
<ul spacing="normal">
<li>the fragment sender <bcp14>MUST</bcp14> send S
CHC Fragment messages containing all the tiles that are reported missing in the
SCHC ACK.</li>
<li>the fragment sender <bcp14>MUST</bcp14> then s
end
either the All-1 SCHC Fragment or either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window.</t> a SCHC ACK REQ with the W field corresponding to the last window.</li>
</list></t> </ul>
</list></t> </li>
</list></t> </ul>
</list></t> </li>
<t>otherwise, the fragment sender <list style="symbols"> </ul>
<t>MUST send SCHC Fragment messages containing the tiles that are reported </li>
missing in the SCHC ACK</t> </ul>
<t>then it MAY send a SCHC ACK REQ with the W field corresponding to the l </li>
ast window</t> <li>
</list></t> <t>otherwise, the fragment sender:</t>
</list></t> <ul spacing="normal">
<li><bcp14>MUST</bcp14> send SCHC Fragment messages containing
<t>See <xref target="Fig-ACKonerrorSnd"/> for one among several possible example the tiles that are reported missing in the SCHC ACK.</li>
s of a Finite State Machine implementing a sender behavior obeying this specific <li>then, it <bcp14>MAY</bcp14> send a SCHC ACK REQ with the W
ation.</t> field corresponding to the last window.</li>
</ul>
</section> </li>
<section anchor="ACK-on-Error-receiver" title="Receiver behavior"> </ul>
<t>See <xref target="Fig-ACKonerrorSnd" format="default"/> for one a
<t>On receiving a SCHC Fragment with a Rule ID and DTag pair not being processed mong several possible examples of a Finite State Machine implementing a sender b
at that time</t> ehavior obeying this specification.</t>
</section>
<t><list style="symbols"> <section anchor="ACK-on-Error-receiver" numbered="true" toc="default">
<t>the receiver SHOULD check if the DTag value has not recently been used for <name>Receiver Behavior</name>
that Rule ID value, <t>On receiving a SCHC Fragment with a RuleID and DTag pair not bein
g processed at that time:</t>
<ul spacing="normal">
<li>the receiver <bcp14>SHOULD</bcp14> check if the DTag value has
not recently been used for that RuleID value,
thereby ensuring that the received SCHC Fragment is not a remnant of a prior fra gmented SCHC Packet transmission. thereby ensuring that the received SCHC Fragment is not a remnant of a prior fra gmented SCHC Packet transmission.
The initial value of the Inactivity Timer is the RECOMMENDED lifetime for the DT The initial value of the Inactivity Timer is the <bcp14>RECOMMENDED</bcp14> life
ag value at the receiver. time for the DTag value at the receiver.
If the SCHC Fragment is determined to be such a remnant, the receiver MAY silent If the SCHC Fragment is determined to be such a remnant, the receiver <bcp14>MAY
ly ignore it and discard it.</t> </bcp14> silently ignore it and discard it.</li>
<t>the receiver MUST start a process to assemble a new SCHC Packet with that R <li>the receiver <bcp14>MUST</bcp14> start a process to assemble a
ule ID and DTag value pair. new SCHC Packet with that RuleID and DTag value pair.
The receiver MUST start an Inactivity Timer for that Rule ID and DTag value pair The receiver <bcp14>MUST</bcp14> start an Inactivity Timer for that RuleID and D
. Tag value pair.
It MUST initialize an Attempts counter to 0 for that Rule ID and DTag value pair It <bcp14>MUST</bcp14> initialize an Attempts counter to 0 for that RuleID and D
. Tag value pair.
If the receiver is under-resourced to do this, it MUST respond to the sender wit If the receiver is under-resourced to do this, it <bcp14>MUST</bcp14> respond to
h a SCHC Receiver Abort.</t> the sender with a SCHC Receiver-Abort.</li>
</list></t> </ul>
<t>On reception of any SCHC F/R message for the RuleID and DTag pair
<t>On reception of any SCHC F/R message for the RuleID and DTag pair being proce being processed, the receiver <bcp14>MUST</bcp14> reset the Inactivity Timer pe
ssed, the receiver MUST reset the Inactivity Timer pertaining to that RuleID and rtaining to that RuleID and DTag pair.</t>
DTag pair.</t> <t>All message receptions being discussed in the rest of this sectio
n are to be understood as
<t>All message receptions being discussed in the rest of this section are to be "matching the RuleID and DTag pair being processed", even if not spelled out, fo
understood as r brevity.</t>
“matching the RuleID and DTag pair being processed”, even if not spelled out, fo <t>On receiving a SCHC Fragment message,
r brevity.</t>
<t>On receiving a SCHC Fragment message,
the receiver determines what tiles were received, based on the payload length an d on the W and FCN fields of the SCHC Fragment.</t> the receiver determines what tiles were received, based on the payload length an d on the W and FCN fields of the SCHC Fragment.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>if the FCN is All-1, if a Payload is present, the full SCHC Fr
<t>if the FCN is All-1, if a Payload is present, the full SCHC Fragment Payloa agment Payload <bcp14>MUST</bcp14> be assembled including the padding bits.
d MUST be assembled including the padding bits. This is because the size of the last tile is not known by the receiver;
This is because the size of the last tile is not known by the receiver, therefore, padding bits are indistinguishable from the tile data bits, at this s
therefore padding bits are indistinguishable from the tile data bits, at this st tage.
age.
They will be removed by the SCHC C/D sublayer. They will be removed by the SCHC C/D sublayer.
If the size of the SCHC Fragment Payload exceeds or equals 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 raise an e the size of one regular tile plus the size of an L2 Word, this <bcp14>SHOULD</bc
rror flag.</t> p14> raise an error flag.</li>
<t>otherwise, tiles MUST be assembled based on the a priori known tile size. <li>
<list style="symbols"> <t>otherwise, tiles <bcp14>MUST</bcp14> be assembled based on th
<t>If allowed by the Profile, the end of the payload MAY contain the last e a priori known tile size.
tile, which may be shorter. Padding bits are indistinguishable from the tile dat </t>
a bits, at this stage.</t> <ul spacing="normal">
<t>the payload may contain the penultimate tile that, if allowed by the Pr <li>If allowed by the Profile, the end of the payload <bcp14>M
ofile, MAY be exactly one L2 Word shorter than the regular tile size.</t> AY</bcp14> contain the last tile, which may be shorter. Padding bits are indisti
<t>Otherwise, padding bits MUST be discarded. nguishable from the tile data bits, at this stage.</li>
The latter is possible because <list style="symbols"> <li>The payload may contain the penultimate tile that, if allo
<t>the size of the tiles is known a priori,</t> wed by the Profile, <bcp14>MAY</bcp14> be exactly one L2 Word shorter than the r
<t>tiles are larger than an L2 Word</t> egular tile size.</li>
<t>padding bits are always strictly less than an L2 Word</t> <li>
</list></t> <t>Otherwise, padding bits <bcp14>MUST</bcp14> be discarded.
</list></t> This is possible because:</t>
</list></t> <ul spacing="normal">
<li>the size of the tiles is known a priori,</li>
<t>On receiving a SCHC ACK REQ or an All-1 SCHC Fragment,</t> <li>tiles are larger than an L2 Word, and</li>
<li>padding bits are always strictly less than an L2 Word.
<t><list style="symbols"> </li>
<t>if the receiver knows of any windows with missing tiles for the packet bein </ul>
g reassembled, it </li>
MUST return a SCHC ACK for the lowest-numbered such window,</t> </ul>
<t>otherwise, </li>
<list style="symbols"> </ul>
<t>if it has received at least one tile, it MUST return a SCHC ACK for the <t>On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:</t>
highest-numbered window it currently has tiles for</t> <ul spacing="normal">
<t>otherwise it MUST return a SCHC ACK for window numbered 0</t> <li>if the receiver knows of any windows with missing tiles for th
</list></t> e packet being reassembled, it
</list></t> <bcp14>MUST</bcp14> return a SCHC ACK for the lowest-numbered such window:</li>
<li>
<t>A Profile MAY specify other times and circumstances at which <t>otherwise:
</t>
<ul spacing="normal">
<li>if it has received at least one tile, it <bcp14>MUST</bcp1
4> return a SCHC ACK for the highest-numbered window it currently has tiles for,
</li>
<li>otherwise, it <bcp14>MUST</bcp14> return a SCHC ACK for wi
ndow numbered 0.</li>
</ul>
</li>
</ul>
<t>A Profile <bcp14>MAY</bcp14> specify other times and circumstance
s at which
a receiver sends a SCHC ACK, a receiver sends a SCHC ACK,
and which window the SCHC ACK reports about in these circumstances.</t> and which window the SCHC ACK reports about in these circumstances.</t>
<t>Upon sending a SCHC ACK, the receiver <bcp14>MUST</bcp14> increas
<t>Upon sending a SCHC ACK, the receiver MUST increase the Attempts counter.</t> e the Attempts counter.</t>
<t>After receiving an All-1 SCHC Fragment,
<t>After receiving an All-1 SCHC Fragment, a receiver <bcp14>MUST</bcp14> check the integrity of the reassembled SCHC Packe
a receiver MUST check the integrity of the reassembled SCHC Packet at least ever t at least every time
y time
it prepares for sending a SCHC ACK for the last window.</t> it prepares for sending a SCHC ACK for the last window.</t>
<t>Upon receiving a SCHC Sender-Abort,
the receiver <bcp14>MAY</bcp14> exit with an error condition.</t>
<t>Upon expiration of the Inactivity Timer,
the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort,
and it <bcp14>MAY</bcp14> exit with an error condition.</t>
<t>On the Attempts counter exceeding MAX_ACK_REQUESTS,
the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort,
and it <bcp14>MAY</bcp14> exit with an error condition.</t>
<t>Reassembly of the SCHC Packet concludes when:</t>
<ul spacing="normal">
<li>a Sender-Abort has been received, or</li>
<li>the Inactivity Timer has expired, or</li>
<li>the Attempts counter has exceeded MAX_ACK_REQUESTS, or</li>
<li>at least an All-1 SCHC Fragment has been received and integrit
y checking of the reassembled SCHC Packet is successful.</li>
</ul>
<t>Upon receiving a SCHC Sender-Abort, <t>See <xref target="Fig-ACKonerrorRcv" format="default"/> for one a
the receiver MAY exit with an error condition.</t> mong several possible examples of a Finite State Machine implementing a receiver
behavior obeying this specification. The example provided is meant to match the
<t>Upon expiration of the Inactivity Timer, sender Finite State Machine of <xref target="Fig-ACKonerrorSnd" format="default
the receiver MUST send a SCHC Receiver-Abort "/>.</t>
and it MAY exit with an error condition.</t> </section>
</section>
<t>On the Attempts counter exceeding MAX_ACK_REQUESTS, </section>
the receiver MUST send a SCHC Receiver-Abort </section>
and it MAY exit with an error condition.</t> <section anchor="Padding" numbered="true" toc="default">
<name>Padding Management</name>
<t>Reassembly of the SCHC Packet concludes when</t> <t>SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does not
have any alignment prerequisite.
<t><list style="symbols">
<t>a Sender-Abort has been received</t>
<t>or the Inactivity Timer has expired</t>
<t>or the Attempts counter has exceeded MAX_ACK_REQUESTS</t>
<t>or when at least an All-1 SCHC Fragment has been received and integrity che
cking of the reassembled SCHC Packet is successful.</t>
</list></t>
<t>See <xref target="Fig-ACKonerrorRcv"/> for one among several possible example
s of a Finite State Machine implementing a receiver behavior obeying this specif
ication,
and that is meant to match the sender Finite State Machine of <xref target="Fig-
ACKonerrorSnd"/>.</t>
</section>
</section>
</section>
</section>
<section anchor="Padding" title="Padding management">
<t>SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does not have a
ny alignment prerequisite.
The size of SCHC Packets can be any number of bits.</t> The size of SCHC Packets can be any number of bits.</t>
<t>If the L2 constrains the payload to align to coarser boundaries (for ex
<t>If the layer below SCHC constrains the payload to align to some boundary, cal ample, bytes),
led L2 Words (for example, bytes), the SCHC messages <bcp14>MUST</bcp14> be padded.
the SCHC messages MUST be padded. When padding occurs, the number of appended bits <bcp14>MUST</bcp14> be strictly
When padding occurs, the number of appended bits MUST be strictly less than the less than the L2 Word size.</t>
L2 Word size.</t> <t>If a SCHC Packet is sent unfragmented (see <xref target="Fig-Operations
-Pad" format="default"/>), it is padded as needed for transmission.</t>
<t>If a SCHC Packet is sent unfragmented (see <xref target="Fig-Operations-Pad"/ <t>If a SCHC Packet needs to be fragmented for transmission, it is not pad
>), it is padded as needed for transmission.</t> ded in itself. Only the SCHC F/R messages are padded as needed for transmission.
<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> Some SCHC F/R messages are intrinsically aligned to L2 Words.</t>
<figure anchor="Fig-Operations-Pad">
<figure title="SCHC operations, including padding as needed" anchor="Fig-Operati <name>SCHC Operations, Including Padding as Needed</name>
ons-Pad"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
A packet (e.g., an IPv6 packet) A packet (e.g., an IPv6 packet)
| ^ (padding bits | ^ (padding bits
v | dropped) v | dropped)
+------------------+ +--------------------+ +------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression | | SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+ +------------------+ +--------------------+
| ^ | ^
| If no fragmentation | | If no fragmentation, |
+---- SCHC Packet + padding as needed ----->| +---- SCHC Packet + padding as needed ----->|
| | (integrity | | (integrity
v | checked) v | checked)
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| SCHC Fragmentation | | SCHC Reassembly | | SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| +--- SCHC ACK + padding as needed --+ | | +--- SCHC ACK + padding as needed --+ |
| | | |
+------- SCHC Fragments + padding as needed---------+ +------- SCHC Fragments + padding as needed---------+
Sender Receiver Sender Receiver]]></artwork>
</figure>
]]></artwork></figure> <t>Each Profile <bcp14>MUST</bcp14> specify the size of the L2 Word.
<t>Each Profile MUST specify the size of the L2 Word.
The L2 Word might actually be a single bit, in which case no padding will take p lace at all.</t> The L2 Word might actually be a single bit, in which case no padding will take p lace at all.</t>
<t>A Profile <bcp14>MUST</bcp14> define the value of the padding bits if t
<t>A Profile MAY define the value of the padding bits. The RECOMMENDED value is he L2 Word is wider than a single bit. The <bcp14>RECOMMENDED</bcp14> value is 0
0.</t> .</t>
</section>
</section> <section anchor="schc-compression-for-ipv6-and-udp-headers" numbered="true"
<section anchor="schc-compression-for-ipv6-and-udp-headers" title="SCHC Compress toc="default">
ion for IPv6 and UDP headers"> <name>SCHC Compression for IPv6 and UDP Headers</name>
<t>This section lists the IPv6 and UDP header fields and describes how the
<t>This section lists the IPv6 and UDP header fields and describes how they can y can be compressed.
be compressed. An example of a set of Rules for UDP/IPv6 header compression is provided in <xre
An example of a set of Rules for UDP/IPv6 header compression is provided in <xre f target="compressIPv6" format="default"/>.</t>
f target="compressIPv6"/>.</t> <section anchor="ipv6-version-field" numbered="true" toc="default">
<name>IPv6 Version Field</name>
<section anchor="ipv6-version-field" title="IPv6 version field"> <t>The IPv6 version field is labeled by the protocol parser as being the
"version" field of the IPv6 protocol.
<t>The IPv6 version field is labeled by the protocol parser as being the “versio
n” field of the IPv6 protocol.
Therefore, it only exists for IPv6 packets. Therefore, it only exists for IPv6 packets.
In the Rule, TV is set to 6, MO to “ignore” In the Rule, TV is set to 6, MO to "ignore"
and CDA to “not-sent”.</t> and CDA to "not-sent".</t>
</section>
</section> <section anchor="ipv6-traffic-class-field" numbered="true" toc="default">
<section anchor="ipv6-traffic-class-field" title="IPv6 Traffic class field"> <name>IPv6 Traffic Class Field</name>
<t>If the DiffServ field does not vary and is known by both sides, the Field Des
criptor in the Rule SHOULD contain a TV with
this well-known value, an “equal” MO and a “not-sent” CDA.</t>
<t>Otherwise (e.g., ECN bits are to be transmitted), two possibilities can be co
nsidered depending on the variability of the value:</t>
<t><list style="symbols"> <t>If the Diffserv field does not vary and is known by both sides, the F
<t>One possibility is to not compress the field and send the original value. I ield Descriptor in the Rule <bcp14>SHOULD</bcp14> contain a TV with
n the Rule, TV is not set to any particular value, MO is set to “ignore” and CDA this well-known value, an "equal" MO, and a "not-sent" CDA.</t>
is set to “value-sent”.</t> <t>Otherwise (e.g., ECN bits are to be transmitted), two possibilities c
<t>If some upper bits in the field are constant and known, a better option is an be considered depending on the variability of the value:</t>
to only send the LSBs. In the Rule, TV is set to a value with the stable known u <ul spacing="normal">
pper part, MO is set to MSB(x) and CDA to LSB. <vspace blankLines='1'/> <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
", and CDA is set to "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 stab
le known upper part, MO is set to MSB(x), and CDA to LSB. </t>
<t>
ECN functionality depends on both bits of the ECN field, which ECN functionality depends on both bits of the ECN field, which
are the 2 LSBs of this field, hence sending only a single are the 2 LSBs of this field; hence, sending only a single
LSB of this field is NOT RECOMMENDED.</t> LSB of this field is <bcp14>NOT RECOMMENDED</bcp14>.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="flow-label-field" title="Flow label field"> <section anchor="flow-label-field" numbered="true" toc="default">
<name>Flow Label Field</name>
<t>If the flow label is not set, i.e. its value is zero, the Field Descriptor in <t>If the flow label is not set, i.e., its value is zero, the Field Desc
the Rule SHOULD contain a TV set to zero, an “equal” MO and a “not-sent” CDA.</ riptor in the Rule <bcp14>SHOULD</bcp14> contain a TV set to zero, an "equal" MO
t> , and a "not-sent" CDA.</t>
<t>If the flow label is set to a pseudorandom value according to <xref t
<t>If the flow label is set to a pseudo-random value according to <xref target=" arget="RFC6437" format="default"/>, in the Rule, TV is not set to any particular
RFC6437"/>, in the Rule, TV is not set to any particular value, MO is set to “ig value, MO is set to "ignore", and CDA is set to "value-sent".</t>
nore” and CDA is set to “value-sent”.</t> <t>If the flow label is set according to some prior agreement, i.e., by
a flow state establishment method as allowed by <xref target="RFC6437" format="d
<t>If the flow label is set according to some prior agreement, i.e. by a flow st efault"/>,
ate establishment method as allowed by <xref target="RFC6437"/>, the Field Descriptor in the Rule <bcp14>SHOULD</bcp14> contain a TV with this ag
the Field Descriptor in the Rule SHOULD contain a TV with this agreed-upon value reed-upon value, an "equal" MO, and a "not-sent" CDA.</t>
, an “equal” MO and a “not-sent” CDA.</t> </section>
<section anchor="payload-length-field" numbered="true" toc="default">
</section> <name>Payload Length Field</name>
<section anchor="payload-length-field" title="Payload Length field"> <t>This field can be elided for the transmission on the LPWAN. The SCHC
C/D recomputes the original payload length value. In the Field Descriptor, TV is
<t>This field can be elided for the transmission on the LPWAN network. The SCHC not set, MO is set to "ignore", and CDA is "compute-*".</t>
C/D recomputes the original payload length value. In the Field Descriptor, TV is </section>
not set, MO is set to “ignore” and CDA is “compute-*”.</t> <section anchor="next-header-field" numbered="true" toc="default">
<name>Next Header Field</name>
</section> <t>If the Next Header field does not vary and is known by both sides, th
<section anchor="next-header-field" title="Next Header field"> e Field Descriptor in the Rule <bcp14>SHOULD</bcp14> contain a TV with
this Next Header value, the MO <bcp14>SHOULD</bcp14> be "equal", and the CDA <bc
<t>If the Next Header field does not vary and is known by both sides, the Field p14>SHOULD</bcp14> be "not-sent".</t>
Descriptor in the Rule SHOULD contain a TV with <t>Otherwise, TV is not set in the Field Descriptor, MO is set to "ignor
this Next Header value, the MO SHOULD be “equal” and the CDA SHOULD be “not-sent e", and CDA is set to "value-sent". Alternatively, a matching-list <bcp14>MAY</b
”.</t> cp14> also be used.</t>
</section>
<t>Otherwise, TV is not set in the Field Descriptor, MO is set to “ignore” and C <section anchor="hop-limit-field" numbered="true" toc="default">
DA is set to “value-sent”. Alternatively, a matching-list MAY also be used.</t> <name>Hop Limit Field</name>
<t>The field behavior for this field is different for Uplink and Downlin
</section> k.
<section anchor="hop-limit-field" title="Hop Limit field"> In Uplink, since there is no IP forwarding between the Dev and the SCHC C/D, the
value is relatively constant.
<t>The field behavior for this field is different for uplink (Up) and downlink ( On the other hand, the Downlink value depends on Internet routing and can change
Dw). more frequently.
In Up, since there is no IP forwarding between the Dev and the SCHC C/D, the val The DI can be used to distinguish both directions:</t>
ue is relatively constant. <ul spacing="normal">
On the other hand, the Dw value depends on Internet routing and can change more <li>in an Up Field Descriptor, elide the field: the TV is set to the k
frequently. nown constant value, the MO is set to "equal" and the CDA is set to "not-sent".<
The Direction Indicator (DI) can be used to distinguish both directions:</t> /li>
<li>in a Dw Field Descriptor, the Hop Limit is elided for transmission
<t><list style="symbols"> and forced to 1 at the receiver, by setting TV to 1, MO to "ignore" and CDA to
<t>in the Up, elide the field: the TV in the Field Descriptor is set to the kn "not-sent". This prevents any further forwarding.</li>
own constant value, the MO is set to “equal” and the CDA is set to “not-sent”.</ </ul>
t> </section>
<t>in the Dw, the Hop Limit is elided for transmission and forced to 1 at the <section anchor="ipv6-addresses-fields" numbered="true" toc="default">
receiver, by setting TV to 1, MO to “ignore” and CDA to “not-sent”. This prevent <name>IPv6 Addresses Fields</name>
s any further forwarding.</t> <t>As in 6LoWPAN <xref target="RFC4944" format="default"/>, IPv6 address
</list></t> es are split into two 64-bit-long fields; one for the prefix and one for the Int
erface Identifier (IID). These fields <bcp14>SHOULD</bcp14> be compressed. To al
</section> low for a single Rule being used for both directions, these values are identifie
<section anchor="ipv6-addresses-fields" title="IPv6 addresses fields"> d by their role (Dev or App) and not by their position in the header (source or
destination).</t>
<t>As in 6LoWPAN <xref target="RFC4944"/>, IPv6 addresses are split into two 64- <section anchor="ipv6-source-and-destination-prefixes" numbered="true" t
bit long fields; one for the prefix and one for the Interface Identifier (IID). oc="default">
These fields SHOULD be compressed. To allow for a single Rule being used for bot <name>IPv6 Source and Destination Prefixes</name>
h directions, these values are identified by their role (Dev or App) and not by <t>Both ends <bcp14>MUST</bcp14> be configured with the appropriate pr
their position in the header (source or destination).</t> efixes. For a specific flow, the source and destination prefixes can be unique a
nd stored in the Context.
<section anchor="ipv6-source-and-destination-prefixes" title="IPv6 source and de
stination prefixes">
<t>Both ends MUST be configured with the appropriate prefixes. For a specific fl
ow, the source and destination prefixes can be unique and stored in the Context.
In that case, the TV for the In that case, the TV for the
source and destination prefixes contain the values, the MO is set to “equal” and source and destination prefixes contain the values, the MO is set to "equal" and
the CDA is set to “not-sent”.</t> the CDA is set to "not-sent".</t>
<t>If the Rule is intended to compress packets with different prefix v
<t>If the Rule is intended to compress packets with different prefix values, mat alues, match-mapping <bcp14>SHOULD</bcp14> be used. The different prefixes are l
ch-mapping SHOULD be used. The different prefixes are listed in the TV, the MO i isted in the TV, the MO is set to "match-mapping" and the CDA is set to "mapping
s set to “match-mapping” and the CDA is set to “mapping-sent”. See <xref target= -sent". See <xref target="Fig-fields" format="default"/>.</t>
"Fig-fields"/>.</t> <t>Otherwise, the TV is not set, the MO is set to "ignore", and the CD
A is set to "value-sent".</t>
<t>Otherwise, the TV is not set, the MO is set to “ignore” and the CDA is set to </section>
“value-sent”.</t> <section anchor="ipv6-source-and-destination-iid" numbered="true" toc="d
efault">
</section> <name>IPv6 Source and Destination IID</name>
<section anchor="ipv6-source-and-destination-iid" title="IPv6 source and destina <t>If the Dev or App IID are based on an L2 address, then the IID can
tion IID"> be reconstructed with information coming from the L2 header. In that case, the T
V is not set, the MO is set to "ignore" and the CDA is set to "DevIID" or "AppII
<t>If the Dev or App IID are based on an LPWAN address, then the IID can be reco D".
nstructed with information coming from the LPWAN header. In that case, the TV is On LPWAN technologies where the frames carry a single identifier (corresponding
not set, the MO is set to “ignore” and the CDA is set to “DevIID” or “AppIID”. to the Dev), AppIID cannot be used.</t>
On LPWAN technologies where the frames carry a single identifier (corresponding <t>As described in <xref target="RFC8065" format="default"/>, it may b
to the Dev.), AppIID cannot be used.</t> e undesirable to build the Dev IPv6 IID out of the Dev address. Another static v
alue is used instead.
<t>As described in <xref target="RFC8065"/>, it may be undesirable to build the In that case, the TV contains the static value, the MO operator is set to "equal
Dev IPv6 IID out of the Dev address. Another static value is used instead. " and the CDA is set to "not-sent".</t>
In that case, the TV contains the static value, the MO operator is set to “equal <t>If several IIDs are possible, then the TV contains the list of poss
” and the CDA is set to “not-sent”.</t> ible IIDs, the MO is set to "match-mapping" and the CDA is set to "mapping-sent"
.</t>
<t>If several IIDs are possible, then the TV contains the list of possible IIDs, <t>It may also happen that the IID variability only expresses itself o
the MO is set to “match-mapping” and the CDA is set to “mapping-sent”.</t> n a few bytes. In that case, the TV is set to the stable part of the IID, the MO
is set to "MSB" and the CDA is set to "LSB".</t>
<t>It may also happen that the IID variability only expresses itself on a few by <t>Finally, the IID can be sent in its entirety on the L2. In that cas
tes. In that case, the TV is set to the stable part of the IID, the MO is set to e, the TV is not set, the MO is set to "ignore", and the CDA is set to "value-se
“MSB” and the CDA is set to “LSB”.</t> nt".</t>
</section>
<t>Finally, the IID can be sent in its entirety on the LPWAN. In that case, the </section>
TV is not set, the MO is set to “ignore” and the CDA is set to “value-sent”.</t> <section anchor="ipv6-extension-headers" numbered="true" toc="default">
<name>IPv6 Extension Headers</name>
</section> <t>This document does not provide recommendations on how to compress IPv
</section> 6 extension headers.</t>
<section anchor="ipv6-extension-headers" title="IPv6 extension headers"> </section>
<section anchor="udp-source-and-destination-ports" numbered="true" toc="de
<t>This document does not provide recommendations on how to compress IPv6 extens fault">
ion headers.</t> <name>UDP Source and Destination Ports</name>
<t>To allow for a single Rule being used for both directions, the UDP po
</section> rt values are identified by their role (Dev or App) and not by their position in
<section anchor="udp-source-and-destination-ports" title="UDP source and destina the header (source or destination). The SCHC C/D <bcp14>MUST</bcp14> be aware o
tion ports"> f the traffic direction (Uplink, Downlink) to select the appropriate field. The
following Rules apply for Dev and App port numbers.</t>
<t>To allow for a single Rule being used for both directions, the UDP port value <t>If both ends know the port number, it can be elided. The TV
s are identified by their role (Dev or App) and not by their position in the hea contains the port number, the MO is set to "equal", and the CDA is set to
der (source or destination). The SCHC C/D MUST be aware of the traffic direction "not-sent".</t>
(Uplink, Downlink) to select the appropriate field. The following Rules apply f <t>If the port variation is on few bits, the TV contains the stable part
or Dev and App port numbers.</t> of the port number, the MO is set to "MSB", and the CDA is set to "LSB".</t>
<t>If some well-known values are used, the TV can contain the list of t
<t>If both ends know the port number, it can be elided. The TV contains the port hese values, the MO is set to "match-mapping", and the CDA is set to "mapping-se
number, the MO is set to “equal” and the CDA is set to “not-sent”.</t> nt".</t>
<t>Otherwise, the port numbers are sent over the L2. The TV is not set,
<t>If the port variation is on few bits, the TV contains the stable part of the the MO is set to "ignore" and the CDA is set to "value-sent".</t>
port number, the MO is set to “MSB” and the CDA is set to “LSB”.</t> </section>
<section anchor="udp-length-field" numbered="true" toc="default">
<t>If some well-known values are used, the TV can contain the list of these val <name>UDP Length Field</name>
ues, the MO is set to “match-mapping” and the CDA is set to “mapping-sent”.</t> <t>The parser MUST NOT label this field unless the UDP Length value
matches the Payload Length value from the IPv6 header.
<t>Otherwise the port numbers are sent over the LPWAN. The TV is not set, the MO The TV is not set, the MO is set to "ignore", and the CDA is set to
is set to “ignore” and the CDA is set to “value-sent”.</t> "compute-*”.</t>
</section>
</section> <section anchor="UDPchecksum" numbered="true" toc="default">
<section anchor="udp-length-field" title="UDP length field"> <name>UDP Checksum Field</name>
<t>The UDP checksum operation is mandatory with IPv6 for most
<t>The UDP length can be computed from the received data. The TV is not set, the packets, but there are exceptions <xref target="RFC8200" format="default"/>.</t>
MO is set to “ignore” and the CDA is set to “compute-*”.</t> <t>For instance, protocols that use UDP as a tunnel encapsulation may
</section>
<section anchor="UDPchecksum" title="UDP Checksum field">
<t>The UDP checksum operation is mandatory with IPv6 for most
packets but there are exceptions <xref target="RFC8200"></xref>.</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 enable zero-checksum mode for a specific port (or set of ports) for
sending and/or receiving. <xref target="RFC8200"></xref> requires any node sending and/or receiving. <xref target="RFC8200" format="default"/> requires any node
implementing zero-checksum mode to follow the requirements specified implementing zero-checksum mode to follow the requirements specified
in “Applicability Statement for the Use of IPv6 UDP Datagrams with in "Applicability Statement for the Use of IPv6 UDP Datagrams with
Zero Checksums” <xref target="RFC6936"></xref>.</t> Zero Checksums" <xref target="RFC6936" format="default"/>.</t>
<t>6LoWPAN Header Compression <xref target="RFC6282" format="default"/>
<t>6LoWPAN Header Compression <xref target="RFC6282"></xref> also specifies that also specifies that a UDP
a UDP checksum can be elided by the compressor and recomputed by the decompressor when
checksum can be elided by the compressor and re-computed by the decompressor whe an upper
n an upper
layer guarantees the integrity of the UDP payload and pseudo-header. layer guarantees the integrity of the UDP payload and pseudo-header.
A specific example of this is A specific example of this is
when a message integrity check protects the compressed message when a message integrity check protects the compressed message
between the compressor that elides the UDP checksum and the decompressor between the compressor that elides the UDP checksum and the decompressor
that computes it, that computes it,
with a strength that is identical or better to with a strength that is identical or better to
the UDP checksum.</t> the UDP checksum.</t>
<t>Similarly, a SCHC compressor <bcp14>MAY</bcp14>
<t>Similarly, a SCHC compressor MAY
elide the UDP checksum when another layer guarantees at least equal elide the UDP checksum when another layer guarantees at least equal
integrity protection for the UDP payload and the pseudo-header. integrity protection for the UDP payload and the pseudo-header.
In this case, the TV is not set, the MO is set to “ignore” and the CDA is set to In this case, the TV is not set, the MO is set to "ignore", and the CDA is set t
“compute-*”.</t> o "compute-*".</t>
<t>In particular, when SCHC fragmentation is used, a fragmentation RCS
<t>In particular, when SCHC fragmentation is used, a fragmentation RCS
of 2 bytes or more provides equal or better protection than the UDP of 2 bytes or more provides equal or better protection than the UDP
checksum; in that case, if the compressor is collocated with the checksum; in that case, if the compressor is collocated with the
fragmentation point and the decompressor is collocated with the fragmentation point and the decompressor is collocated with the
packet reassembly point, packet reassembly point,
and if the SCHC Packet is fragmented even when it would fit unfragmented in the L2 MTU, and if the SCHC Packet is fragmented even when it would fit unfragmented in the L2 MTU,
then the compressor MAY verify and then elide the UDP checksum. then the compressor <bcp14>MAY</bcp14> verify and then elide the UDP checksum.
Whether and when the UDP Checksum is elided is to be specified in the Whether and when the UDP Checksum is elided is to be specified in the
Profile.</t> Profile.</t>
<t>Since the compression happens before the fragmentation, implementers
<t>Since the compression happens before the fragmentation, implementers
should understand the risks when dealing with unprotected data below should understand the risks when dealing with unprotected data below
the transport layer and take special care when manipulating that data.</t> the transport layer and take special care when manipulating that data.</t>
<t>In other cases, the checksum <bcp14>SHOULD</bcp14> be explicitly sent
<t>In other cases, the checksum SHOULD be explicitly sent. The TV is not set, th . The TV is not set, the MO is set to "ignore" and the CDA is set to "value-sent
e MO is set to “ignore” and the CDA is set to “value-sent”.</t> ".</t>
</section>
</section> </section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>This document has no request to IANA.</t> </section>
<section anchor="SecConsiderations" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<section anchor="SecConsiderations" title="Security considerations"> <t>As explained in <xref target="Overview" format="default"/>, SCHC is exp
ected to be implemented on top of LPWAN technologies,
<t>As explained in <xref target="Overview"/>, SCHC is expected to be implemented
on top of LPWAN technologies,
which are expected to implement security measures.</t> which are expected to implement security measures.</t>
<t>In this section, we analyze the potential security threats that could b
<t>In this section, we analyze the potential security threats that could be intr e introduced
oduced
into an LPWAN by adding the SCHC functionalities.</t> into an LPWAN by adding the SCHC functionalities.</t>
<section anchor="security-considerations-for-schc-compressiondecompression
<section anchor="security-considerations-for-schc-compressiondecompression" titl " numbered="true" toc="default">
e="Security considerations for SCHC Compression/Decompression"> <name>Security Considerations for SCHC Compression/Decompression</name>
<section anchor="forged-schc-packet" numbered="true" toc="default">
<section anchor="forged-schc-packet" title="Forged SCHC Packet"> <name>Forged SCHC Packet</name>
<t>Let’s assume that an attacker is able to send a forged SCHC Packet to a SCHC <t>Let's assume that an attacker is able to send a forged SCHC Packet
Decompressor.</t> to a SCHC decompressor.</t>
<t>Let's first consider the case where the RuleID contained in that fo
<t>Let’s first consider the case where the Rule ID contained in that forged SCHC rged SCHC Packet does not correspond to a Rule allocated in the Rule table.
Packet does not correspond to a Rule allocated in the Rule table. An implementation should detect that the RuleID is invalid and should silently d
An implementation should detect that the Rule ID is invalid and should silently rop the offending SCHC Packet.</t>
drop the offending SCHC Packet.</t> <t>Let's now consider that the RuleID corresponds to a Rule in the tab
le. With the CDAs defined in this document, the reconstructed packet is, at most
<t>Let’s now consider that the Rule ID corresponds to a Rule in the table. With , a constant number of bits bigger than the SCHC Packet that was received.
the CDAs defined in this document, the reconstructed packet is at most a constan This assumes that the compute-* decompression actions produce a bounded number o
t number of bits bigger than the SCHC Packet that was received. f bits, irrespective of the incoming SCHC Packet. This property is true for IPv6
This assumes that the compute-* decompression actions produce a bounded number o Length, UDP Length, and UDP Checksum, for which the compute-* CDA is recommende
f bits, irrespective of the incoming SCHC Packet. This property is true for IPv6 d by this document.</t>
Length, UDP Length and UDP Checksum, for which the compute-* CDA is recommended <t>As a consequence, SCHC decompression does not amplify attacks, beyo
by this document.</t> nd adding a bounded number of bits to the SCHC Packet received. This bound is de
termined by the Rule stored in the receiving device.</t>
<t>As a consequence, SCHC Decompression does not amplify attacks, beyond adding <t>As a general safety measure, a SCHC decompressor should never recon
a bounded number of bits to the SCHC Packet received. This bound is determined b struct a packet larger than MAX_PACKET_SIZE (defined in a Profile, with 1500 byt
y the Rule stored in the receiving device.</t> es as generic default).</t>
</section>
<t>As a general safety measure, a SCHC Decompressor should never re-construct a <section anchor="compressed-packet-size-as-a-side-channel-to-guess-a-sec
packet larger than MAX_PACKET_SIZE (defined in a Profile, with 1500 bytes as gen ret-token" numbered="true" toc="default">
eric default).</t> <name>Compressed Packet Size as a Side Channel to Guess a Secret Token
</name>
</section> <t>Some packet compression methods are known to be susceptible to atta
<section anchor="compressed-packet-size-as-a-side-channel-to-guess-a-secret-toke cks, such as BREACH and CRIME.
n" title="Compressed packet size as a side channel to guess a secret token">
<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 r esulting compressed packet size. The observed size potentially reflects correlat ion 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> The attack involves injecting arbitrary data into the packet and observing the r esulting compressed packet size. The observed size potentially reflects correlat ion 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 takes place header field by header fi
<t>By contrast, SCHC Compression takes place header field by header field, eld,
with the SCHC Packet being a mere concatenation of the compression residues of e ach of the individual field. with the SCHC Packet being a mere concatenation of the compression residues of e ach of the individual field.
Any correlation between header fields does not result in a change in the SCHC Pa cket size compressed under the same Rule.</t> Any correlation between header fields does not result in a change in the SCHC Pa cket size compressed under the same Rule.</t>
<t>If SCHC C/D is used to compress packets that include a secret infor
<t>If SCHC C/D is used to compress packets that include a secret information fie mation field, such as a token,
ld, such as a token,
the Rule set should be designed so that the size of the compression residue for the field to remain secret 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. is the same irrespective of the value of the secret information.
This is achieved by e.g., sending this field in extenso with the “ignore” MO and the “value-sent” CDA. This is achieved by, e.g., sending this field in extenso with the "ignore" MO an d the "value-sent" CDA.
This recommendation is disputable if it is ascertained that the Rule set itself will remain secret.</t> This recommendation is disputable if it is ascertained that the Rule set itself will remain secret.</t>
</section>
</section> <section anchor="decompressed-packet-different-from-the-original-packet"
<section anchor="decompressed-packet-different-from-the-original-packet" title=" numbered="true" toc="default">
Decompressed packet different from the original packet"> <name>Decompressed Packet Different from the Original Packet</name>
<t>As explained in <xref target="PProcessing"/>, using FPs with value 0 in Field <t>As explained in <xref target="PProcessing" format="default"/>, usin
Descriptors in a Rule may result in header fields g 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 orig inal packet. appearing in the decompressed packet in an order different from that in the orig inal packet.
Likewise, as stated in <xref target="NotSentCDA"/>, using an “ignore” MO togethe r with a “not-sent” CDA will Likewise, as stated in <xref target="NotSentCDA" format="default"/>, using an "i gnore" MO together with a "not-sent" CDA will
result in the header field taking the TV value, which is likely to be different from the original value.</t> 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
<t>Depending on the protocol, the order of header fields in the packet may be fu the packet may or may not be functionally significant.</t>
nctionally significant or not.</t> <t>Furthermore, if the packet is protected by a checksum or a similar
integrity protection mechanism,
<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 de compression, and if the checksum is transmitted instead of being recomputed as part of the de compression,
these situations may result in the packet being considered corrupt and dropped.< /t> these situations may result in the packet being considered corrupt and dropped.< /t>
</section>
</section> </section>
</section> <section anchor="security-considerations-for-schc-fragmentationreassembly"
<section anchor="security-considerations-for-schc-fragmentationreassembly" title numbered="true" toc="default">
="Security considerations for SCHC Fragmentation/Reassembly"> <name>Security Considerations for SCHC Fragmentation/Reassembly</name>
<section anchor="buffer-reservation-attack" numbered="true" toc="default
<section anchor="buffer-reservation-attack" title="Buffer reservation attack"> ">
<t>Let’s assume that an attacker is able to send a forged SCHC Fragment to a SCH <name>Buffer Reservation Attack</name>
C Reassembler.</t> <t>Let's assume that an attacker is able to send a forged SCHC Fragmen
t to a SCHC reassembler.</t>
<t>A node can perform a buffer reservation attack: the receiver will reserve buf <t>A node can perform a buffer reservation attack: the receiver will r
fer space for the SCHC Packet. If the implementation has only one buffer, other eserve buffer space for the SCHC Packet. If the implementation has only one buff
incoming fragmented SCHC Packets will be dropped while the reassembly buffer is er, other incoming fragmented SCHC Packets will be dropped while the reassembly
occupied during the reassembly timeout. Once that timeout expires, the attacker buffer is occupied during the reassembly timeout. Once that timeout expires, the
can repeat the same procedure, and iterate, thus creating a denial of service at attacker can repeat the same procedure, and iterate, thus, creating a denial-of
tack. -service attack.
An implementation may have multiple reassembly buffers. The cost to mount this a ttack is linear with the number of buffers at the target node. An implementation may have multiple reassembly buffers. The cost to mount this a ttack is linear with the number of buffers at the target node.
Better, the cost for an attacker can be increased if individual fragments of mul Better, the cost for an attacker can be increased if individual
tiple SCHC Packets can be stored in the reassembly buffer. The finer grained the fragments of multiple SCHC Packets can be stored in the reassembly
reassembly buffer (downto the smallest tile size), the higher the cost of the a buffer. The finer grained the reassembly buffer (down to the smallest tile size)
ttack. , the higher the cost of the attack.
If buffer overload does occur, a smart receiver could selectively discard SCHC P ackets being reassembled based on the sender behavior, which may help identify w hich SCHC Fragments have been sent by the attacker. If buffer overload does occur, a smart receiver could selectively discard SCHC P ackets being reassembled based on the sender behavior, which may help identify w hich SCHC Fragments have been sent by the attacker.
Another mild counter-measure is for the target to abort the fragmentation/reasse Another mild countermeasure is for the target to abort the fragmentation/reassem
mbly session as early as it detects a non-identical SCHC Fragment duplicate, ant bly session as early as it detects a non-identical SCHC Fragment duplicate, anti
icipating for an eventual corrupt SCHC Packet, so as to save the sender the hass cipating for an eventual corrupt SCHC Packet, so as to save the sender the hassl
le of sending the rest of the fragments for this SCHC Packet.</t> e of sending the rest of the fragments for this SCHC Packet.</t>
</section>
</section> <section anchor="corrupt-fragment-attack" numbered="true" toc="default">
<section anchor="corrupt-fragment-attack" title="Corrupt Fragment attack"> <name>Corrupt Fragment Attack</name>
<t>Let’s assume that an attacker is able to send a forged SCHC Fragment to a SCH <t>Let's assume that an attacker is able to send a forged SCHC Fragmen
C Reassembler. t to a SCHC reassembler.
The malicious node is additionally assumed to be able to hear an incoming commun ication destined to the target node.</t> The malicious node is additionally assumed to be able to hear an incoming commun ication destined to the target node.</t>
<t>It can then send a forged SCHC Fragment that looks like it belongs
<t>It can then send a forged SCHC Fragment that looks like it belongs to a SCHC to a SCHC Packet already being reassembled at the target node.
Packet already being reassembled at the target node. This can cause the SCHC Packet to be considered corrupt and to be dropped by the
This can cause the SCHC Packet to be considered corrupt and be dropped by the re receiver.
ceiver. The amplification happens here by a single spoofed SCHC Fragment rendering a ful
The amplification happens here by a single spoofed SCHC Fragment rendering a ful l sequence of legitimate SCHC Fragments useless.
l sequence of legit SCHC Fragments useless.
If the target uses ACK-Always or ACK-on-Error mode, such a malicious node can al so interfere with If the target uses ACK-Always or ACK-on-Error mode, such a malicious node can al so interfere with
the acknowledgement and repetition algorithm of SCHC F/R. the acknowledgement and repetition algorithm of SCHC F/R.
A single spoofed ACK, with all bitmap bits set to 0, will trigger the repetition of WINDOW_SIZE tiles. This protocol loop amplification depletes the energy sour ce of the target node and consumes the channel bandwidth. A single spoofed ACK, with all Bitmap bits set to 0, will trigger the repetition of WINDOW_SIZE tiles. This protocol loop amplification depletes the energy sour ce of the target node and consumes the channel bandwidth.
Similarly, a spoofed ACK REQ will trigger the sending of a SCHC ACK, 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. 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> These consequences should be borne in mind when defining profiles for SCHC over specific LPWAN technologies.</t>
</section>
</section> <section anchor="fragmentation-as-a-way-to-bypass-network-inspection" nu
<section anchor="fragmentation-as-a-way-to-bypass-network-inspection" title="Fra mbered="true" toc="default">
gmentation as a way to bypass Network Inspection"> <name>Fragmentation as a Way to Bypass Network Inspection</name>
<t>Fragmentation is known for potentially allowing to force through a Network In <t>Fragmentation is known for potentially allowing one to force throug
spection device (e.g., firewall) packets that would be rejected if unfragmented. h a Network Inspection device (e.g., firewall) packets that would be rejected if
This involves sending overlapping fragments to rewrite fields whose initial valu unfragmented.
e led the Network Inspection device to allow the flow go through.</t> This involves sending overlapping fragments to rewrite fields whose initial valu
e 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 Inspect <t>SCHC F/R is expected to be used over one LPWAN link, where no Netwo
ion device is expected to sit. rk Inspection device is expected to sit.
As described in <xref target="FunctionalMapping"/>, even if the SCHC F/R on the As described in <xref target="FunctionalMapping" format="default"/>, even if the
Network infrastructure side is located SCHC F/R on the Network Infrastructure side is located
in the Internet, a tunnel is to be established between it and the NGW.</t> in the Internet, a tunnel is to be established between it and the NGW.</t>
</section>
</section> <section anchor="privacy-issues-associated-with-schc-header-fields" numb
<section anchor="privacy-issues-associated-with-schc-header-fields" title="Priva ered="true" toc="default">
cy issues associated with SCHC header fields"> <name>Privacy Issues Associated with SCHC Header Fields</name>
<t>SCHC F/R allocates a DTag value to fragments belonging to the same SCHC Packe <t>SCHC F/R allocates a DTag value to fragments belonging to the same
t. SCHC Packet.
Concerns were raised that, if DTag is a wide counter that is incremented in a pr edictable fashion for each new fragmented SCHC Packet, Concerns were raised that, if DTag is a wide counter that is incremented in a pr edictable fashion for each new fragmented SCHC Packet,
it might lead to a privacy issue, such as enabling tracking of a device across L PWANs.</t> it might lead to a privacy issue, such as enabling tracking of a device across L PWANs.</t>
<t>However, SCHC F/R is expected to be used over exactly one LPWAN lin
<t>However, SCHC F/R is expected to be used over exactly one LPWAN link. k.
As described in <xref target="FunctionalMapping"/>, even if the SCHC F/R on the As described in <xref target="FunctionalMapping" format="default"/>, even if the
Network infrastructure side is located SCHC F/R on the Network Infrastructure side is located
in the Internet, a tunnel is to be established between it and the NGW. 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> 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> </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 carrie
d out during his stay as a visiting scholar at the Computer Laboratory of the Un
iversity of Cambridge.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6936.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8200.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8376.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4944.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5795.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6282.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6437.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7136.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8065.xml"/>
<references title='Normative References'> <reference anchor="ETHERNET" target="https://ieeexplore.ieee.org/document/641973
5" quoteTitle="true" derivedAnchor="IEEE-802.3-2012">
<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 Comm
unity, 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 Check
sums</title>
<author initials='G.' surname='Fairhurst' fullname='G. Fairhurst'><organization
/></author>
<author initials='M.' surname='Westerlund' fullname='M. Westerlund'><organizatio
n /></author>
<date year='2013' month='April' />
<abstract><t>This document provides an applicability statement for the use of UD
P transport checksums with IPv6. It defines recommendations and requirements fo
r the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issu
es and design principles that need to be considered when UDP is used with IPv6 t
o support tunnel encapsulations, and it examines the role of the IPv6 UDP transp
ort checksum. The document also identifies issues and constraints for deploymen
t 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 RF
C 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 /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</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 /></au
thor>
<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'><org
anization /></author>
<date year='2018' month='May' />
<abstract><t>Low-Power Wide Area Networks (LPWANs) are wireless technologies wit
h characteristics such as large coverage areas, low bandwidth, possibly very sma
ll packet and application-layer data sizes, and long battery life operation. Th
is memo is an informational overview of the set of LPWAN technologies being cons
idered in the IETF and of the gaps that exist between the needs of those technol
ogies 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'><organizatio
n /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'><organizat
ion /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></au
thor>
<date year='2007' month='September' />
<abstract><t>This document describes the frame format for transmission of IPv6 p
ackets and the method of forming IPv6 link-local addresses and statelessly autoc
onfigured addresses on IEEE 802.15.4 networks. Additional specifications include
a simple header compression scheme using shared context and provisions for pack
et 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 oper
ate efficiently and robustly over various link technologies with different chara
cteristics.</t><t>The ROHC framework, along with a set of compression profiles,
was initially defined in RFC 3095. To improve and simplify the ROHC specificati
ons, this document explicitly defines the ROHC framework and the profile for unc
ompressed separately. More specifically, the definition of the framework does n
ot modify or update the definition of the framework specified by RFC 3095.</t><t
>This specification obsoletes RFC 4995. It fixes one interoperability issue tha
t 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'><organizatio
n /></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 compr
ession format for IPv6 packet delivery in Low Power Wireless Personal Area Netwo
rks (6LoWPANs). The compression format relies on shared context to allow compre
ssion of arbitrary prefixes. How the information is maintained in that shared c
ontext is out of scope. This document specifies compression of multicast address
es and a framework for compressing next headers. UDP header compression is spec
ified 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 /></au
thor>
<author initials='B.' surname='Carpenter' fullname='B. Carpenter'><organization
/></author>
<author initials='S.' surname='Jiang' fullname='S. Jiang'><organization /></auth
or>
<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 r
equirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets
, and flow state establishment methods. Even when mentioned as examples of poss
ible uses of the flow labeling, more detailed requirements for specific use case
s are out of the scope for this document.</t><t>The usage of the Flow Label fiel
d enables efficient IPv6 flow classification based only on IPv6 main header fiel
ds 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 /></auth
or>
<date year='2014' month='February' />
<abstract><t>The IPv6 addressing architecture includes a unicast interface ident
ifier 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 a
n 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 t
he Universal and Group bits of an IEEE link-layer address are mapped into an IPv
6 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> <front>
<title>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms</title> <title>IEEE Standard for Ethernet</title>
<author initials='D.' surname='Thaler' fullname='D. Thaler'><organization /></au <seriesInfo name="DOI" value="10.1109/IEEESTD.2012.6419735"/>
thor> <seriesInfo name="IEEE Standard" value="802.3-2012"/>
<date year='2017' month='February' /> <author>
<abstract><t>This document discusses how a number of privacy threats apply to te <organization showOnFrontPage="true">IEEE</organization>
chnologies designed for IPv6 over various link-layer protocols, and it provides </author>
advice to protocol designers on how to address such threats in adaptation-layer <date month="December" year="2012"/>
specifications for IPv6 over such links.</t></abstract>
</front> </front>
<seriesInfo name='RFC' value='8065'/>
<seriesInfo name='DOI' value='10.17487/RFC8065'/>
</reference>
<reference anchor="ETHERNET" >
<front>
<title>IEEE Standard for Ethernet</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
<seriesInfo name="IEEE" value="standard"/>
<seriesInfo name="DOI" value="10.1109/ieeestd.2018.8457469"/>
</reference> </reference>
</references>
</references> </references>
<section anchor="compressIPv6" numbered="true" toc="default">
<name>Compression Examples</name>
<section anchor="compressIPv6" title="Compression Examples"> <t>This section gives some scenarios of the compression mechanism for IPv6
/UDP. The goal is to illustrate the behavior of SCHC.</t>
<t>This section gives some scenarios of the compression mechanism for IPv6/UDP. <t>The mechanisms defined in this document can be applied to a Dev that em
The goal is to illustrate the behavior of SCHC.</t> beds some applications running over CoAP. In this example, three flows are consi
dered. The first flow is for the device management based
<t>The mechanisms defined in this document can be applied to a Dev that embeds s on CoAP using Link Local IPv6 addresses and UDP ports 123 and 124 for
ome applications running over CoAP. In this example, three flows are considered. Dev and App, respectively. The second flow is a CoAP server for measurements don
The first flow is for the device management based e by the Dev (using ports 5683) and Global IPv6 Address prefixes alpha::IID/64 t
on CoAP using Link Local IPv6 addresses and UDP ports 123 and 124 for Dev and Ap o beta::1/64.
p, respectively.
The second flow will be a CoAP server for measurements done by the Dev (using po
rts 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 dest ination IPv6 address prefix is gamma::1/64.</t> The last flow is for legacy applications using different ports numbers, the dest ination IPv6 address prefix is gamma::1/64.</t>
<t><xref target="FigStack" format="default"/> presents the protocol stack.
<t><xref target="FigStack"/> presents the protocol stack. IPv6 and UDP are repre IPv6 and UDP are represented with dotted lines since these protocols are compre
sented with dotted lines since these protocols are compressed on the radio link. ssed on the radio link.</t>
</t> <figure anchor="FigStack">
<name>Simplified Protocol Stack for LP-WAN</name>
<figure title="Simplified Protocol Stack for LP-WAN" anchor="FigStack"><artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
<![CDATA[
Management Data Management Data
+----------+---------+---------+ +----------+---------+---------+
| CoAP | CoAP | legacy | | CoAP | CoAP | legacy |
+----||----+---||----+---||----+ +----||----+---||----+---||----+
. UDP . UDP | UDP | . UDP . UDP | UDP |
................................ ................................
. IPv6 . IPv6 . IPv6 . . IPv6 . IPv6 . IPv6 .
+------------------------------+ +------------------------------+
| SCHC Header compression | | SCHC Header compression |
| and fragmentation | | and fragmentation |
+------------------------------+ +------------------------------+
| LPWAN L2 technologies | | LPWAN L2 technologies |
+------------------------------+ +------------------------------+
Dev or NGW Dev or NGW]]></artwork>
</figure>
]]></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>
<figure title="Context Rules" anchor="Fig-fields"><artwork><![CDATA[ <figure anchor="Fig-fields">
<name>Context Rules - Rule 0 and Rule 1</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Rule 0 Rule 0
Special Rule ID used to tag an uncompressed UDP/IPV6 packet. Special RuleID used to tag an uncompressed UDP/IPV6 packet.
Rule 1 Rule 1
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
| Field         |FL|FP|DI| Value   | Match | Comp Decomp|| Sent | | FID |FL|FP|DI| TV | MO | CDA || Sent |
| | | | | | Opera. | Action ||[bits]| | | | | | | | ||[bits]|
+----------------+--+--+--+---------+---------------------++------+ +----------------+--+--+--+---------+---------------------++------+
|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
|IPv6 Length |16|1 |Bi| | ignore | compute-* || | |IPv6 Length |16|1 |Bi| | ignore | compute-* || |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |
|IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | |IPv6 DevPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || | |IPv6 AppPrefix |64|1 |Bi|FE80::/64| equal | not-sent || |
|IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
|UDP DevPort |16|1 |Bi|123 | equal | not-sent || | |UDP DevPort |16|1 |Bi|123 | equal | not-sent || |
|UDP AppPort |16|1 |Bi|124 | equal | not-sent || | |UDP AppPort |16|1 |Bi|124 | equal | not-sent || |
|UDP Length |16|1 |Bi| | ignore | compute-* || | |UDP Length |16|1 |Bi| | ignore | compute-* || |
|UDP checksum |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 Rule 2
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
| Field |FL|FP|DI| Value | Match | Action || Sent | | FID |FL|FP|DI| TV | MO | CDA || Sent |
| | | | | | Opera. | Action ||[bits]| | | | | | | | ||[bits]|
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
|IPv6 Length |16|1 |Bi| | ignore | compute-* || | |IPv6 Length |16|1 |Bi| | ignore | compute-* || |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |
|IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 | |IPv6 DevPrefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 |
| | | | |fe80::/64] mapping| || | | | | | |fe80::/64] mapping| || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 | |IPv6 AppPrefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 |
| | | | |alpha/64,| mapping| || | | | | | |alpha/64,| mapping| || |
| | | | |fe80::64]| | || | | | | | |fe80::64]| | || |
|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
|UDP DevPort |16|1 |Bi|5683 | equal | not-sent || | |UDP DevPort |16|1 |Bi|5683 | equal | not-sent || |
|UDP AppPort |16|1 |Bi|5683 | equal | not-sent || | |UDP AppPort |16|1 |Bi|5683 | equal | not-sent || |
|UDP Length |16|1 |Bi| | ignore | compute-* || | |UDP Length |16|1 |Bi| | ignore | compute-* || |
|UDP checksum |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 Rule 3
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
| Field |FL|FP|DI| Value | Match | Action || Sent | | FID |FL|FP|DI| TV | MO | CDA || Sent |
| | | | | | Opera. | Action ||[bits]| | | | | | | | ||[bits]|
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
|IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || | |IPv6 Version |4 |1 |Bi|6 | ignore | not-sent || |
|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 Diffserv |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || |
|IPv6 Length |16|1 |Bi| | ignore | compute-* || | |IPv6 Length |16|1 |Bi| | ignore | compute-* || |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |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 |Up|255 | ignore | not-sent || |
|IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 | |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 |
|IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || | |IPv6 DevPrefix |64|1 |Bi|alpha/64 | equal | not-sent || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || | |IPv6 AppPrefix |64|1 |Bi|gamma/64 | equal | not-sent || |
|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
|UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 | |UDP DevPort |16|1 |Bi|8720 | MSB(12)| LSB || 4 |
|UDP AppPort |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 Length |16|1 |Bi| | ignore | compute-* || |
|UDP checksum |16|1 |Bi| | ignore | compute-* || | |UDP checksum |16|1 |Bi| | ignore | compute-* || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+]]></artwork
>
]]></artwork></figure> </figure>
<t>Figures <xref target="Fig-fields" format="counter"/> to <xref target="F
<t><xref target="Fig-fields"/> describes a example of a Rule set.</t> ig-fields2" format="counter"/> describe an example of a Rule set.</t>
<t>In this example, 0 was chosen as the special RuleID that tags packets t
<t>In this example, 0 was chosen as the special Rule ID that tags packets that c hat cannot be compressed with any compression Rule.</t>
annot be compressed with any compression Rule.</t> <t>All the fields described in Rules 1-3 are present in the IPv6 and UDP h
eaders. The DevIID value is inferred from the L2 header.</t>
<t>All the fields described in Rules 1-3 are present in the IPv6 and UDP headers <t>Rules 2-3 use global addresses. The way the Dev learns the prefix is no
. The DevIID-DID value is found in the L2 header.</t> t in the scope of the document.</t>
<t>Rule 3 compresses each port number to 4 bits.</t>
<t>Rules 2-3 use global addresses. The way the Dev learns the prefix is not in t </section>
he scope of the document.</t> <section anchor="FragExamples" numbered="true" toc="default">
<name>Fragmentation Examples</name>
<t>Rule 3 compresses each port number to 4 bits.</t> <t>This section provides examples for the various fragment reliability mod
es specified in this document.
</section>
<section anchor="FragExamples" title="Fragmentation Examples">
<t>This section provides examples for the various fragment reliability modes spe
cified in this document.
In the drawings, Bitmaps are shown in their uncompressed form.</t> In the drawings, Bitmaps are shown in their uncompressed form.</t>
<t><xref target="Fig-Example-Unreliable" format="default"/> illustrates th
<t><xref target="Fig-Example-Unreliable"/> illustrates the transmission in No-AC e transmission in No-ACK mode of a SCHC Packet that needs 11 SCHC Fragments. FCN
K mode of a SCHC Packet that needs 11 SCHC Fragments. FCN is 1 bit wide.</t> is 1 bit wide.</t>
<figure anchor="Fig-Example-Unreliable">
<figure title="No-ACK mode, 11 SCHC Fragments" anchor="Fig-Example-Unreliable">< <name>No-ACK Mode, 11 SCHC Fragments</name>
artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
       Sender               Receiver Sender Receiver
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------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 |-----FCN=1 + RCS --->| Integrity check: success
(End)       (End)]]></artwork>
]]></artwork></figure> </figure>
<t>In the following examples, N (the size of the FCN field) is 3 bits. The
<t>In the following examples, N (the size of the FCN field) is 3 bits. The All-1 All-1 FCN value is therefore 7.</t>
FCN value is 7.</t> <t><xref target="Fig-Example-Win-NoLoss-NACK" format="default"/> illustrat
es the transmission in ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles
<t><xref target="Fig-Example-Win-NoLoss-NACK"/> illustrates the transmission in , with one tile per SCHC Fragment, WINDOW_SIZE=7 and no lost SCHC Fragment.</t>
ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles, with one tile per SCH <figure anchor="Fig-Example-Win-NoLoss-NACK">
C Fragment, WINDOW_SIZE=7 and no lost SCHC Fragment.</t> <name>ACK-on-Error Mode, 11 Tiles, One Tile per SCHC Fragment, No Lost S
CHC Fragment</name>
<figure title="ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, no lost <artwork name="" type="" align="left" alt=""><![CDATA[
SCHC Fragment." anchor="Fig-Example-Win-NoLoss-NACK"><artwork><![CDATA[ Sender Receiver
       Sender               Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=3----->| |-----W=0, FCN=3----->|
|-----W=0, FCN=2----->| |-----W=0, FCN=2----->|
|-----W=0, FCN=1----->| |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| |-----W=0, FCN=0----->|
(no ACK) (no ACK)
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4----->| |-----W=1, FCN=4----->|
|--W=1, FCN=7 + RCS-->| Integrity check: success |--W=1, FCN=7 + RCS-->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1 |<-- ACK, W=1, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t><xref target="Fig-Example-Rel-Window-NACK-Loss" format="default"/> illu
<t><xref target="Fig-Example-Rel-Window-NACK-Loss"/> illustrates the transmissio strates the transmission in ACK-on-Error mode of a SCHC Packet fragmented in 11
n in ACK-on-Error mode of a SCHC Packet fragmented in 11 tiles, with one tile pe tiles, with one tile per SCHC Fragment, WINDOW_SIZE=7, and three lost SCHC Fragm
r SCHC Fragment, WINDOW_SIZE=7 and three lost SCHC Fragments.</t> ents.</t>
<figure anchor="Fig-Example-Rel-Window-NACK-Loss">
<figure title="ACK-on-Error mode, 11 tiles, one tile per SCHC Fragment, lost SCH <name>ACK-on-Error Mode, 11 Tiles, One Tile per SCHC Fragment, Lost SCHC
C Fragments." anchor="Fig-Example-Rel-Window-NACK-Loss"><artwork><![CDATA[ Fragments</name>
        Sender             Receiver <artwork name="" type="" align="left" alt=""><![CDATA[
Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3----->| |-----W=0, FCN=3----->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|-----W=0, FCN=1----->| |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| 6543210 |-----W=0, FCN=0----->| 6543210
|<-- ACK, W=0, C=0 ---| Bitmap:1101011 |<-- ACK, W=0, C=0 ---| Bitmap:1101011
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=2----->| |-----W=0, FCN=2----->|
(no ACK) (no ACK)
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->| |-----W=1, FCN=4--X-->|
|- W=1, FCN=7 + RCS ->| Integrity check: failure |- W=1, FCN=7 + RCS ->| Integrity check: failure
|<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001
|-----W=1, FCN=4----->| Integrity check: success |-----W=1, FCN=4----->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1 |<-- ACK, W=1, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t><xref target="Figure-Example-ACK-on-Error-VarMTU" format="default"/> sh
<t><xref target="Figure-Example-ACK-on-Error-VarMTU"/> shows an example of a tra ows an example of a transmission in ACK-on-Error mode of a SCHC Packet fragmente
nsmission in ACK-on-Error mode of a SCHC Packet fragmented in d in
73 tiles, with N=5, WINDOW_SIZE=28, M=2 and 3 lost SCHC Fragments.</t> 73 tiles, with N=5, WINDOW_SIZE=28, M=2, and three lost SCHC Fragments.</t>
<figure anchor="Figure-Example-ACK-on-Error-VarMTU">
<figure title="ACK-on-Error mode, variable MTU." anchor="Figure-Example-ACK-on-E <name>ACK-on-Error Mode, Variable MTU</name>
rror-VarMTU"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0, FCN=27----->| 4 tiles sent |-----W=0, FCN=27----->| 4 tiles sent
|-----W=0, FCN=23----->| 4 tiles sent |-----W=0, FCN=23----->| 4 tiles sent
|-----W=0, FCN=19----->| 4 tiles sent |-----W=0, FCN=19----->| 4 tiles sent
|-----W=0, FCN=15--X-->| 4 tiles sent (not received) |-----W=0, FCN=15--X-->| 4 tiles sent (not received)
|-----W=0, FCN=11----->| 4 tiles sent |-----W=0, FCN=11----->| 4 tiles sent
|-----W=0, FCN=7 ----->| 4 tiles sent |-----W=0, FCN=7 ----->| 4 tiles sent
|-----W=0, FCN=3 ----->| 4 tiles sent |-----W=0, FCN=3 ----->| 4 tiles sent
|-----W=1, FCN=27----->| 4 tiles sent |-----W=1, FCN=27----->| 4 tiles sent
|-----W=1, FCN=23----->| 4 tiles sent |-----W=1, FCN=23----->| 4 tiles sent
|-----W=1, FCN=19----->| 4 tiles sent |-----W=1, FCN=19----->| 4 tiles sent
|-----W=1, FCN=15----->| 4 tiles sent |-----W=1, FCN=15----->| 4 tiles sent
|-----W=1, FCN=11----->| 4 tiles sent |-----W=1, FCN=11----->| 4 tiles sent
|-----W=1, FCN=7 ----->| 4 tiles sent |-----W=1, FCN=7 ----->| 4 tiles sent
|-----W=1, FCN=3 --X-->| 4 tiles sent (not received) |-----W=1, FCN=3 --X-->| 4 tiles sent (not received)
|-----W=2, FCN=27----->| 4 tiles sent |-----W=2, FCN=27----->| 4 tiles sent
|-----W=2, FCN=23----->| 4 tiles sent |-----W=2, FCN=23----->| 4 tiles sent
^ |-----W=2, FCN=19----->| 1 tile sent ^ |-----W=2, FCN=19----->| 1 tile sent
| |-----W=2, FCN=18----->| 1 tile sent | |-----W=2, FCN=18----->| 1 tile sent
| |-----W=2, FCN=17----->| 1 tile sent | |-----W=2, FCN=17----->| 1 tile sent
|-----W=2, FCN=16----->| 1 tile sent |-----W=2, FCN=16----->| 1 tile sent
s |-----W=2, FCN=15----->| 1 tile sent s |-----W=2, FCN=15----->| 1 tile sent
m |-----W=2, FCN=14----->| 1 tile sent m |-----W=2, FCN=14----->| 1 tile sent
a |-----W=2, FCN=13--X-->| 1 tile sent (not received) a |-----W=2, FCN=13--X-->| 1 tile sent (not received)
l |-----W=2, FCN=12----->| 1 tile sent l |-----W=2, FCN=12----->| 1 tile sent
l |---W=2, FCN=31 + RCS->| Integrity check: failure l |---W=2, FCN=31 + RCS->| Integrity check: failure
e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111
r |-----W=0, FCN=15----->| 1 tile sent r |-----W=0, FCN=15----->| 1 tile sent
|-----W=0, FCN=14----->| 1 tile sent |-----W=0, FCN=14----->| 1 tile sent
L |-----W=0, FCN=13----->| 1 tile sent L |-----W=0, FCN=13----->| 1 tile sent
2 |-----W=0, FCN=12----->| 1 tile sent 2 |-----W=0, FCN=12----->| 1 tile sent
|<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000
M |-----W=1, FCN=3 ----->| 1 tile sent M |-----W=1, FCN=3 ----->| 1 tile sent
T |-----W=1, FCN=2 ----->| 1 tile sent T |-----W=1, FCN=2 ----->| 1 tile sent
U |-----W=1, FCN=1 ----->| 1 tile sent U |-----W=1, FCN=1 ----->| 1 tile sent
|-----W=1, FCN=0 ----->| 1 tile sent |-----W=1, FCN=0 ----->| 1 tile sent
| |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001
| |-----W=2, FCN=13----->| Integrity check: success | |-----W=2, FCN=13----->| Integrity check: success
V |<--- ACK, W=2, C=1 ---| C=1 V |<--- ACK, W=2, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t>In this example, the L2 MTU becomes reduced just before sending the "W=
<t>In this example, the L2 MTU becomes reduced just before sending the “W=2, FCN 2, FCN=19" fragment, leaving space for only one tile in each forthcoming SCHC Fr
=19” fragment, leaving space for only 1 tile in each forthcoming SCHC Fragment. agment.
Before retransmissions, the 73 tiles are carried by a total of 25 SCHC Fragments Before retransmissions, the 73 tiles are carried by a total of 25 SCHC Fragments
, the last 9 being of smaller size.</t> , the last nine being of smaller size.</t>
<t>Note: other sequences of events (e.g., regarding when ACKs are sent by
<t>Note: other sequences of events (e.g., regarding when ACKs are sent by the Re the Receiver) are also allowed by this specification. Profiles may restrict this
ceiver) are also allowed by this specification. Profiles may restrict this flexi flexibility.</t>
bility.</t> <t><xref target="Fig-Example-Rel-Window-ACK-NoLoss" format="default"/> ill
ustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in 11 t
<t><xref target="Fig-Example-Rel-Window-ACK-NoLoss"/> illustrates the transmissi iles, with one tile per SCHC Fragment, with N=3, WINDOW_SIZE=7, and no loss.</t>
on in ACK-Always mode of a SCHC Packet fragmented in 11 tiles, with one tile per <figure anchor="Fig-Example-Rel-Window-ACK-NoLoss">
SCHC Fragment, with N=3, WINDOW_SIZE=7 and no loss.</t> <name>ACK-Always Mode, 11 Tiles, One Tile per SCHC Fragment, No Loss</na
me>
<figure title="ACK-Always mode, 11 tiles, one tile per SCHC Fragment, no loss." <artwork name="" type="" align="left" alt=""><![CDATA[
anchor="Fig-Example-Rel-Window-ACK-NoLoss"><artwork><![CDATA[ Sender Receiver
       Sender               Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=3----->| |-----W=0, FCN=3----->|
|-----W=0, FCN=2----->| |-----W=0, FCN=2----->|
|-----W=0, FCN=1----->| |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| |-----W=0, FCN=0----->|
|<-- ACK, W=0, C=0 ---| Bitmap:1111111 |<-- ACK, W=0, C=0 ---| Bitmap:1111111
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4----->| |-----W=1, FCN=4----->|
|--W=1, FCN=7 + RCS-->| Integrity check: success |--W=1, FCN=7 + RCS-->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1 |<-- ACK, W=1, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t><xref target="Fig-Example-Rel-Window-ACK-Loss" format="default"/> illus
<t><xref target="Fig-Example-Rel-Window-ACK-Loss"/> illustrates the transmission trates the transmission in ACK-Always mode of a SCHC Packet fragmented in 11 til
in ACK-Always mode of a SCHC Packet fragmented in 11 tiles, with one tile per S es, with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7 and three lost SCHC Frag
CHC Fragment, N=3, WINDOW_SIZE=7 and three lost SCHC Fragments.</t> ments.</t>
<figure anchor="Fig-Example-Rel-Window-ACK-Loss">
<figure title="ACK-Always mode, 11 tiles, one tile per SCHC Fragment, three lost <name>ACK-Always Mode, 11 Tiles, One Tile per SCHC Fragment, Three Lost
SCHC Fragments." anchor="Fig-Example-Rel-Window-ACK-Loss"><artwork><![CDATA[ SCHC Fragments</name>
       Sender               Receiver <artwork name="" type="" align="left" alt=""><![CDATA[
Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3----->| |-----W=0, FCN=3----->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|-----W=0, FCN=1----->| |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| 6543210 |-----W=0, FCN=0----->| 6543210
|<-- ACK, W=0, C=0 ---| Bitmap:1101011 |<-- ACK, W=0, C=0 ---| Bitmap:1101011
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=2----->| |-----W=0, FCN=2----->|
|<-- ACK, W=0, C=0 ---| Bitmap:1111111 |<-- ACK, W=0, C=0 ---| Bitmap:1111111
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->| |-----W=1, FCN=4--X-->|
|--W=1, FCN=7 + RCS-->| Integrity check: failure |--W=1, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001
|-----W=1, FCN=4----->| Integrity check: success |-----W=1, FCN=4----->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1 |<-- ACK, W=1, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-A" format="default"/
<t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-A"/> illustrates the trans > illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in
mission in ACK-Always mode of a SCHC Packet fragmented in 6 tiles, six tiles,
with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments a with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments,
nd only one retry needed to recover each lost SCHC Fragment.</t> and only one retry needed to recover each lost SCHC Fragment.</t>
<figure anchor="Fig-Example-Rel-Window-ACK-Loss-Last-A">
<figure title="ACK-Always mode, 6 tiles, <name>ACK-Always Mode, Six Tiles, One Tile per SCHC Fragment, Three Lost
one tile per SCHC Fragment, three lost SCHC Fragments." anchor="Fig-Example-Rel- SCHC Fragments</name>
Window-ACK-Loss-Last-A"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->| |-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + RCS-->| Integrity check: failure |--W=0, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->| Integrity check: failure |-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->| Integrity check: failure |-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2----->| Integrity check: success |-----W=0, FCN=2----->| Integrity check: success
|<-- ACK, W=0, C=1 ---| C=1 |<-- ACK, W=0, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-B" format="default"/
<t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-B"/> illustrates the trans > illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in
mission in ACK-Always mode of a SCHC Packet fragmented in 6 tiles, six tiles,
with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK lost.</t> with one tile per SCHC Fragment, N=3, WINDOW_SIZE=7, three lost SCHC Fragments, and the second SCHC ACK lost.</t>
<figure anchor="Fig-Example-Rel-Window-ACK-Loss-Last-B">
<figure title="ACK-Always mode, 6 tiles, <name>ACK-Always Mode, Six Tiles, One Tile per SCHC Fragment, SCHC ACK L
one tile per SCHC Fragment, SCHC ACK loss." anchor="Fig-Example-Rel-Window-ACK-L oss</name>
oss-Last-B"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->| |-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + RCS-->| Integrity check: failure |--W=0, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->| Integrity check: failure |-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->| Integrity check: failure |-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2----->| Integrity check: success |-----W=0, FCN=2----->| Integrity check: success
|<-X-ACK, W=0, C=1 ---| C=1 |<-X-ACK, W=0, C=1 ---| C=1
timeout | | timeout | |
|--- W=0, ACK REQ --->| ACK REQ |--- W=0, ACK REQ --->| ACK REQ
|<-- ACK, W=0, C=1 ---| C=1 |<-- ACK, W=0, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-C" format="default"/
<t><xref target="Fig-Example-Rel-Window-ACK-Loss-Last-C"/> illustrates the trans > illustrates the transmission in ACK-Always mode of a SCHC Packet fragmented in
mission in ACK-Always mode of a SCHC Packet fragmented in 6 tiles, six tiles,
with N=3, WINDOW_SIZE=7, with three lost SCHC Fragments, and one retransmitted S CHC Fragment lost again.</t> with N=3, WINDOW_SIZE=7, with three lost SCHC Fragments, and one retransmitted S CHC Fragment lost again.</t>
<figure anchor="Fig-Example-Rel-Window-ACK-Loss-Last-C">
<figure title="ACK-Always mode, 6 tiles, <name>ACK-Always Mode, Six Tiles, Retransmitted SCHC Fragment Lost Again
retransmitted SCHC Fragment lost again." anchor="Fig-Example-Rel-Window-ACK-Loss </name>
-Last-C"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->| |-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + RCS-->| Integrity check: failure |--W=0, FCN=7 + RCS-->| Integrity check: failure
|<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->| Integrity check: failure |-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->| Integrity check: failure |-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
timeout| | timeout| |
|--- W=0, ACK REQ --->| ACK REQ |--- W=0, ACK REQ --->| ACK REQ
|<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101
|-----W=0, FCN=2----->| Integrity check: success |-----W=0, FCN=2----->| Integrity check: success
|<-- ACK, W=0, C=1 ---| C=1 |<-- ACK, W=0, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
<t><xref target="Fig-Example-MaxWindFCN" format="default"/> illustrates th
<t><xref target="Fig-Example-MaxWindFCN"/> illustrates the transmission in ACK-A e transmission in ACK-Always mode of a SCHC Packet fragmented in 28 tiles,
lways mode of a SCHC Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5, WINDOW_SIZE=24, and two lost SCHC Fragment
with one tile per SCHC Fragment, N=5, WINDOW_SIZE=24 and two lost SCHC Fragments s.</t>
.</t> <figure anchor="Fig-Example-MaxWindFCN">
<name>ACK-Always Mode, 28 Tiles, One Tile per SCHC Fragment, Lost SCHC F
<figure title="ACK-Always mode, 28 tiles, ragments</name>
one tile per SCHC Fragment, lost SCHC Fragments." anchor="Fig-Example-MaxWindFCN <artwork name="" type="" align="left" alt=""><![CDATA[
"><artwork><![CDATA[
Sender Receiver Sender Receiver
|-----W=0, FCN=23----->| |-----W=0, FCN=23----->|
|-----W=0, FCN=22----->| |-----W=0, FCN=22----->|
|-----W=0, FCN=21--X-->| |-----W=0, FCN=21--X-->|
|-----W=0, FCN=20----->| |-----W=0, FCN=20----->|
|-----W=0, FCN=19----->| |-----W=0, FCN=19----->|
|-----W=0, FCN=18----->| |-----W=0, FCN=18----->|
|-----W=0, FCN=17----->| |-----W=0, FCN=17----->|
|-----W=0, FCN=16----->| |-----W=0, FCN=16----->|
|-----W=0, FCN=15----->| |-----W=0, FCN=15----->|
skipping to change at line 2659 skipping to change at line 2391
| | | |
|<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111
|-----W=0, FCN=21----->| |-----W=0, FCN=21----->|
|-----W=0, FCN=10----->| |-----W=0, FCN=10----->|
|<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111
|-----W=1, FCN=23----->| |-----W=1, FCN=23----->|
|-----W=1, FCN=22----->| |-----W=1, FCN=22----->|
|-----W=1, FCN=21----->| |-----W=1, FCN=21----->|
|--W=1, FCN=31 + RCS-->| Integrity check: success |--W=1, FCN=31 + RCS-->| Integrity check: success
|<--- ACK, W=1, C=1 ---| C=1 |<--- ACK, W=1, C=1 ---| C=1
(End) (End)]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="FSM" numbered="true" toc="default">
<section anchor="FSM" title="Fragmentation State Machines"> <name>Fragmentation State Machines</name>
<t>The fragmentation state machines of the sender and the receiver, one fo
<t>The fragmentation state machines of the sender and the receiver, one for each r each of the different reliability modes, are described in the following figure
of the different reliability modes, are described in the following figures:</t> s:</t>
<figure anchor="Fig-NoACKModeSnd">
<figure title="Sender State Machine for the No-ACK Mode" anchor="Fig-NoACKModeSn <name>Sender State Machine for the No-ACK Mode</name>
d"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+===========+ +===========+
+------------+ Init | +------------+ Init |
| FCN=0 +===========+ | FCN=0 +===========+
| No Window | No Window
| No Bitmap | No Bitmap
| +-------+ | +-------+
| +========+==+ | More Fragments | +========+==+ | More Fragments
| | | <--+ ~~~~~~~~~~~~~~~~~~~~ | | | <--+ ~~~~~~~~~~~~~~~~~~~~
+--------> | Send | send Fragment (FCN=0) +--------> | Send | send Fragment (FCN=0)
+===+=======+ +===+=======+
| last fragment | last fragment
| ~~~~~~~~~~~~ | ~~~~~~~~~~~~
| FCN = 1 | FCN = 1
v send fragment+RCS v send fragment+RCS
+============+ +============+
| END | | END |
+============+ +============+]]></artwork>
]]></artwork></figure> </figure>
<figure anchor="Fig-NoACKModeRcv">
<figure title="Receiver State Machine for the No-ACK Mode" anchor="Fig-NoACKMode <name>Receiver State Machine for the No-ACK Mode</name>
Rcv"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------+ Not All-1 +------+ Not All-1
+==========+=+ | ~~~~~~~~~~~~~~~~~~~ +==========+=+ | ~~~~~~~~~~~~~~~~~~~
| + <--+ set Inactivity Timer | + <--+ set Inactivity Timer
| RCV Frag +-------+ | RCV Frag +-------+
+=+===+======+ |All-1 & +=+===+======+ |All-1 &
All-1 & | | |RCS correct All-1 & | | |RCS correct
RCS wrong | |Inactivity | RCS wrong | |Inactivity |
| |Timer Exp. | | |Timer Exp. |
v | | v | |
+==========++ | v +==========++ | v
| Error |<-+ +========+==+ | Error |<-+ +========+==+
+===========+ | END | +===========+ | END |
+===========+ +===========+]]></artwork>
</figure>
]]></artwork></figure> <figure anchor="Fig-ACKAlwaysSnd">
<name>Sender State Machine for the ACK-Always Mode</name>
<figure title="Sender State Machine for the ACK-Always Mode" anchor="Fig-ACKAlwa <artwork name="" type="" align="left" alt=""><![CDATA[
ysSnd"><artwork><![CDATA[
+=======+ +=======+
| INIT | FCN!=0 & more frags | INIT | FCN!=0 & more frags
| | ~~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~~~~~
+======++ +--+ send Window + frag(FCN) +======++ +--+ send Window + frag(FCN)
W=0 | | | FCN- W=0 | | | FCN-
Clear lcl_bm | | v set lcl_bm Clear lcl_bm | | v set lcl_bm
FCN=max value | ++==+========+ FCN=max value | ++==+========+
+> | | +> | |
+---------------------> | SEND | +---------------------> | SEND |
| +==+===+=====+ | +==+===+=====+
skipping to change at line 2739 skipping to change at line 2472
+----+ Wait | |Frag | +----+ Wait | |Frag |
not expected wnd | | Bitmap | +=======+ not expected wnd | | Bitmap | +=======+
~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp |
discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ |
| | | ^ ^ |reSend(empty)All-* | | | | ^ ^ |reSend(empty)All-* |
| | | | | |Set Retrans_Timer | | | | | | |Set Retrans_Timer |
| | | | +--+Attempt++ | | | | | +--+Attempt++ |
C_bit==1 & | | | +-------------------------+ C_bit==1 & | | | +-------------------------+
Recv_window==window & | | | all missing frags sent Recv_window==window & | | | all missing frags sent
no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~| |  |   Set Retrans_Timer                 ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer
Stop Retrans_Timer| | | Stop Retrans_Timer| | |
+=============+ | | | +=============+ | | |
| END +<--------+ | | | END +<--------+ | |
+=============+ | | Attempt > MAX_ACK_REQUESTS +=============+ | | Attempt > MAX_ACK_REQUESTS
All-1 Window & | | ~~~~~~~~~~~~~~~~~~ All-1 Window & | | ~~~~~~~~~~~~~~~~~~
C_bit ==0 & | v Send Abort C_bit ==0 & | v Send Abort
lcl_bm==recv_bm | +=+===========+ lcl_bm==recv_bm | +=+===========+
            ~~~~~~~~~~~~ +>| ERROR | ~~~~~~~~~~~~ +>| ERROR |
Send Abort +=============+ Send Abort +=============+]]></artwork>
</figure>
]]></artwork></figure> <figure anchor="Fig-ACKAlwaysRcv">
<name>Receiver State Machine for the ACK-Always Mode</name>
<figure title="Receiver State Machine for the ACK-Always Mode" anchor="Fig-ACKAl <artwork name="" type="" align="left" alt=""><![CDATA[
waysRcv"><artwork><![CDATA[
Not All- & w=expected +---+ +---+w = Not expected Not All- & w=expected +---+ +---+w = Not expected
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~
Set lcl_bm(FCN) | v v |discard Set lcl_bm(FCN) | v v |discard
++===+===+===+=+ ++===+===+===+=+
+---------------------+     Rcv     +--->* ABORT +---------------------+ Rcv +--->* ABORT
| +------------------+   Window     | | +------------------+ Window |
| |                 +=====+==+=====+ | | +=====+==+=====+
| |       All-0 & w=expect |  ^ w =next & not-All | | All-0 & w=expect | ^ w =next & not-All
| | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~
| | set lcl_bm(FCN) | |expected = next window | | set lcl_bm(FCN) | |expected = next window
| | send lcl_bm | |Clear lcl_bm | | send lcl_bm | |Clear lcl_bm
| | | | | | | |
| | w=expected & not-All | | | | w=expected & not-All | |
| | ~~~~~~~~~~~~~~~~~~ | | | | ~~~~~~~~~~~~~~~~~~ | |
| | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0
| | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~ | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~
| | send lcl_bm | | | | | | expected = nxt wnd | | send lcl_bm | | | | | | expected = nxt wnd
| | v | v | | | Clear lcl_bm | | v | v | | | Clear lcl_bm
skipping to change at line 2806 skipping to change at line 2539
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 |
|set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ |
|send lcl_bm | +<+Send lcl_bm | |send lcl_bm | +<+Send lcl_bm |
+-------------------------->+ END | | +-------------------------->+ END | |
+==========+<---------------+ +==========+<---------------+
--->* ABORT --->* ABORT
In any state In any state
on receiving a SCHC ACK REQ on receiving a SCHC ACK REQ
Send a SCHC ACK for the current window Send a SCHC ACK for the current window]]></artwork>
                            </figure>
]]></artwork></figure> <figure anchor="Fig-ACKonerrorSnd">
<name>Sender State Machine for the ACK-on-Error Mode</name>
<figure title="Sender State Machine for the ACK-on-Error Mode" anchor="Fig-ACKon <artwork name="" type="" align="left" alt=""><![CDATA[
errorSnd"><artwork><![CDATA[
+=======+ +=======+
| | | |
| INIT | | INIT |
| | FCN!=0 & more frags | | FCN!=0 & more frags
+======++ ~~~~~~~~~~~~~~~~~~~~~~ +======++ ~~~~~~~~~~~~~~~~~~~~~~
Frag RuleID trigger | +--+ Send cur_W + frag(FCN); Frag RuleID trigger | +--+ Send cur_W + frag(FCN);
~~~~~~~~~~~~~~~~~~~ | | | FCN--; ~~~~~~~~~~~~~~~~~~~ | | | FCN--;
cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp] cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp]
clear [cur_W, Bmp_n];| | v clear [cur_W, Bmp_n];| | v
clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND
+->+ | cur_W==rcv_W & +->+ | cur_W==rcv_W &
**BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp
+-------------------------->+ | & more frags +-------------------------->+ | & more frags
| +----------------------->+ | ~~~~~~~~~~~~ | +----------------------->+ | ~~~~~~~~~~~~
| | ++===+=========+ cur_W++; | | ++==+==========+ cur_W++;
| | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n]
| | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~
| | set cur_Bmp; | |set [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; | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+RCS;
| | set Retrans_Timer| |set Retrans_Timer | | set Retrans_Timer| |set Retrans_Timer
| | | | +-----------------------------------+ | | | | +---------------------------------+
| |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| | | | | |cur_W == |
| |more Frags | | | ~~~~~~~~~~~~~~~~~~~ | | |Retrans_Timer expires & | | | rcv_W & [cur_W,Bmp_n]!=rcv_Bmp|
| |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W | | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ |
| |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &| | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W |
| |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp| | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &|
| |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp|
| +-------------------+ | | Resend | Attempts++;| | |cur_W++ +=====+==+=+=+==+ +=+=========+ ~~~~~~~~~~~|
+----------------------+ Wait x ACK | | Missing | W=Wn | | +-------------------+ | | Resend | Attempts++;|
+--------------------->+ | | Frags(W) +<-------------+ +----------------------+ Wait x ACK | | Missing | W=Wn |
| rcv_W==Wn &+-+ | +======+====+ +--------------------->+ | | Frags(W) +<-----------+
| [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ | | rcv_W==Wn &+-+ | +======+====+
| ~~~~~~~~~~~~~~| ^ | | | ^ | | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+=+ |
| send (cur_W,+--+ | | | +-------------+ | ~~~~~~~~~~~~~~| ^ | | | ^ |
| send (cur_W,+--+ | | | +------------+
| ALL-0-empty) | | | all missing frag sent(W) | ALL-0-empty) | | | all missing frag sent(W)
| | | | ~~~~~~~~~~~~~~~~~ | | | | ~~~~~~~~~~~~~~~~~
| Retrans_Timer expires &| | | set Retrans_Timer | Retrans_Timer expires &| | | set Retrans_Timer
| No more Frags| | | | No more Frags| | |
| ~~~~~~~~~~~~~~| | | | ~~~~~~~~~~~~~~| | |
| stop Retrans_Timer;| | | | stop Retrans_Timer;| | |
|(re)send frag(All-1)+RCS | | | |(re)send frag(All-1)+RCS | | |
+-------------------------+ | | +-------------------------+ | |
cur_W==rcv_W&| | cur_W==rcv_W&| |
[cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS
No more Frags & RCS flag==OK| | ~~~~~~~~~~ No more Frags & RCS flag==OK| | ~~~~~~~~~~
~~~~~~~~~~~~~~~~~~| | send Abort ~~~~~~~~~~~~~~~~~~| | send Abort
+=========+stop Retrans_Timer| | +===========+ +=========+stop Retrans_Timer| | +===========+
| END +<-----------------+ +->+ ERROR | | END +<-----------------+ +->+ ERROR |
+=========+ +===========+ +=========+ +===========+]]></artwork>
]]></artwork></figure> </figure>
<t>This is an example only. It is not normative.
<t>This is an example only. It is not normative. The specification in <xref target="ACK-on-Error-sender" format="default"/> allow
The specification in <xref target="ACK-on-Error-sender"/> allows for sequences o s for sequences of operations different from the one shown here.</t>
f operations different from the one shown here.</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
+=======+ New frag RuleID received +=======+ New frag RuleID received
| | ~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~
| INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]);
+=======+ |sync=0 +=======+ |sync=0
| |
Not All* & rcv_W==cur_W+---+ | +---+ Not All* & rcv_W==cur_W+---+ | +--+
~~~~~~~~~~~~~~~~~~~~ | | | | (E) ~~~~~~~~~~~~~~~~~~~~ | | | | (E)
set[cur_W,Bmp_n(FCN)]| v v v | set[cur_W,Bmp_n(FCN)]| v v v |
++===+=+=+===+=+ ++===+=+=+==+=+
+----------------------+ +--+ All-0&Full[cur_W,Bmp_n] +----------------------+ +--+ All-0&Full[cur_W,Bmp_n]
| ABORT *<---+ Rcv Window | | ~~~~~~~~~~ | ABORT *<---+ Rcv Window | | ~~~~~~~~~~
| +-------------------+ +<-+ cur_W++;set Inact_timer; | +-------------------+ +<-+ cur_W++;set Inact_timer;
| | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n] | | +->+=+=+=+=+=+===+ clear [cur_W,Bmp_n]
| | All-0 empty(Wn)| | | | ^ ^ | | All-0 empty(Wn)| | | | ^ ^
| | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0; | | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0;
| | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n]) | | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n])
| | | | | |& All* || last_miss_frag | | | | | |& All* || last_miss_frag
| | | | | |~~~~~~~~~~~~~~~~~~~~~~ | | | | | |~~~~~~~~~~~~~~~~~~~~~~
| | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); | | All* & rcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]);
| | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n])
| |&no_full([cur_W,Bmp_n])| |(E)| | |&no_full([cur_W,Bmp_n])| |(E)|
| | ~~~~~~~~~~~~~~~~ | | | | +========+ | | ~~~~~~~~~~~~~~~~ | | | | +========+
| | sendACK([cur_W,Bmp_n])| | | | | Error/ | | | sendACK([cur_W,Bmp_n])| | | | | Error/ |
| | | | | | +----+ | Abort | | | | | | | +----+ | Abort |
| | v v | | | | +===+====+ | | v v | | | | +===+====+
| | +===+=+=+=+===+=+ (D) ^ | | +===+=+=+=+===+=+ (D) ^
| | +--+ Wait x | | | | | +--+ Wait x | | |
| | All-0 empty(Wn)+->| Missing Frags |<-+ | | | All-0 empty(Wn)+->| Missing Frags |<-+ |
| | ~~~~~~~~~~~~~~ +=============+=+ | | | ~~~~~~~~~~~~~~ +=============+=+ |
| | sendACK([Wn,Bmp_n]) +--------------+ | | sendACK([Wn,Bmp_n]) +--------------+
| | *ABORT | | *ABORT
v v v v
(A)(B) (A)(B)
(D) All* || last_miss_frag (D) All* || last_miss_frag
(C) All* & sync>0 & rcv_W!=cur_W & sync>0 (C) All* & sync>0 & rcv_W!=cur_W & sync>0
~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n])
Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~
sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)];
sendACK([Wn,Bmp_n]);sync-- 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> ABORT-->* Uplink Only &
<figure title="Receiver State Machine for the ACK-on-Error Mode" anchor="Fig-ACK Inact_Timer expires
onerrorRcv"><artwork><![CDATA[ (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 anchor="Fig-ACKonerrorRcv">
<name>Receiver State Machine for the ACK-on-Error Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
(A)(B) (A)(B)
| | | |
| | All-1 & rcv_W==cur_W & RCS!=OK All-0 empty(Wn) | | All-1 & rcv_W==cur_W & RCS!=OK All-0 empty(Wn)
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~
| | sendACK([cur_W,Bmp_n],C=0) | v sendACK([Wn,Bmp_n]) | | sendACK([cur_W,Bmp_n],C=0) | v sendACK([Wn,Bmp_n])
| | +===========+=++ | | +===========+=++
| +--------------------->+ Wait End +-+ | +--------------------->+ Wait End +-+
| +=====+=+====+=+ | All-1 | +=====+=+====+=+ | All-1
| rcv_W==cur_W & RCS==OK | | ^ | & rcv_W==cur_W | rcv_W==cur_W & RCS==OK | | ^ | & rcv_W==cur_W
| ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & RCS!=OK | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & RCS!=OK
| sendACK([cur_W,Bmp_n],C=1) | | ~~~~~~~~~~~~~~~~~~~ | sendACK([cur_W,Bmp_n],C=1) | | ~~~~~~~~~~~~~~~~~~~
| | | sendACK([cur_W,Bmp_n],C=0); | | | sendACK([cur_W,Bmp_n],C=0);
| | | Attempts++ | | | Attempts++
|All-1 & Full([cur_W,Bmp_n]) | | |All-1 & Full([cur_W,Bmp_n]) | |
|& RCS==OK & sync==0 | +-->* ABORT |& RCS==OK & sync==0 | +-->* ABORT
|~~~~~~~~~~~~~~~~~~~ v |~~~~~~~~~~~~~~~~~~~ v
|sendACK([cur_W,Bmp_n],C=1) +=+=========+ |sendACK([cur_W,Bmp_n],C=1) +=+=========+
+---------------------------->+ END | +---------------------------->+ END |
+===========+ +===========+]]></artwork>
</figure>
]]></artwork></figure> </section>
<section anchor="SCHCParams" numbered="true" toc="default">
</section> <name>SCHC Parameters</name>
<section anchor="SCHCParams" title="SCHC Parameters"> <t>This section lists the information that needs to be provided in the LPW
AN technology-specific documents.</t>
<t>This section lists the information that needs to be provided in the LPWAN tec <ul spacing="normal">
hnology-specific documents.</t> <li>Most common uses cases, deployment scenarios.</li>
<li>Mapping of the SCHC architectural elements onto the LPWAN architectu
<t><list style="symbols"> re.</li>
<t>Most common uses cases, deployment scenarios</t> <li>Assessment of LPWAN integrity checking.</li>
<t>Mapping of the SCHC architectural elements onto the LPWAN architecture</t> <li>Various potential channel conditions for the technology and the corr
<t>Assessment of LPWAN integrity checking</t> esponding recommended use of SCHC C/D and SCHC F/R.</li>
<t>Various potential channel conditions for the technology and the correspondi </ul>
ng recommended use of SCHC C/D and F/R</t> <t>This section lists the parameters that need to be defined in the Profil
</list></t> e.</t>
<ul spacing="normal">
<t>This section lists the parameters that need to be defined in the Profile.</t> <li>RuleID numbering scheme, fixed-size or variable-size RuleIDs, number
of Rules, the way the RuleID is transmitted.</li>
<t><list style="symbols"> <li>maximum packet size that should ever be reconstructed by SCHC decomp
<t>Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs, number of ression (MAX_PACKET_SIZE). See <xref target="SecConsiderations" format="default"
Rules, the way the Rule ID is transmitted</t> />.</li>
<t>maximum packet size that should ever be reconstructed by SCHC Decompression <li>Padding: size of the L2 Word (for most LPWAN technologies, this woul
(MAX_PACKET_SIZE). See <xref target="SecConsiderations"/>.</t> d be a byte; for some technologies, a bit).</li>
<t>Padding: size of the L2 Word (for most LPWAN technologies, this would be a <li>
byte; for some technologies, a bit)</t> <t>Decision to use SCHC fragmentation mechanism or not. If yes, the do
<t>Decision to use SCHC fragmentation mechanism or not. If yes, the document m cument must describe: </t>
ust describe: <list style="symbols"> <ul spacing="normal">
<t>reliability mode(s) used, in which cases (e.g., based on link channel c <li>reliability mode(s) used, in which cases (e.g., based on link ch
ondition)</t> annel condition).</li>
<t>Rule ID values assigned to each mode in use</t> <li>RuleID values assigned to each mode in use.</li>
<t>presence and number of bits for DTag (T) for each Rule ID value, lifeti <li>presence and number of bits for DTag (T) for each RuleID value,
me of DTag at the receiver</t> lifetime of DTag at the receiver.</li>
<t>support for interleaved packet transmission, to what extent</t> <li>support for interleaved packet transmission, to what extent.</li
<t>WINDOW_SIZE, for modes that use windows</t> >
<t>number of bits for W (M) for each Rule ID value, for modes that use win <li>WINDOW_SIZE, for modes that use windows.</li>
dows</t> <li>number of bits for W (M) for each RuleID value, for modes that u
<t>number of bits for FCN (N) for each Rule ID value</t> se windows.</li>
<t>what makes an All-0 SCHC Fragment and a SCHC ACK REQ distinguishable (s <li>number of bits for FCN (N) for each RuleID value, meaning of the
ee <xref target="NotLastFrag"/>).</t> FCN values.</li>
<t>what makes an All-1 SCHC Fragment and a SCHC Sender-Abort distinguishab <li>what makes an All-0 SCHC Fragment and a SCHC ACK REQ distinguish
le (see <xref target="LastFrag"/>).</t> able (see <xref target="NotLastFrag" format="default"/>).</li>
<t>size of RCS and algorithm for its computation, for each Rule ID, if dif <li>what makes an All-1 SCHC Fragment and a SCHC Sender-Abort distin
ferent from the default CRC32. Byte fill-up with zeroes or other mechanism, to b guishable (see <xref target="LastFrag" format="default"/>).</li>
e specified.</t> <li>for RuleIDs that use ACK-on-Error mode: when the last tile of a
<t>Retransmission Timer duration for each Rule ID value, if applicable to SCHC Packet is to be sent in a Regular SCHC Fragment, alone in an All-1 SCHC Fra
the SCHC F/R mode</t> gment or with any of these two methods.</li>
<t>Inactivity Timer duration for each Rule ID value, if applicable to the <li>for RuleIDs that use ACK-on-Error mode: if the penultimate tile
SCHC F/R mode</t> of a SCHC Packet is of the regular size only or if it can also be one L2 Word sh
<t>MAX_ACK_REQUESTS value for each Rule ID value, if applicable to the SCH orter.</li>
C F/R mode</t> <li>for RuleIDs that use ACK-on-Error mode: times at which the sende
</list></t> r must listen for SCHC ACKs.</li>
<t>if L2 Word is wider than a bit and SCHC fragmentation is used, value of the <li>size of RCS and algorithm for its computation, for each RuleID,
padding bits (0 or 1). This is needed if different from the default CRC32. Byte fill-up with zeroes or other mechanism
because the padding bits of the last fragment are included in the RCS computatio , to be specified. Support for UDP checksum elision.</li>
n.</t> <li>Retransmission Timer duration for each RuleID value, if applicab
</list></t> le to the SCHC F/R mode.</li>
<li>Inactivity Timer duration for each RuleID value, if applicable t
<t>A Profile may define a delay to be added after each SCHC message transmission o the SCHC F/R mode.</li>
for compliance with local regulations or other constraints imposed by the appli <li>MAX_ACK_REQUESTS value for each RuleID value, if applicable to t
cations.</t> he SCHC F/R mode.</li>
</ul>
<t><list style="symbols"> </li>
<t>In some LPWAN technologies, as part of energy-saving techniques, <li>if L2 Word is wider than a bit and SCHC fragmentation is used, value
downlink transmission is only possible immediately after an uplink transmission. of the padding bits (0 or 1).</li>
In order to avoid potentially high delay in the downlink transmission of a fragm </ul>
ented SCHC Packet, <t>A Profile may define a delay to be added after each SCHC message transm
the SCHC Fragment receiver may perform an uplink transmission as soon as possibl ission for compliance with local regulations or other constraints imposed by the
e after reception of a SCHC applications.</t>
<ul spacing="normal">
<li>In some LPWAN technologies, as part of energy-saving techniques,
Downlink transmission is only possible immediately after an Uplink transmission.
In order to avoid potentially high delay in the Downlink transmission of a fragm
ented SCHC Packet,
the SCHC Fragment receiver may perform an Uplink transmission as soon as possibl
e after reception of a SCHC
Fragment that is not the last one. Fragment that is not the last one.
Such uplink transmission may be triggered by the L2 (e.g., an L2 ACK sent in res Such Uplink transmission may be triggered by the L2 (e.g., an L2 ACK sent in res
ponse to a SCHC Fragment encapsulated ponse to a SCHC Fragment encapsulated
in a L2 PDU that requires an L2 ACK) or it may be triggered from an upper layer. in a L2 PDU that requires an L2 ACK) or it may be triggered from an upper layer.
See <xref target="AsymLinks"/>.</t> See <xref target="AsymLinks" format="default"/>.</li>
<t>the following parameters need to be addressed in documents other than this <li>
one but not necessarily in <t>the following parameters need to be addressed in documents other th
the LPWAN technology-specific documents: <list style="symbols"> an this one but not necessarily in
<t>The way the Contexts are provisioned</t> the LPWAN technology-specific documents: </t>
<t>The way the Rules are generated</t> <ul spacing="normal">
</list></t> <li>The way the Contexts are provisioned.</li>
</list></t> <li>The way the Rules are generated.</li>
</ul>
</section> </li>
<section anchor="MultWinSizes" title="Supporting multiple window sizes for fragm </ul>
entation"> </section>
<section anchor="MultWinSizes" numbered="true" toc="default">
<t>For ACK-Always or ACK-on-Error, implementers may opt to support a single wind <name>Supporting Multiple Window Sizes for Fragmentation</name>
ow size or multiple window sizes. The latter, when feasible, may provide perfor <t>For ACK-Always or ACK-on-Error, implementers may opt to support a singl
mance optimizations. For example, a large window size should be used for packet e window size or multiple window sizes. The latter, when feasible, may provide
s that need to be split into a large number of tiles. However, when the number o performance optimizations. For example, a large WINDOW_SIZE should be used for
f tiles required to carry a packet is low, a smaller window size, and thus a sho packets that need to be split into a large number of tiles. However, when the nu
rter Bitmap, may be sufficient to provide reception status on all tiles. If mult mber of tiles required to carry a packet is low, a smaller WINDOW_SIZE and, thus
iple window sizes are supported, the Rule ID signals the window size in use for , a shorter Bitmap, may be sufficient to provide reception status on all tiles.
a specific packet transmission.</t> If multiple window sizes are supported, the RuleID signals what WINDOW_SIZE is i
n use for a specific packet transmission.</t>
</section> </section>
<section anchor="AsymLinks" title="ACK-Always and ACK-on-Error on quasi-bidirect <section anchor="AsymLinks" numbered="true" toc="default">
ional links"> <name>ACK-Always and ACK-on-Error on Quasi-Bidirectional Links</name>
<t>The ACK-Always and ACK-on-Error modes of SCHC F/R are bidirectional pro
<t>The ACK-Always and ACK-on-Error modes of SCHC F/R are bidirectional protocols tocols:
:
they require a feedback path from the reassembler to the fragmenter.</t> they require a feedback path from the reassembler to the fragmenter.</t>
<t>Some LPWAN technologies provide quasi-bidirectional connectivity,
<t>Some LPWAN technologies provide quasi-bidirectional connectivity, whereby a Downlink transmission from the Network Infrastructure can only take pl
whereby a downlink transmission from the Network Infrastructure can only take pl ace
ace right after an Uplink transmission by the Dev.</t>
right after an uplink transmission by the Dev.</t> <t>When using SCHC F/R to send fragmented SCHC Packets Downlink over these
quasi-bidirectional links,
<t>When using SCHC F/R to send fragmented SCHC Packets downlink over these quasi the following situation may arise: if an Uplink SCHC ACK is lost,
-bidirectional links, the SCHC ACK REQ message by the sender could be stuck indefinitely in the Downli
the following situation may arise: if an uplink SCHC ACK is lost, nk queue
the SCHC ACK REQ message by the sender could be stuck indefinitely in the downli
nk queue
at the Network Infrastructure, waiting for a transmission opportunity.</t> at the Network Infrastructure, waiting for a transmission opportunity.</t>
<t>There are many ways by which this deadlock can be avoided.
<t>There are many ways by which this deadlock can be avoided. The Dev application might be sending recurring Uplink messages such as keep-aliv
The Dev application might be sending recurring uplink messages such as keep-aliv e,
e, or the Dev application stack might be sending other recurring Uplink messages as
or the Dev application stack might be sending other recurring uplink messages as part of its operation.
part of its operation.
However, these are out of the control of this generic SCHC specification.</t> 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 specif
<t>In order to cope with quasi-bidirectional links, a SCHC-over-foo specificatio ication may want to amend
n may want to amend
the SCHC F/R specification to add a timer-based retransmission of the SCHC ACK. 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. Below is an example of the suggested behavior for ACK-Always mode.
Because it is an example, <xref target="RFC2119"/> language is deliberately not Because it is an example, <xref target="RFC2119" format="default"/> language is
used here.</t> deliberately not used here.</t>
<t>For Downlink transmission of a fragmented SCHC Packet in ACK-Always mod
<t>For downlink transmission of a fragmented SCHC Packet in ACK-Always mode, the e, the SCHC Fragment receiver may support timer-based SCHC ACK retransmission. I
SCHC Fragment receiver may support timer-based SCHC ACK retransmission. In this n this mechanism, the SCHC Fragment receiver initializes and starts a timer (the
mechanism, the SCHC Fragment receiver initializes and starts a timer (the Uplin UplinkACK Timer) after the transmission of a SCHC ACK, except when the SCHC ACK
kACK Timer) after the transmission of a SCHC ACK, except when the SCHC ACK is se is sent in response to the last SCHC Fragment of a packet (All-1 fragment). In
nt in response to the last SCHC Fragment of a packet (All-1 fragment). In the la the latter case, the SCHC Fragment receiver does not start a timer after transmi
tter case, the SCHC Fragment receiver does not start a timer after transmission ssion of the SCHC ACK.</t>
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 recei
<t>If, after transmission of a SCHC ACK that is not an All-1 fragment, and befor ver receives a SCHC Fragment that belongs to the current window (e.g., a missing
e expiration of the corresponding UplinkACK timer, the SCHC Fragment receiver re SCHC Fragment from the current window) or to the next window, the UplinkACK tim
ceives a SCHC Fragment that belongs to the current window (e.g., a missing SCHC er for the SCHC ACK is stopped. However, if the UplinkACK timer expires, the SCH
Fragment from the current window) or to the next window, the UplinkACK timer for C ACK is resent and the UplinkACK timer is reinitialized and restarted.</t>
the SCHC ACK is stopped. However, if the UplinkACK timer expires, the SCHC ACK <t>The default initial value for the UplinkACK Timer, as well as the maxim
is resent and the UplinkACK timer is reinitialized and restarted.</t> um number of retries for a specific SCHC ACK, denoted MAX_ACK_REQUESTS, is to be
defined in a Profile.
<t>The default initial value for the UplinkACK Timer, as well as the maximum num
ber of retries for a specific SCHC ACK, denoted MAX_ACK_REQUESTS, is to be defin
ed in a Profile.
The initial value of the UplinkACK timer is expected to be greater than that of the Retransmission timer, 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. 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 Fragm ent transmission.</t> One exception to this recommendation is the special case of the All-1 SCHC Fragm ent transmission.</t>
<t>When the SCHC Fragment sender transmits the All-1 SCHC Fragment,
<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 tim es that of the initial UplinkACK Timer). it starts its Retransmission Timer with a large timeout value (e.g., several tim es that of the initial UplinkACK Timer).
If a SCHC ACK is received before expiration of this 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, 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 la st window, or if the SCHC ACK confirms successful reception of all SCHC Fragments of the la st window,
the transmission of the fragmented SCHC Packet is considered complete. 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 t imer, If the timer expires, and no SCHC ACK has been received since the start of the t imer,
the SCHC Fragment sender assumes that the All-1 SCHC Fragment has been successfu lly received the SCHC Fragment sender assumes that the All-1 SCHC Fragment has been successfu lly 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 F ragment receiver, and it also assumes that it is unlikely that several ACKs beco me all lost).</t> (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 F ragment receiver, and it also assumes that it is unlikely that several ACKs beco me all lost).</t>
</section> </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 Spani
sh 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 Uni
versity of Cambridge.</t>
</section>
</back> </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> </rfc>
 End of changes. 213 change blocks. 
3989 lines changed or deleted 2923 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/