One document matched: draft-ietf-6lo-paging-dispatch-03.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-03" 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>
    <author initials="R." surname="Cragie" fullname="Robert Cragie">
      <organization abbrev="ARM">ARM Ltd.</organization>
      <address>
        <postal>
          <street>110 Fulbourn Road</street>
          <city>Cambridge</city>
          <code>CB1 9NJ</code>
          <country>UK</country>
        </postal>
        <email>robert.cragie@gridmerge.com</email>
      </address>
    </author>

    <date/>

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

    <abstract>


<t>This specification updates RFC 4944 to introduce 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, which often is a very constrained resource.
   Other constraints, such as memory capacity and duty cycle restrictions
   on LLN devices, usually derive from that primary concern.  Energy
   is often available only from primary batteries that are expected to last
   for years, or is scavenged from the environment in very limited
   amounts.  Any protocol that is intended for use in LLNs must be
   designed with a primary focus on saving energy, which is a strict
   requirement.
   
   </t>

<t>
   Controlling the amount of data transmission is one possible means of
   saving 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 mechanism.

</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 <xref target="RFC7102">Terms Used in
   Routing for Low-Power and Lossy Networks </xref> and 
   <xref target="RFC7228">Terminology for Constrained-Node Networks </xref>.
</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 a "parsing 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>
   The Dispatch bits defined in Page 0 by <xref target="RFC4944"/> are free 
   to be reused in Pages 1 to 15. This specification allocates some values in
   Page 1 in <xref target="new-disp"/> and leaves the rest open for future
   allocations.
</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>



</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 for LOWPAN_IPHC by 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 from Page 1 to Page 0 to decode a packet that is encoded
      per <xref target="RFC6282"/>.
</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>
      As a result, 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
      occur in those packets that adhere to 6LoWPAN specifications
      available at the time of writing this specification.
</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">

<section anchor="disptype" title="Consuming Dispatch Types">
<t>
   This document allocates 16 values from the Dispatch type field registry 
   that was created for <xref target="RFC4944"/>. The allocated values are
   from 11 110000 through 11 111111 and represent Page Numbers 0 through 15 as
   discussed in this document.
</t>

</section>

<section anchor="perpagedisptype" title="New Per-Page Dispatch Type registries">
<t>
   This document creates 15 new IANA registries for the Per-Page Dispatch type
   fields, indexed by Page Number, 1 to 15. Each Registry corresponds to a
   bit-field of one octet. 
</t>

<t>
   Future assignments in these registries are to be coordinated via IANA
   under the policy of "Specification Required" <xref target="RFC5226"/>.
   It is expected that this policy will allow for other (non-IETF)
   organizations to more easily obtain assignments.
</t>

<t>
   These registries extend the Dispatch type field registry that was created for
   <xref target="RFC4944"/>, which is considered as the registry for Page 0.
</t>

<t>
   As described above, this document allocates in the registry associated to
   Page 1 the Per-Page Dispatch type field values that are allocated 
   in the Dispatch type field for LOWPAN_IPHC by <xref target="RFC6282"/>.
   Those values are from 01 100000 through 01 111111 and they have the same
   definition in Page 1 as they do in Page 0, meaning that the registries for
   Page 0 and Page 1 are an exact overlap in this range.
</t>

</section>


</section>

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

<t>The authors wish to thank Tom Phinney, 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.5226"?>
	  <?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/>
  </front>
</reference>


    </references>

    <references title='Informative References'>


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





    </references>




  </back>
</rfc>