目錄[隱藏] |
最近，對運行在低功耗嵌入式設(shè)備上的，基于互聯(lián)網(wǎng)協(xié)議的網(wǎng)絡(luò)的興趣又重新火熱了起來。這些興趣來源于以下幾個方面：一，IETF正在制定新的標準，使得在受限設(shè)備上能有效率地，與傳統(tǒng)網(wǎng)絡(luò)兼容地運行IP協(xié)議；二，已經(jīng)有一些開源或者閉源的嵌入式IP協(xié)議棧，證明在受限設(shè)備上運行IP協(xié)議棧是可行的；三，最近的一些學(xué)術(shù)文章表明了這樣一種情況，即這種體系結(jié)構(gòu)具有重要的研究意義，并在更多的細節(jié)上描述了協(xié)議棧的結(jié)構(gòu)。
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機制映射到收集路由本地聚集這些已經(jīng)研究得很好的傳感網(wǎng)絡(luò)的問題上。接下來我們討論目前標準的狀態(tài)，最后我們提出一種將IP協(xié)議移植進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.
現(xiàn)行的IP協(xié)議有2個版本：IPv4和IPv6。之前的研究表明IPv6更適合應(yīng)用到低功耗嵌入式網(wǎng)絡(luò)中：大多數(shù)標準化的努力都集中在將IPv6應(yīng)用到這些設(shè)備上去，因此我們只考慮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.
在傳感網(wǎng)絡(luò)上實現(xiàn)IPv6的中心問題是IETF的“route over”還是“mesh under”問題。在mesh under網(wǎng)絡(luò)中，路由是基于協(xié)議棧的第二層尋路來完成的（IEEE802.15.4或者適配層頭部）。每個主機距其他主機一跳。雖然這樣做與大部分已有的子網(wǎng)設(shè)計兼容，但其帶來了明顯的冗余和效率低下的問題。另一種方法，是在運行在無線射頻之上的IP層負責尋路，叫做routing-over。雖然與標準的IPv6機制不完全兼容，但這樣做更受歡迎，因為有一系列的工具能用來調(diào)試bug。本TEP接下來的篇章都假設(shè)路由采用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的路由協(xié)議，一些是專門用于無線鏈路的。IPv6本身并沒有要求任何路由協(xié)議與特定的鏈路掛鉤：一般在有線網(wǎng)絡(luò)中使用OSPF和IS-IS。最近IETF的研究表明，這些已有的協(xié)議并不適合在低功耗嵌入式網(wǎng)絡(luò)上運行[raft-ietf-roll-protocols-02]，因此在這點上需要更多的工作。TinyOS上已有的一些協(xié)議，譬如DYMO或者S4可能適合這項任務(wù)，而匯聚和分發(fā)協(xié)議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定義了單播，任播，多播地址范圍，每一個范圍都有他們自己的特性。要想知道關(guān)于IPv6地址的所有解釋，請閱讀相關(guān)書籍和RFC，我們只簡要地描述一些重要細節(jié)。
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個部分：網(wǎng)絡(luò)標識符(前64位)和接口標識符(后64位)。本地標識符是一個平坦空間，可能是從接口的MAC地址，隨機數(shù)，或者其他機制衍生過來的。Ipv6有一些保證接口ID與子網(wǎng)其他接口ID不同的機制。網(wǎng)絡(luò)有可能會被指定使用很多不同的機制，但某些網(wǎng)絡(luò)標識符是特殊的。
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地址。此地址的網(wǎng)絡(luò)標識符為fe80::，用它來和主機所在的子網(wǎng)通信。
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協(xié)議棧中，link-local地址被用來與其他TinyOS節(jié)點通信。比如用于本地聚合。如果TinyOS主機能將IEEE802.15.4 16位短ID或64位EUID派生出來的地址分配給節(jié)點作為link-local地址，例如，將fe80::10分配給值為10的16位短ID的接口的節(jié)點。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也能使主機獲得一個可尋路的網(wǎng)絡(luò)標識符。TinyOS主機能與擁有這些地址的其他傳感網(wǎng)絡(luò)或者互聯(lián)網(wǎng)主機通信。多重連接使得主機能同時擁有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開頭的地址都是多播地址。接下來的一個字節(jié)，其中頭4位標志4類多播范圍，例如：第一類是node-local，第二類是link-local。IPv6定義了一些知名的多播組[2]。這些多播組中知名度最高的是地址ff02::1，代表link-local所有節(jié)點，還有地址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?！皊ite local”是IPv6中定義的管理性概念，這里可能指整個傳感網(wǎng)絡(luò)。因此，向這個地址發(fā)送數(shù)據(jù)就是向這個網(wǎng)絡(luò)中的所有路由節(jié)點發(fā)送該數(shù)據(jù)，能用涓流算法來實現(xiàn)該行為。
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社區(qū)會開發(fā)額外的協(xié)議，以提供范圍內(nèi)的洪泛或者向特殊節(jié)點交付數(shù)據(jù)等額外的功能。在傳感網(wǎng)絡(luò)中得到實現(xiàn)完全的IP多播，能應(yīng)用在譬如控制應(yīng)用程序，管理注冊了多播組的子網(wǎng)等場景上。
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.
任播地址表明報文應(yīng)該被交付到最少一個擁有任播地址的節(jié)點上。這看起來很像MultiHopLQI和CTP等將匯聚報告發(fā)送到一個根節(jié)點的匯聚協(xié)議模型。但是，這個基于IP體系的匯聚根更有可能不是數(shù)據(jù)的最終目的地，他們很可能是數(shù)據(jù)發(fā)往最終目的地時的臨近路由器。因此，或許有應(yīng)用程序使用任播尋址，但我們不認為這個尋址模型適合大部分應(yīng)用。
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個方法使得互聯(lián)網(wǎng)主機能與一個全局網(wǎng)絡(luò)標識符相關(guān)聯(lián)：零配置和DHCPv6。零配置定義了路由請求和路由廣播。加入到一個網(wǎng)絡(luò)中的路由主機將其link-local地址作為源地址，發(fā)送路由請求到link-local全路由地址ff02::2。路由器回顯一個路由廣播報文，這個報文包含了主機能使用的全局網(wǎng)絡(luò)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協(xié)議棧的實現(xiàn)中，同鄰居發(fā)現(xiàn)協(xié)議一樣，路由請求和路由廣播可能被用來在主機上選擇默認路由。
In a TinyOS IP implementation, router solicitations and advertisements mightbe used for default route selection on the hosts, as well as neighbordiscovery.
TinyOS的一個特色就是通過實現(xiàn)一系列組件來提供棧式頭部，所有這些組件都實現(xiàn)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.
這些擴展頭部用來支持協(xié)議選項，或者捎帶信息。例如一個鏈路估算組件能在要發(fā)送的包中添加“鏈路選項頭部”，這樣能避免單獨發(fā)送這些數(shù)據(jù)，給鏈路帶來過載的情況。這種頭部體系結(jié)構(gòu)比已有的TinyOS包體系結(jié)構(gòu)更加靈活，當然代價是帶來了一些復(fù)雜性。
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中，然而大多數(shù)運行TinyOS的節(jié)點都是受限設(shè)備，因此接下來的工作主要集中在如何能使這些機制符合受限設(shè)備的特點。
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字節(jié)(定長320位)。其中32字節(jié)是源、目的地址。IETF已經(jīng)發(fā)表了RFC4944，其中描述了一個報頭壓縮技術(shù)：HC1。然而，這個方法有一個明顯的問題，不能利用16位短標識符的優(yōu)勢。隨后有一些draft提案改進了該技術(shù)，例如：HC1g，HC。這些draft中最新的版本是draft-hui-6lowpan-hc-02，有現(xiàn)象表明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個字節(jié)。很明顯這比IEEE802.15.4鏈路層MTU127字節(jié)大了許多。RFC4944定義了一個2.5層協(xié)議(適配層)，允許超過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無狀態(tài)零配置的最初定義存在一些問題，特別是當一個“routing over”網(wǎng)絡(luò)建立起來時，例如重復(fù)地址檢測很可能要求網(wǎng)絡(luò)作出某些改變。6lowpan工作組中的某個子委員會目前正研究這些問題，可能提出一些適配機制，但現(xiàn)在還沒有一個穩(wěn)定的狀態(tài)。
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.
現(xiàn)在還不可能開發(fā)一個與協(xié)議兼容的路由層次[譯者注：RPL協(xié)議已經(jīng)在TinyOS中得到實現(xiàn)，此文檔有點過時了]，相關(guān)的標準還沒有提出來?，F(xiàn)在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.
正如前面幾節(jié)所說的那樣，很多有明確目的的傳感網(wǎng)絡(luò)抽象能很好地映射到IPv6機制上去。然而并沒有可用的標準精確地定義了如何來完成這些事情。因此，我們的態(tài)度是，TinyOS應(yīng)該盡可能快地將現(xiàn)有的技術(shù)融合到IPv6協(xié)議棧中去，同時考慮保持標準的自由度，這樣做能夠提高性能和簡化實現(xiàn)。鑒于標準處于隨時變動的狀態(tài)，能體現(xiàn)挑戰(zhàn)和可行機制的開放實現(xiàn)，它很可能具有重大的意義。
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.
走在最前頭的很可能是關(guān)于路由的標準：有路由的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的傳感網(wǎng)絡(luò)使用IPv6，和如何將它們與之前的工作相結(jié)合的方法。它沒有指明任何實現(xiàn)上的問題，這些問題有可能在之后的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
聯(lián)系客服
