|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 13, 2008.
Copyright © The Internet Society (2007).
Internet 0 (zero) is an encoding technology for carrying IP datagrams over any link medium. In contrast to other encoding schemes, Internet 0 places primary design emphasis on simplicity and medium independence. Following in the spirit of the "IP-over-everything" paradigm, Internet 0 makes minimal assumptions about the physical properties of the underlying network. Rather than being optimized for a single physical transport, Internet 0 is suitable for carrying IP over anything. Internet 0's encoding scheme is analogous to Morse code. Packets may be transmitted over any medium as electric, optic, radio or acoustic impulses. By adopting a unified design into lower layers, Internet 0 provides significant value to the emerging class of inexpensive sensor and embedded devices expected to be active network participants. This document defines a standard for the transmission of IP datagrams over Internet 0 networks. This document also describes the Internet 0 protocol and its design principles.
A retrospective analysis of the Internet identified and enumerated several architectural enablers of the Internet's success [RFC1958] (Carpenter, B., “Architectural Principles of the Internet,” June 1996.). One notion that has stood the test of time is the Internet's ability to accommodate a variety of network technologies by making a minimum set of assumptions on the functionality of the network. Colloquially, this network heterogeneity is referred to as the "IP-over-everything" argument. While the principles of simplicity and minimal assumptions are brought to bear on the Internet Protocol (IP) and higher layers, there is significant value to applying the same design tenets to the data-link layer.
Internet 0 (zero) is an encoding technology which pushes the IP-over-everything paradigm into the link layer. Just as IP is agnostic to the data-link it runs on top of, Internet 0 aims to be a "encoding over anything." While Internet 0 is not optimal for a single particular medium, it is acceptable for virtually any media. This generality is appropriate when minimizing cost and complexity is more important than maximizing performance for a specific task.
Internet 0's design goals address the emerging class of inexpensive sensor and embedded devices expected to become active and ubiquitous network participants. These automated devices, an Internet of things [i0] (Gershenfeld, N., Krikorian, R., and D. Cohen, “The Internet of Things,” October 2004.), may outnumber the current population of traditional hosts on the network. Such devices have unique requirements which naturally differ from the servers and clients attached to the Internet today.
For example, a light bulb and light switch do not need a high-speed network in order to communicate short instructions or query state. Rather, cost and the ability to transmit over any physical medium, for instance the bulb's own power line, are paramount. Internet 0 orders its design goals in the context of link layer requirements for ubiquitous nodes. An Internet of things places cost, simplicity and interoperability as primary goals with speed a secondary concern.
This document defines a standard for the transmission of IP datagrams over Internet 0 networks. This document also details Internet 0 and describes architectural principles of the protocol.
Internet 0 defines an encoding scheme for carrying bytes over links of various media, to all destinations. It may encapsulate IP version 4 (IPv4) and IP version 6 (IPv6) packets, as well as any other byte oriented protocol. Internet 0 makes no changes to IP or the IP standard.
There exist a myriad of link layer schemes that address specific requirements including speed, transport medium, error protection and noise immunity. The fact that IP runs and interoperates over this wide variety of networks is a testament to its design. IP achieves this flexibility by not specifying any performance numbers and making only minimal assumptions on the functionality of the underlying network [clark‑philosophy] (Clark, D., “The Design Philosophy of the DARPA Internet Protocols,” .). Internet 0 similarly applies these design insights to the next lower layer.
Today's link layer technologies are not end-to-end: a packet on the Internet may travel over several local area Ethernets, an optical network with SONET and PPP framing, and a wireless connection to name a few. A great deal of effort has been spent on developing standards for IP over X where X is any of the recent IETF working groups: Cable Data Network (ipcdn), IEEE 802.16 (16ng), Resilient Packet Rings (iporpr), ATM (ipatm), FDDI (fddi), IEEE 1394 (ip1394), Bluetooth (ipobt), etc.
Internet 0 unifies encoding into a single scheme. In this sense, the encoding of the link-layer signal may be carried through the entire span of the network without decoding and re-encoding. Thus, the encoding becomes an end-point functionality and intermediate devices are greatly simplified. Figure 1 shows the difference between interconnecting networks at the software protocol layers versus Internet 0's approach of interdevice internetworking at the physical link.
Internet 0 Interconnects Networks at the Physical Link
+-----------+ +-----------+
| Network |<--->| Network |
+-----------+ +-----------+
| Data Link | | Data Link |
+-----------+ +-----------+ +-----------+ +-----------+
->| Physical | | Physical |<-->| Physical |<--->| Physical |<-
+-----------+ +-----------+ +-----------+ +-----------+
| Figure 1 |
Two important, but separable principles of Internet 0 contribute to its ability to accommodate wide media heterogeneity: big bits and clicks. We describe each in turn next.
Internet 0's encoding scheme diverges from current networking practice by using "big bits." The duration of a bit and its speed of propagation define a size. Bits have length equal to the ratio between the speed of light (actually 2c/3 in most medium) and the rate of transmission. For example, bits are approximately 30cm long for a data rate of a gigabit per second while over 10km long on an 18kbps link. If a bit is larger than a network, the transient response to it can settle independently of the topology of the network. By allowing enough time such that all echoes die, Internet 0 does not have to content with signal integrity, echoes and multi-path issues. Thus, for low data-rate devices, using bits that are large enough to settle on the local network eliminates the need for active hubs in wired networks and collision detection in wireless ones.
In the near-field limit for big bits, signals can equilibrate. In the time domain this corresponds to communicating in impulse responses. Transmission schemes such as Ultra Wideband [uwb] (Ultra Wideband Forum, “Ultra Wideband,” .) use impulse responses on multiple orthogonal frequencies, but for low-power, fading and interference rejection at high-speeds. Internet 0 is much simpler. Information is communicated solely in the timing of an event rather than its frequency, amplitude, or phase. Internet 0 encodes bits via timing so that not just the data in a packet, but also its encoding can be carried end-to-end.
Internet 0's encoding scheme is, by design, very simple. Because Internet 0 makes no assumptions about the underlying medium, for instance the frequency or amplitude response, it relies on timing events.
Internet 0 operates by pulse-position modulation: a bit-interval of length t encodes a bit. Each bit-interval is divided into two equal sized time slots. A bit is transmitted as an impulse, or "click," in the center of the appropriate slot. Every interval must have a click impulse in the first or second slot or both slots. As depicted in Figure 2, the first interval slot encodes the start sequence while the second slot encodes a 1 (one) bit. The next click interval, the third slot, encodes a 0 (zero) bit. Bytes are framed by start and stop sequences with impulses in both slots of a click interval, self-consistently providing time origin and data rate. Each bit of a byte is sent in big-endian order. This transmission order sends bits in the normal order in which they are read in English. For example, in Figure 2 the first bit sent after the start sequence is 1 and the second bit sent is 0.
Internet 0 Encoding
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | |
| | | | | | | | | | | |
+--:--|--:--|--:--|--:--|--:--|--:--|--:--|--:--|--:--|--:--> Time
start 1 0 0 1 1 1 0 0 stop
| Figure 2 |
A malformed byte in a click stream is discarded.
Two primary issues with pulse-position modulation are synchronization and multipath interference. The receiver's clock must be properly aligned with the sender in order to decode the incoming signal. The start and stop framing sequence is used in Internet 0 to recover the timing. More problematic is interference due to echos of transmitted pulses. A receiver that experiences echo interference cannot disambiguate the correct pulse positions.
However, Internet 0 avoids these potential pitfalls by bounding the data transmission rate to the size of the network. In addition, decoding can be performed over windows of clicks. More sophisticated non-local click decoding such as a decoding tree can provide noise rejection and signal separation.
Because of its simplicity and low cost Internet 0 may support IP to the leaves in networks of things. Internet 0 communicates information by encoding it into the timing of activities on its links. Internet 0 nodes encode information into the timing of outbound activities and decode the information from the timing of received activities. The media to media communication bridging is accomplished by nodes creating activities on one medium whenever they detect activities on their other medium, preserving their timing. Internet 0 makes no assumptions about the media.
Thus, Internet 0 is medium independent, in much the same way Morse code is. With Internet 0, the common language of all devices is the timing onset which gives the distinction between activity and non-activity in a click interval. Clicks can be sent as electrical impulses on a wire, smoke signals through air, knocks on a table or light impulses through an optical medium. Critical to the design is that information is always represented the same way irrespective of the underlying medium. In this way, the logical and physical layers are coincident. Internet 0 purposefully omits performance numbers so that technological assumptions do not limit current and future use.
In order to frame an entire packet for serial transmission, Internet 0 uses the current, simple de facto SLIP standard [RFC1055] (Romkey, J., “Nonstandard for transmission of IP datagrams over serial lines: SLIP,” June 1988.):
The SLIP protocol defines two special characters: END and ESC. END is octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be confused with the ASCII ESCape character. To send a packet, a SLIP host simply starts sending the data in the packet. If a data byte is the same code as END character, a two byte sequence of ESC and octal 334 (decimal 220) is sent instead. If it the same as an ESC character, an two byte sequence of ESC and octal 335 (decimal 221) is sent instead. When the last byte in the packet has been sent, an END character is then transmitted.
Internet 0 eliminates link-layer addresses. Hence, on broadcast networks, every node receives all traffic.
Figure 3 shows the relationship between the various protocols and Internet 0.
Protocol Relationships
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| IP (Internet Protocol) |
+-------------------------------+
| | |
+----------+ +----------+ +-----------+
|Internet 0| | Ethernet | | SONET/SDH |
+----------+ +----------+ +-----------+
| Figure 3 |
A 240-bit UDP/IP Internet 0 packet, comprising 160 bits for an IPv4 header, 64 bits for the UDP header, and 16 bits for the SLIP framing is shown below. This figure looks like a bar code, and in fact could be used that way, scanned optically and then the raw signals carried over any other Internet 0 transport, wired or wireless, electromagnetic, acoustic, or optical. This packet illustrates an important fundamental concept of Internet 0: the fact that the logical and physical representations of a packet are coincident.
|| | | | | | || | ||||| || | | || ||||| | | | | | | | ||||| | | | | | | | ||||| | || | | | | ||||| | | | | | | | ||||| | | | | | | | ||||| | | | | | | | ||||| | | | | | | | |||||| | | | | | | | ||||| | | || | | |||||| || | | | || |||| || | || || | |||| || || | | | |||||| | | | | | | ||||| || | | | | | |||||| | | | | | | ||||| || || | | | ||||| | || | | | | |||||| || | | | | ||||| || | | | | | ||||| | | | | | | | ||||| | | | || || ||||| | | | | | | | ||||| | | | || || ||||| | | | | | | | ||||| | | || | | | ||||| | | | | | | | ||||| | | | | | | | ||||| | | | | | || | ||
In Summary:
The Internet 0 project [i0] (Gershenfeld, N., Krikorian, R., and D. Cohen, “The Internet of Things,” October 2004.), [ieee‑i0] (Gershenfeld, N. and D. Cohen, “Internet 0: Interdevice Internetworking,” October 2006.) enjoys both academic and industrial backing. Internet 0 encoding and clicks are implemented on tiny inexpensive general purpose microprocessors. Active test installations of Internet 0 include RFID, lights and switches and industrial control. Internet 0 is successfully running on a series of commercial home office routers and mass-produced sensor devices. Test beds in other application domains are planned.
This memo does not address security issues. Authors note their use of current scalable encryption research [sea] (Standaert, F., Piret, G., Gershenfeld, N., and J. Quisquater, “SEA: A Scalable Encryption Algorithm for Small Embedded Applications,” April 2006.) as a promising part of security for the embedded devices mentioned in this draft.
| [RFC1055] | Romkey, J., “Nonstandard for transmission of IP datagrams over serial lines: SLIP,” STD 47, RFC 1055, June 1988. |
| [RFC1958] | Carpenter, B., “Architectural Principles of the Internet,” RFC 1958, June 1996. |
| [clark-philosophy] | Clark, D., “The Design Philosophy of the DARPA Internet Protocols.” |
| [i0] | Gershenfeld, N., Krikorian, R., and D. Cohen, “The Internet of Things,” Scientific American , October 2004. |
| [ieee-i0] | Gershenfeld, N. and D. Cohen, “Internet 0: Interdevice Internetworking,” IEEE Circuits and Systems , October 2006. |
| [sea] | Standaert, F., Piret, G., Gershenfeld, N., and J. Quisquater, “SEA: A Scalable Encryption Algorithm for Small Embedded Applications,” Seventh Smart Card Research and Advanced Applications , April 2006. |
| [uwb] | Ultra Wideband Forum, “Ultra Wideband,” http://www.uwbforum.org/ . |
The authors gratefully acknowledge the contributions of (alphabetically): Robert Beverly, David Dalrymple, Ralph Droms, Doug Johnson, Karen Sollins and JP Vasseur.
| Neil Gershenfeld | |
| Massachusetts Institute of Technology | |
| Room E15-411 | |
| 20 Ames Street | |
| Cambridge, MA 02139 | |
| US | |
| Phone: | +1 617 253 0392 |
| Email: | gersh@cba.mit.edu |
| Danny Cohen | |
| Sun Microsystems, Inc. | |
| Mailstop UMPK16-160 | |
| 16 Network Circle | |
| Menlo Park, CA 94025 | |
| US | |
| Phone: | +1 650 786 0006 |
| Email: | danny.cohen@sun.com |
| Todd Snide | |
| Schneider Electric | |
| 1 High Street | |
| North Andover, MA 01845 | |
| US | |
| Phone: | +1 978 975 9472 |
| Email: | todd.snide@us.schneider-electric.com |
| David Kopp | |
| Schneider Electric | |
| 1 High Street | |
| North Andover, MA 01845 | |
| US | |
| Phone: | +1 978 975 9472 |
| Email: | David.Kopp@us.schneider-electric.com |
| Kerry Lynn | |
| Cisco Systems | |
| 1414 Massachusetts Avenue | |
| Boxborough, MA 01719 | |
| US | |
| Phone: | +1 978 936 1342 |
| Email: | kelynn@cisco.com |
| David R. Oran | |
| Cisco Systems | |
| 7 Ladyslipper Lane | |
| Acton, MA 01720 | |
| US | |
| Email: | oran@cisco.com |
Copyright © The Internet Society (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).