<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-du-programmable-ip-in-iot-network-00"
     ipr="trust200902">
  <front>
    <title abbrev=" Programmable IP in IOT">Programmable IP Format in IOT
    Network</title>

    <author fullname="Zongpeng Du" initials=" Z." surname="Du">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>

          <city>Beijing</city>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>duzongpeng@foxmail.com</email>
      </address>
    </author>

    <date month="" year=""/>

    <area>Internet Area</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>IP, IOT, programmable</keyword>

    <abstract>
      <t>This document describes a programmable IP format communication
      mechanism for the IOT network .</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>There will be more and more IOT devices deployed in the future. IOT
      networks are deployed widely in the residential scenarios and in the
      smart city scenarios. However, the IOT devices belonging to different
      vendors are hard to communicate.</t>

      <t>Normally, they need to connect to the servers in the cloud, and then
      perhaps they can make some cooperation. It is to say that they can not
      communicate freely in the local network. We suggest that what we need
      here is a new layer 3 narrow waist for different IOT networks.</t>

      <t>IOT devices have many different requirements, so that we need a
      programmable IP format for a specific IOT network. For example, some IOT
      networks may need an IP format that has simplified format; meanwhile,
      some IOT networks may need an IP format that contains more security
      considerations.</t>

      <t>In this document, we introduce a mechanism to signal the selected
      format for an IOT network. Our final goal is to support a programmable
      IP format for various IOT networks.</t>

      <t/>

      <t/>
    </section>

    <section title="Proposed Mechanism Description">
      <t>In the current Internet, we have designed a uniform IP format <xref
      target="RFC4291"/>. It can benefit the communication among all the
      devices in the Internet. However, the IOT networks are quite different
      from the traditional IP network, and we need a programmable layer 3 for
      them to enable a better local communication.</t>

      <t>As we have not assumed a unified format in the layer 3, we need to
      determinate the encapsulation format of the layer 3. For example, we can
      make a bitmap to communicate between the gateway of the IOT network and
      a new IOT device that needs to communicate with the IOT network. In
      other words, they can negotiation the format of the layer 3.</t>

      <t>We suggest using some communications in the layer 2 to determinate
      the encapsulation format of the layer 3. The new IOT device may send a
      L2 frame to the gateway of the IOT network. The gateway may response
      another L2 frame that contains the information about the format in this
      IOT network.</t>

      <t>By using the information in the frame from the gateway, the new IOT
      device can connect to the IOT network and communicate with the IOT
      devices in the IOT network.</t>

      <t>The encapsulation information can be an index of some pre-configured
      format, or it can be a bitmap that describes the encapsulation format in
      the IOT network. In the later case, the bitmap may indicate whether a
      specific item is encoded in the format, for example, the SA, the TTL, or
      the next header. Each bit in the bitmap should be pre-configured and can
      be understood without ambiguity. Following the bitmap, some offsets
      should be given, so that we can determine the length of each item that
      is contained in the format. Hence, we can make a flexible platform for
      the encapsulation of the layer 3 in the IOT network, while the different
      format requirements of the IOT networks can be fulfilled.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBD.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4291"?>
    </references>
  </back>
</rfc>
