目录[隐藏] |
最近，对运行在低功耗嵌入式设备上的，基于互联网协议的网络的兴趣又重新火热了起来。这些兴趣来源于以下几个方面：一，IETF正在制定新的标准，使得在受限设备上能有效率地，与传统网络兼容地运行IP协议；二，已经有一些开源或者闭源的嵌入式IP协议栈，证明在受限设备上运行IP协议栈是可行的；三，最近的一些学术文章表明了这样一种情况，即这种体系结构具有重要的研究意义，并在更多的细节上描述了协议栈的结构。
Recently, there has been renewed interest in the applicability of InternetProtocol-based networking for low power, embedded devices. This interest isbeing driven by several sources. One, emerging standards from the IETF arebeginning to make it possible to design efficient, compatibleimplementations of IP for this class of resource-constrained device. Two,there has been an emergence of a significant number of both open and closed IPembedded IP stacks which demonstrate the applicability of this model ofnetworking. Third, a set of recent academic papers have made the case thatthis network architecture is a significant research enabler and shown in moredetail the structure of a full stack.
在此TEP中，我们简单地解释一下如何将IP机制映射到收集路由本地聚集这些已经研究得很好的传感网络的问题上。接下来我们讨论目前标准的状态，最后我们提出一种将IP协议移植进TinyOS的方法。
In this TEP, we briefly explain how IP mechanisms map onto the well-studiedproblems of the sensor network community like collection routing and localaggregation. Next, we discuss the current "state of the standards." Finally,we propose a path for the adoption of IP within TinyOS.
现行的IP协议有2个版本：IPv4和IPv6。之前的研究表明IPv6更适合应用到低功耗嵌入式网络中：大多数标准化的努力都集中在将IPv6应用到这些设备上去，因此我们只考虑IPv6。
There are two versions of IP: IPv4 (RFCXXX) and IPv6 (RFCXXX). Previousstudies have indicated that IPv6 is more applicable to the low-power, embeddedspace then IPv4 for various reasons; most standardization efforts have focusedon adapting IPv6 to these devices. Therefore, we consider only IPv6.
在传感网络上实现IPv6的中心问题是IETF的“route over”还是“mesh under”问题。在mesh under网络中，路由是基于协议栈的第二层寻路来完成的（IEEE802.15.4或者适配层头部）。每个主机距其他主机一跳。虽然这样做与大部分已有的子网设计兼容，但其带来了明显的冗余和效率低下的问题。另一种方法，是在运行在无线射频之上的IP层负责寻路，叫做routing-over。虽然与标准的IPv6机制不完全兼容，但这样做更受欢迎，因为有一系列的工具能用来调试bug。本TEP接下来的篇章都假设路由采用route over模型。
A central question for implementing IPv6 in sensor networks is what has becomeknow as "route over" vs. "mesh under" in the IETF. In mesh under networking,routing is done on layer two addresses, and every host is one hop from everyother. Although this is the most compatible with existing assumptions aboutsubnet design, it leads to significant redundancies and inefficiencies in thisspace. The alternative, so called route-over exposes the radio topology atthe IP layer. While not strictly compatible with some IPv6 mechanisms, thisis becomming the favored approach since a single set of tools can be used todebug. For the rest of this TEP we assume that route over is the model.
已有很多IPv6的路由协议，一些是专门用于无线链路的。IPv6本身并没有要求任何路由协议与特定的链路挂钩：一般在有线网络中使用OSPF和IS-IS。最近IETF的研究表明，这些已有的协议并不适合在低功耗嵌入式网络上运行[raft-ietf-roll-protocols-02]，因此在这点上需要更多的工作。TinyOS上已有的一些协议，譬如DYMO或者S4可能适合这项任务，而汇聚和分发协议CTP、Drip可能不适合，因为它们是无地址的，although the insight gainedfrom their implementations may be transferable.
There are a number of existing routing protocols for IPv6, some targeted atwireless links. However, IPv6 itself does not require any particular routingprotocol to be used with a domain; common choices in wired networks are OSPFand IS-IS. Recent study in the IETF has indicated that existing protocols areprobably not appropriate for this space [draft-ietf-roll-protocols-02], and sofurther work is needed on this point. Existing protocols with TinyOSimplementations such as DYMO or S4 may be appropriate for this task;collection and dissemination protocols like CTP or Drip are probably notdirectly applicable since they are address-free, although the insight gainedfrom their implementations may be transferable.
IPv6最显著地特性是它的地址长度。一个IPv6地址是128位长的。Ipv6定义了单播，任播，多播地址范围，每一个范围都有他们自己的特性。要想知道关于IPv6地址的所有解释，请阅读相关书籍和RFC，我们只简要地描述一些重要细节。
The most well-known property of IPv6 is probably it's address length. An IPv6address is 128 bits long. Within this space, IPv6 defines unicast, anycast,and multicast address ranges; each of these ranges further have properties oftheir own. For a full explaination of IPv6 addressing we refer the reader to,for example, [OReilly, RFC], we cover briefly some of the important details.
IPv6单播地址有2个部分：网络标识符(前64位)和接口标识符(后64位)。本地标识符是一个平坦空间，可能是从接口的MAC地址，随机数，或者其他机制衍生过来的。Ipv6有一些保证接口ID与子网其他接口ID不同的机制。网络有可能会被指定使用很多不同的机制，但某些网络标识符是特殊的。
Unicast addresses in IPv6 consist of two parts: the network identifier (thefirst 64 bits), and the interface identifier (the second). The interfaceidentifier is a flat space, and may be derived from the interface's MACaddress, a random number, or other mechanism. IPv6 contains mechanisms toensure that the interface ID is unique within the subnet. The networkmay be assigned using many different mechanisms, but some network identifiersare special.
不同于IPv4，每个IPv6的接口都是多重连接的，它可以有多个IPv6地址。但接口启动后，IPv6会为接口配置一个唯一的，不可寻路的地址，称之为link-local地址。此地址的网络标识符为fe80::，用它来和主机所在的子网通信。
Unlike IPv4, each interface in IPv6 is multihomed: it is expected to havemultiple IPv6 addresses. When an interface is brought up, IPv6 containsmechanisms to configure the interface with a locally unique, non-routableaddress known as the link-local address. This address has the networkidentifier fe80::, and can be used for communication between hosts in the samesubnet.
在TinyOS IPv6协议栈中，link-local地址被用来与其他TinyOS节点通信。比如用于本地聚合。如果TinyOS主机能将IEEE802.15.4 16位短ID或64位EUID派生出来的地址分配给节点作为link-local地址，例如，将fe80::10分配给值为10的16位短ID的接口的节点。These addresses would not be routed; an IP stack wouldsend directly to the short id 0x10 contained in the address.
In a TinyOS IPv6 stack, this address range might be used to allow TinyOS nodesto communicate locally without routing, for instance to enable localaggregation. If the TinyOS hosts can assign themselves link-local addressesderived from their IEEE802.15.4 16-bit short id, or full 64-bit EUID. Forinstance, a node with short ID 16 might assign the address fe80::10 to its802.15.4 interface. These addresses would not be routed; an IP stack wouldsend directly to the short id 0x10 contained in the address.
IPv6也能使主机获得一个可寻路的网络标识符。TinyOS主机能与拥有这些地址的其他传感网络或者互联网主机通信。多重连接使得主机能同时拥有public和link-local地址。
IPv6 also contains several mechanisms to allow a host to obtain apublicly-routable network identifier. TinyOS hosts communicating with theseaddresses could contact nodes in other sensor networks or on the internet; thefact that they are multihomed allows them to use both public and link-localaddresses simultaneously.
IPv6有一个多播地址范围。以0xff开头的地址都是多播地址。接下来的一个字节，其中头4位标志4类多播范围，例如：第一类是node-local，第二类是link-local。IPv6定义了一些知名的多播组[2]。这些多播组中知名度最高的是地址ff02::1，代表link-local所有节点，还有地址ff02::2，代表link-local所有路由。取决于TinyOS主机是不是IP路由器，这些link-local地址能被映射到第二层的广播地址(0xffff)，作为有效地link-local广播地址。这样IPv6也拥有了本地广播能力。
IPv6 contains a multicast address range; addresses beginning with the bytecontaining all ones (0xff) are multicast addresses. Following this byte arefour bits of flags and four bits of "scope". For instance, scope 1 isnode-local, and scope 2 is link local. IPv6 defines many well-known multicastgroups [3]; of most interest here are the "link-local all nodes" and "linklocal all-routers" addresses: ff02::1 and ff02::2, respectively. Depending onweather TinyOS IP hosts are also IP routers, these addresses are effecitvelylink-local broadcast addresses which might be mapped into the layer 2broadcast address (0xffff). Thus IPv6 contains mechanisms for localbroadcast.
在IPv6中定义了一个site-local级别的路由地址ff05::2。“site local”是IPv6中定义的管理性概念，这里可能指整个传感网络。因此，向这个地址发送数据就是向这个网络中的所有路由节点发送该数据，能用涓流算法来实现该行为。
There is also a site-local scope defined in IPv6 (5) with a similar ff05::2address. "Site local" is an administratively defined scope in IPv6, and mightnaturally consist of an entire sensor network. Thus, sending to this addresswould correspond to disseminating a value to each node in the network andcould be implemented with a trickle-based algorithm.
TinyOS社区会开发额外的协议，以提供范围内的洪泛或者向特殊节点交付数据等额外的功能。在传感网络中得到实现完全的IP多播，能应用在譬如控制应用程序，管理注册了多播组的子网等场景上。
Futhermore, the TinyOS community could develop additional conventions toprovide and address for scoped flooding or delivery to nodes with particularcapabilities. A full IP multicast implementation within the sensor networkcould be used for many things including control applications orpublish-subscribe network layers which have previously been special purpose.
任播地址表明报文应该被交付到最少一个拥有任播地址的节点上。这看起来很像MultiHopLQI和CTP等将汇聚报告发送到一个根节点的汇聚协议模型。但是，这个基于IP体系的汇聚根更有可能不是数据的最终目的地，他们很可能是数据发往最终目的地时的临近路由器。因此，或许有应用程序使用任播寻址，但我们不认为这个寻址模型适合大部分应用。
Anycast addresses indicate that the packet should be delivered to at least onehost with the anycast address. This seems initially similar to the model forcollection routing such as MultiHopLQI or CTP, in that a collection report isdelivered to a single root. However, it is more likeley that those"collection roots" in an IP-based infrastructure are not actually the finaldestination for the data; they are likely to only be intermediate routers whosend the data on to a final destination. Therefore, while there may beapplications for anycast addressing, we do not believe this addressing mode tobe appropriate in the common case.
就像之前提到的，IPv6有2个方法使得互联网主机能与一个全局网络标识符相关联：零配置和DHCPv6。零配置定义了路由请求和路由广播。加入到一个网络中的路由主机将其link-local地址作为源地址，发送路由请求到link-local全路由地址ff02::2。路由器回显一个路由广播报文，这个报文包含了主机能使用的全局网络ID信息。
As alluded to earlier, IPv6 contains two mechanisms to allow internet hosts tobecome associated with a public network identifier. These methods arestateless autoconfiguration and DHCPv6. Stateless autoconfiguration definesRouter Solicitations and Router Advertisements. A host joining a networksends router solicitations to the link-local all-routers address (ff02::2)using his link-local address as the source address. Routers respond with aRouter Advertisement containing, among other things, a public networkidentifier which the host may use.
在TinyOS IP协议栈的实现中，同邻居发现协议一样，路由请求和路由广播可能被用来在主机上选择默认路由。
In a TinyOS IP implementation, router solicitations and advertisements mightbe used for default route selection on the hosts, as well as neighbordiscovery.
TinyOS的一个特色就是通过实现一系列组件来提供栈式头部，所有这些组件都实现Packet接口。IPv6以一种更可扩展地方式提供栈式头部。这些头部分为2类：逐跳扩展头部和目的扩展头部。这些头部一个紧接另一个，由一些16位字段组成，这些字段标示下一个头部的类型，选项头部长度。这使得主机在不知道所有扩展头部的含义的时候，也能串行处理这些头部链。
A common idiom in TinyOS is to provide "stacked" headers by implementing aseries of components, all of which implement the Packet interface. IPv6supports this a more flexible way with options headers. These headers fallinto one of two categories: hop-by-hop options headers and destination optionheaders. These headers are chained together with small, two-octet commonheader fields which identifiy the header type of the next header, and thelength of that options header. This allows hosts to process a header chaineven if they do not know how to interpret all of the options headers.
这些扩展头部用来支持协议选项，或者捎带信息。例如一个链路估算组件能在要发送的包中添加“链路选项头部”，这样能避免单独发送这些数据，给链路带来过载的情况。这种头部体系结构比已有的TinyOS包体系结构更加灵活，当然代价是带来了一些复杂性。
These headers are commonly used for protocol options, or to piggyback data onoutgoing packets. For instance, a link estimator component could add an extra"link options" header to occasional outgoing packets as an options header,while avoiding the overhead when it is not necessary to do so. This headerarchitecture is significantly more flexible then the existing TinyOS packetarchitecture, although it does come at the slight cost of complexity.
之前所有的机制都定义在各种各样的RFC中，然而大多数运行TinyOS的节点都是受限设备，因此接下来的工作主要集中在如何能使这些机制符合受限设备的特点。
All of the previously defined mechanisms are well defined for IPv6 in variousRFCs. However, most nodes running TinyOS are significantly moreresource-constrained then typical IPv6 hosts. Thus, there is ongoing work onadapting these mechanisms to the characteristics of embedded devices.
第一个问题是IPv6头部全长40字节(定长320位)。其中32字节是源、目的地址。IETF已经发表了RFC4944，其中描述了一个报头压缩技术：HC1。然而，这个方法有一个明显的问题，不能利用16位短标识符的优势。随后有一些draft提案改进了该技术，例如：HC1g，HC。这些draft中最新的版本是draft-hui-6lowpan-hc-02，有现象表明6lowpan工作组将从RFC4944中丢弃HC1算法。
The first issue which must be addressed is the sheer size of the IPv6 header:40 octets. Of this, 32 octets are the source and destination addresses of thepacket. The IETF has published RFC4944 which describes a header compressiontechnique known as HC1. However, this scheme has significant problems, mostimportantly the inability to take advantage of 16-bit short identifiers whenavailable. There have been a sequence of internet drafts proposing improvedtechinques such as HC1g, and HC. The most recent version of these drafts isdraft-hui-6lowpan-hc-02, and there are strong indications that the workinggroup will depreciate HC1 from RFC4944 in the future.
IPv6要求MTU的最小值在1280个字节。很明显这比IEEE802.15.4链路层MTU127字节大了许多。RFC4944定义了一个2.5层协议(适配层)，允许超过1280MTU大小的包能在此小MTU链路上传输。虽然这样做已有些问题显露出来，但它看起来很可能是不可替代的。
IPv6 requires a minimum link MTU of 1280 octets in RFCXXX. Clearly, this ismuch larger then the IEEE802.15.4 link MTU of 127 octets. RFC4944 defines "layer 2.5" fragmentation which allow packets up to this MTU to be transferedover small MTU links. While there are some issues have been raised with thisscheme, it seems likely to remain relatively unaltered.
IPv6无状态零配置的最初定义存在一些问题，特别是当一个“routing over”网络建立起来时，例如重复地址检测很可能要求网络作出某些改变。6lowpan工作组中的某个子委员会目前正研究这些问题，可能提出一些适配机制，但现在还没有一个稳定的状态。
IPv6 stateless autoconfiguration as originally defined has some problems,expecially once a "route over" network topology is established; for instance,Duplicate Address Detection is likely to require some changes. A subcomitteeof the 6lowpan working group is currently investigating these issues is islikely to propose adaptation mechanisms but they are currently in flux.
现在还不可能开发一个与协议兼容的路由层次[译者注：RPL协议已经在TinyOS中得到实现，此文档有点过时了]，相关的标准还没有提出来。现在Roll工作组正为此奋斗。
It is currently not possible to develop a standards-compliant routing layer,as the relevant standards do not exist. Work in this direction is occuring inthe Roll working group, but a full specification is likely some way off.
正如前面几节所说的那样，很多有明确目的的传感网络抽象能很好地映射到IPv6机制上去。然而并没有可用的标准精确地定义了如何来完成这些事情。因此，我们的态度是，TinyOS应该尽可能快地将现有的技术融合到IPv6协议栈中去，同时考虑保持标准的自由度，这样做能够提高性能和简化实现。鉴于标准处于随时变动的状态，能体现挑战和可行机制的开放实现，它很可能具有重大的意义。
As the previous sections have shown, many sensor network abstractions map wellinto IPv6 mechanisms, with a significant gain in clarity of abstraction.However, standards are currently unavailable to specifiy exactly how thisshould be accomplished. Therefor, our position is that TinyOS should movequickly to incorporate existing techinques and standards into an IPv6 stackwhere possible, while taking liberties with the standards when doing soimproves performance or simplifies implementation. Given that the standardsthemselves are in a state of flux, having an open implementation whichdemonstrates challenges and feasible mechaninisms is likely to be ofsignificant value.
走在最前头的很可能是关于路由的标准：有路由的IPv6比没有路由的IPv6有用的多。(后面的不太懂....)
The most important places where it may be necessary to move ahead of thestandards are the routing; an IPv6 stack with no routing will not be as usefulas one with it. One open question is weather we choose a routing algorithmwhich functions in a completly decentralized fashion like AODV, OLSR, DYMO,S4, or many existing protocols or choose one which imposes more hierarchy ondeployments. We do note that existing standards like Zigbee and WirelessHARTboth contain multi-tier architectures with devices of differing capabilities.This has also been a common deployment model in many applications, but itlimits the utility to places where this is possible. The correct long-termanswer is probably to support both types of routing.
本文档向读者介绍了在基于TinyOS的传感网络使用IPv6，和如何将它们与之前的工作相结合的方法。它没有指明任何实现上的问题，这些问题有可能在之后的TEP中描述。
This document is meant to introduce readers to the ways in which IPv6mechanisms can be used in a TinyOS-based sensor network deployment, and howthey relate to previous work. It does not address any implementation issues,which will be presented in a later TEP.
Stephen Dawson-HaggertyComputer Science DivisionUniversity of California, Berkeley410 Soda HallBerkeley, CA 94701stevedh@eecs.berkeley.edu
Matus HarvanInformation SecurityIFW C 48.1ETH ZentrumHaldeneggsteig 48092 ZurichSwitzerlandphone - +41 44 63 26876email - mharvan@inf.ethz.ch
Omprakash GnawaliRonald Tutor Hall (RTH) 418 3710 S. McClintock AvenueLos Angeles, CA 90089 phone - +1 213 821-5627email - gnawali@usc.edu
联系客服
