One document matched: draft-ietf-6lo-paging-dispatch-00.xml

<?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.0.20 -->

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

<rfc ipr="trust200902" docName="draft-ietf-6lo-paging-dispatch-00" category="std" updates="4944">

<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>

  <front>
    <title>6LoWPAN Paging Dispatch</title>

    <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="editor">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street>Building D - Regus</street> <street>45 Allee des Ormes</street> <street>BP1200</street>
          <city>MOUGINS - Sophia Antipolis</city>
          <code>06254</code>
          <country>FRANCE</country>
        </postal>
        <phone>+33 4 97 23 26 34</phone>
        <email>pthubert@cisco.com</email>
      </address>
    </author>

    <date/>

    <area>Internet</area>
    <workgroup>6lo</workgroup>
    

    <abstract>


<t>This specification introduces a new context switch mechanism for 6LoWPAN compression,
expressed in terms of Pages and signaled by a new Paging Dispatch.</t>
    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving
energy, a very constrained resource in most cases. The other
constraints, such as the memory capacity and the duty cycling of the LLN
devices, derive from that primary concern. Energy is often available
from primary batteries that are expected to last for years, or is scavenged from the
environment in very limited quantities. Any protocol that is intended for
use in LLNs must be designed with the primary concern of saving energy as
a strict requirement.</t>

<t>Controlling the amount of data transmission is one possible venue to save
energy. In a number of LLN standards, the frame size is limited to much
smaller values than the IPv6 maximum transmission unit (MTU) of 1280 bytes.
In particular, an LLN that relies on the classical Physical Layer (PHY)
of IEEE 802.15.4 <xref target="IEEE802154"/> is limited to 127 bytes
per frame. The need to compress IPv6 packets over IEEE 802.15.4 led to
the <xref target="RFC6282">6LoWPAN Header Compression</xref> work (6LoWPAN-HC).
</t>

<t>
As more and more protocols need to be compressed, the encoding capabilities of
the original dispatch defined in the 6lo adaptation layer framework
(<xref target="RFC4944"/>,<xref target="RFC6282"/>) becomes saturated.
This specification introduces a new context switch mechanism for 6LoWPAN
compression, expressed in terms of Pages and signaled by a new Paging Dispatch.
</t>

</section>
<section anchor="terminology" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”,
and “OPTIONAL” in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>

<t>The Terminology used in this document is consistent with and incorporates that 
described in `Terminology in Low power And Lossy Networks’ <xref target="RFC7102"/> and 
<xref target="RFC7228"/>.</t>
<!--
<t>The term “byte” is used in its now customary sense as a synonym for
“octet”.</t>
-->
</section>
<section anchor="updating-rfc-4944" title="Updating RFC 4944">

<t>This draft adapts 6LoWPAN while maintaining backward 
compatibility with <xref target="RFC4944">IPv6 over IEEE 802.15.4</xref> by introducing a concept 
of “context” in the 6LoWPAN parser, a context being identified by a Page number.
This specification defines 16 Pages.</t>

<t>Pages are delimited in a 6LoWPAN packet by a Paging Dispatch value that indicates the next
current Page. The Page number is encoded in a Paging Dispatch with  the Value Bit Pattern
of 1111xxxx where xxxx is the Page number, 0 to 15, as described in <xref target="Pagenb"/>:</t>

<figure title="Paging Dispatch with Page Number Encoding." anchor="Pagenb"><artwork><![CDATA[
                         0               
                         0 1 2 3 4 5 6 7 
                        +-+-+-+-+-+-+-+-+
                        |1|1|1|1|Page Nb|
                        +-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>Values of the Dispatch byte defined in <xref target="RFC4944"/> are considered
as belonging to the Page 0 parsing context, which is the default and does not need to be 
signaled explicitly at the beginning of a 6LoWPAN packet. This ensures backward
compatibility with existing implementations of 6LoWPAN.</t>

<t>Note: This specification does not use the Escape Dispatch, which extends Page 0
to more values, but rather allocates another Dispatch Bit Pattern (1111xxxx) for
a new Paging Dispatch, that is present in all Pages,
including Page 0 and Pages defined in future specifications,
to indicate the next parsing context represented by its Page number.
The rationale for avoiding that approach is that there can be multiple
occurrences of a new header indexed by this specification in a single frame and
the overhead on an octet each time for the Escape Dispatch would be prohibitive.</t>

<t>A Page (say Page N) is is said to be active once the Page N Paging Dispatch
is parsed, and as long as no other Paging Dispatch is parsed.</t>

<t>The Dispatch bits defined in Page 0 by <xref target="RFC4944"/> are free to be reused in
Pages 1 to 15.</t>


</section>

<section anchor="new-disp" title="Page 1 Paging Dispatch">
<t>
This specification defines some special properties for Page 1, detailed below:
<list>
<t>The Dispatch bits defined in Page 0 for the 
<xref target="RFC6282">Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</xref>
are defined with the same values in Page 1 so there is no need to switch
context back from Page 1 to Page 0 to address LOWPAN_IPHC and LOWPAN_NHC.</t>

<t>Mesh Headers represent Layer-2 information and are processed before 
any Layer-3 information that is encoded in Page 1. 
If a 6LoWPAN packet requires a Mesh header, the Mesh Header MUST always be placed 
in the packet before the first Page 1 Paging Dispatch, if any.</t>

<t>For the same reason, Fragment Headers as defined in <xref target="RFC4944"/> MUST always be placed 
in the packet before the first Page 1 Paging Dispatch, if any.</t>

<t>The NALP Dispatch Bit Pattern as defined in <xref target="RFC4944"/>
is only defined for the first octet in the  packet. Switching back to Page 0
for NALP inside a 6LoWPAN packet does not make sense.</t>

<t>It results that there is no need so far for restoring the Page 0 parsing 
context after a context was switched to Page 1, so the value for the Page 0 Paging Dispatch of 
11110000 may not actually be seen in packets following the 6LoWPAN specifications
that are available at the time of writing.</t>
</list>
</t>
</section> 

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

<t>The security considerations of <xref target="RFC4944"/> and <xref target="RFC6282"/> apply.</t>

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

<t>This document creates a IANA registry for the 6LoWPAN Routing Header Type,
and assigns the following values:</t>

<t><list style='empty'>
  <t>0..4   : RH3-6LoRH                         [RFCthis]</t>
</list></t>

<t><list style='empty'>
  <t>5      : RPI-6LoRH                         [RFCthis]</t>
</list></t>

<t><list style='empty'>
  <t>6      : IPinIP-6LoRH                      [RFCthis]</t>
</list></t>

<!--
> 15..19 : BIER-6LoRH                        [RFCthis]
-->

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The authors wish to thank Thomas Watteyne, Tengfei Chang, Martin Turon,
James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel Montenegro and Ralph Droms
for constructive reviews to the design in the 6lo Working Group.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>


	  <?rfc include="reference.RFC.2119"?>
	  <?rfc include="reference.RFC.4944"?>
	  <?rfc include="reference.RFC.6282"?>


<reference anchor="IEEE802154" >
  <front>
    <title>IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks</title>
    <author >
      <organization>IEEE standard for Information Technology</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>


    </references>

    <references title='Informative References'>


	  <?rfc include="reference.RFC.7102"?>
	  <?rfc include="reference.RFC.7228"?>





    </references>




  </back>
</rfc>