Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 6574 J. Arkko
Category: Informational April 2012
ISSN: 2070-1721
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 6574 J. Arkko
Category: Informational April 2012
ISSN: 2070-1721
Report from the Smart Object Workshop
来自智能对象研讨会的报告
Abstract
摘要
This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.
本文件概述了互联网体系结构委员会（IAB）举办的“智能对象与互联网互联”研讨会。研讨会于2011年3月25日在布拉格举行。研讨会的主要目标是征求更广泛社区对其在受限环境中部署IETF协议的经验的反馈。本报告总结了讨论情况，并向互联网工程任务组（IETF）社区列出了结论和建议。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
请注意，本文件是研讨会会议记录的报告。本报告中记录的观点和立场是研讨会参与者的观点和立场，不一定反映IAB的观点和立场。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6574.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6574.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 5
3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 6
3.1.2. Domain-Specific Stacks and Profiles . . . . . . . . . 8
3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 9
3.2. Sleeping Nodes . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 25
Appendix B. Workshop Materials . . . . . . . . . . . . . . . . . 25
Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 25
Appendix D. Workshop Participants . . . . . . . . . . . . . . . . 30
Appendix E. IAB Members at the Time of Approval . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 5
3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 6
3.1.2. Domain-Specific Stacks and Profiles . . . . . . . . . 8
3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 9
3.2. Sleeping Nodes . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 25
Appendix B. Workshop Materials . . . . . . . . . . . . . . . . . 25
Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 25
Appendix D. Workshop Participants . . . . . . . . . . . . . . . . 30
Appendix E. IAB Members at the Time of Approval . . . . . . . . . 32
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.
互联网架构委员会（IAB）举办临时研讨会，旨在考虑互联网的长期问题和策略，并提出未来的互联网架构方向。IAB的这一长期规划职能是对互联网工程任务组（IETF）工作组在互联网工程指导小组（IESG）和地区理事会领导下进行的工程工作的补充。
Today's Internet is experienced by users as a set of applications, such as email, instant messaging, and services on the Web. While these applications do not require users to be present at the time of service execution, in many cases they are. There are also substantial differences in performance among the various end devices, but in general end devices participating in the Internet are considered to have high performance.
今天的互联网是用户体验的一组应用程序，如电子邮件、即时消息和Web服务。虽然这些应用程序不要求用户在执行服务时在场，但在许多情况下，用户是在场的。各种终端设备之间的性能也有很大差异，但一般来说，参与互联网的终端设备被认为具有高性能。
There are, however, a large number of deployed embedded devices, and there is substantial value in interconnecting them with the Internet. The term "Internet of Things" denotes a trend where a large number of devices employ communication services offered by the Internet protocols. Many of these devices are not directly operated by humans, but exist as components in buildings or vehicles, or are spread out in the environment. There is a large variation in the computing power, available memory, (electrical) power, and communications bandwidth between different types of devices.
然而，有大量已部署的嵌入式设备，将它们与Internet互连具有巨大的价值。术语“物联网”表示大量设备使用互联网协议提供的通信服务的趋势。这些设备中有许多不是由人类直接操作的，而是作为建筑或车辆的部件存在的，或者分布在环境中。在不同类型的设备之间，计算能力、可用内存、（电）功率和通信带宽存在很大差异。
Many of these devices offer a range of new possibilities or provide additional value for previously unconnected devices. Some devices have been connected using proprietary communication networks in the past but are now migrating to the use of the Internet Protocol suite in order to share the same communication network between all applications and to enable rich communications services.
其中许多设备提供了一系列新的可能性，或为以前未连接的设备提供了附加价值。一些设备过去使用专有通信网络连接，但现在正在迁移到使用Internet协议套件，以便在所有应用程序之间共享相同的通信网络，并实现丰富的通信服务。
Much of this development can simply run on existing Internet protocols. For instance, home entertainment and monitoring systems often offer a Web interface to the end user. In many cases the new, constrained environments can benefit from additional protocols and protocol extensions that help optimize the communications and lower the computational requirements. Examples of currently ongoing standardization efforts targeted for these environments include the Constrained RESTful Environments (CoRE), IPv6 over Low power WPAN (6LoWPAN), Routing Over Low power and Lossy networks (ROLL), and the Light-Weight Implementation Guidance (LWIG) working groups of the IETF.
这种开发的大部分可以简单地在现有的互联网协议上运行。例如，家庭娱乐和监控系统通常为最终用户提供Web界面。在许多情况下，新的受限环境可以受益于附加协议和协议扩展，这些协议和协议扩展有助于优化通信并降低计算要求。目前针对这些环境正在进行的标准化工作包括受限RESTful环境（CoRE）、低功耗WPAN上的IPv6（6LoWPAN）、低功耗和有损网络上的路由（ROLL）以及IETF的轻量级实施指南（LWIG）工作组。
This workshop explored the experiences of researchers and developers when considering the characteristics of constrained devices. Engineers know that many design considerations need to be taken into account when developing protocols and architecture. Balancing between the conflicting goals of code size, economic incentives, power consumption, usability, and security is often difficult, as illustrated by Clark et al. in "Tussle in Cyberspace: Defining Tomorrow's Internet" [Tussle].
本研讨会探讨了研究人员和开发人员在考虑受约束设备的特性时的经验。工程师们知道，在开发协议和体系结构时，需要考虑许多设计因素。在代码大小、经济激励、功耗、可用性和安全性等相互冲突的目标之间取得平衡通常是困难的，正如Clark等人在《网络空间的争斗：定义未来的互联网》中所述[Tussle]。
Participants at the workshop discussed the experience and approaches taken when designing protocols and architectures for interconnecting smart objects to the Internet. The scope of the investigations included constrained nodes as well as constrained networks.
研讨会的参与者讨论了在设计智能对象与互联网互连的协议和体系结构时所采用的经验和方法。研究范围包括约束节点和约束网络。
The call for position papers suggested investigating the area of integration with the Internet in the following categories:
《征求意见书》建议从以下几类调查与互联网的整合领域：
o Scalability
o 可伸缩性
o Power efficiency
o 功率效率
o Interworking between different technologies and network domains
o 不同技术和网络域之间的互通
o Usability and manageability
o 可用性和可管理性
o Security and privacy
o 安全和隐私
The goals of the workshop can be summarized as follows:
讲习班的目标可概括如下：
As many deployed smart objects demonstrate, running protocols like the Internet Protocol Version 4 [RFC0791] and Version 6 [RFC2460], the User Datagram Protocol (UDP) [RFC0768], the Transmission Control Protocol (TCP) [RFC0793], the Hypertext Transfer Protocol (HTTP) [RFC2616], etc., on constrained devices is clearly possible. Still, protocol designers, system architects, and developers have to keep various limitations in mind. The organizers were interested to discuss the experience with deploying IETF protocols in different constrained environments.
正如许多部署的智能对象所展示的，在受约束的设备上运行互联网协议版本4[RFC0791]和版本6[RFC2460]、用户数据报协议（UDP）[RFC0768]、传输控制协议（TCP）[RFC0793]、超文本传输协议（HTTP）[RFC2616]等协议显然是可能的。不过，协议设计者、系统架构师和开发人员必须牢记各种限制。组织者有兴趣讨论在不同受限环境中部署IETF协议的经验。
Furthermore, the organizers were seeking to identify issues either where current implementers do not yet have solutions or where researchers predict potential issues.
此外，组织者试图确定当前实施者尚未找到解决方案或研究人员预测潜在问题的问题。
The workshop served as a venue to identify problems and to discover common interests that may turn into new work or into changes in direction of already ongoing work at the IETF and or the Internet Research Task Force (IRTF).
该研讨会是一个确定问题和发现共同兴趣的场所，这些兴趣可能会转变为新的工作或转变为IETF和/或互联网研究工作队（IRTF）正在进行的工作方向。
The workshop was spurred by the increasing presence of constrained devices on the network. It is quite natural to ask how these limitations impact the design of the affected nodes. Note that not all nodes suffer from the same set of limitations.
网络上受限制设备的日益增多推动了研讨会的召开。询问这些限制如何影响受影响节点的设计是很自然的。请注意，并非所有节点都受到相同的限制。
Energy constraints:
能源限制：
Since wireless communication can be a large portion of the power budget for wireless devices, reducing unnecessary communication can significantly increase the battery life of a low-end device. The choice of low-power radio can also significantly impact the overall energy consumption, as can sleeping periodically, when the device is not in use. In some cases, these nodes will only wake periodically to handle needed communications. This constraint is quite in contrast to the "always on" paradigm found in regular Internet hosts. Even in the case of non-battery operated devices, power is a constraint with respect to energy efficiency goals.
由于无线通信可能是无线设备功率预算的很大一部分，因此减少不必要的通信可以显著增加低端设备的电池寿命。低功率收音机的选择也会显著影响整体能耗，当设备不使用时，周期性睡眠也会影响整体能耗。在某些情况下，这些节点只会定期唤醒以处理所需的通信。这种限制与常规Internet主机中的“始终打开”模式形成鲜明对比。即使在非电池供电设备的情况下，功率也是能源效率目标的一个限制因素。
Bandwidth constraints:
带宽限制：
Various low-power radio networks offer only limited bandwidth, and show high packet loss as well as high link quality variability. The data transmission rates vary from 20 to 900 kilobits per second (e.g., in the case of IEEE 802.15.4). Nodes may be used in usually highly unstable radio environments. The physical-layer packet size may be limited (~100 bytes).
各种低功率无线电网络仅提供有限的带宽，并且表现出高分组丢失和高链路质量可变性。数据传输速率在20到900千比特/秒之间变化（例如，在IEEE 802.15.4的情况下）。节点可用于通常高度不稳定的无线电环境中。物理层数据包大小可能受到限制（~100字节）。
Memory constraints:
内存限制：
The amount of volatile and persistent storage impacts the program execution and has important implications for the functionality of the protocol stack. The Arduino UNO board, for example, provides a developer with 2 KB RAM and 32 KB flash memory (without any extensions, such as microSD cards).
易失性和持久性存储的数量会影响程序的执行，并对协议栈的功能产生重要影响。例如，Arduino UNO板为开发人员提供了2 KB RAM和32 KB闪存（无任何扩展，如microSD卡）。
A system designer also needs to consider CPU constraints, which often relate to energy constraints: a processor with lower performance consumes less energy. As described later in this document, the design of the mainboard may allow certain components to be put to sleep to further lower energy consumption. In general, embedded systems are often purpose built with only the hardware components needed for the given task, while general-purpose personal computers are less constrained with regard to their mainboard layout and typically offer a huge number of optional plug-in peripherals to be connected. A factor that also has to be taken into consideration is the intended usage environment. For example, a humidity sensor
系统设计者还需要考虑CPU约束，这常常与能量约束有关：性能较低的处理器消耗较少的能量。如本文件后面所述，主板的设计可能允许某些组件进入休眠状态，以进一步降低能耗。一般来说，嵌入式系统通常是专门构建的，只有特定任务所需的硬件组件，而通用个人计算机在主板布局方面较少受到限制，通常提供大量可选的插件外设进行连接。还必须考虑的一个因素是预期的使用环境。例如，湿度传感器
deployed outside a building may need to deal with temperatures from -50 degrees C to +85 degrees C. There are often physical size limitations for smart objects. While traditional mainboards are rather large, such as the Advanced Technology eXtended (ATX) design with a board size of 305 x 244 mm available in many PCs or the mini-ITX design typically found in home theater PCs with 170 x 170 mm, mainboard layouts for embedded systems are typically much smaller, such as the CoreExpress layout with 58 x 65 mm, or even smaller. In addition to the plain mainboard, additional sensors, peripherals, a power adapter/battery, and a case have to be taken into consideration. Finally, there are cost restrictions as well.
部署在建筑物外可能需要处理-50摄氏度到+85摄氏度的温度。智能对象通常有物理尺寸限制。虽然传统主板相当大，如许多PC机上提供的板尺寸为305 x 244 mm的先进技术扩展（ATX）设计，或170 x 170 mm的家庭影院PC中常见的迷你ITX设计，但嵌入式系统的主板布局通常要小得多，如58 x 65 mm的CoreExpress布局，甚至更小。除普通主板外，还必须考虑其他传感器、外围设备、电源适配器/电池和机箱。最后，还有成本限制。
The situation becomes more challenging when not only the hosts are constrained but also the network nodes themselves.
当不仅主机受到约束，而且网络节点本身也受到约束时，这种情况变得更具挑战性。
While there are constantly improvements being made, Moore's law tends to be less effective in the embedded system space than in personal computing devices: gains made available by increases in transistor count and density are more likely to be invested in reductions of cost and power requirements than into continual increases in computing power.
尽管不断有改进，但摩尔定律在嵌入式系统领域的效果往往不如在个人计算设备领域：晶体管数量和密度增加带来的收益更有可能投资于降低成本和功率需求，而不是持续提高计算能力。
With the ongoing work on connecting smart objects to the Internet, there are many challenges the workshop participants raised in more than 70 accepted position papers. With a single workshop day, discussions had to be focused, and priority was given to those topics that had been raised by many authors. A summary of the identified issues are captured in the subsections below.
随着将智能对象连接到互联网的持续工作，研讨会参与者在70多份公认的立场文件中提出了许多挑战。在一天的研讨会上，讨论必须有重点，并优先考虑许多作者提出的主题。已识别问题的摘要见以下各小节。
A number of architectural questions were brought up in the workshop. This is natural, as the architectural choices affect the required technical solutions and the need for standards. At this workshop, questions regarding the separation of traffic, the need for profiling for application-specific domains, the demand for data-model-specific standardization, as well as the design choices regarding the layer at which functionality should be put were discussed and are briefly summarized below.
研讨会上提出了许多建筑问题。这是很自然的，因为架构选择会影响所需的技术解决方案和对标准的需求。在本次研讨会上，讨论了有关流量分离的问题、特定于应用程序的领域的评测需求、特定于数据模型的标准化需求以及关于功能应放在哪一层的设计选择，并简要总结如下。
Devices that used to be in proprietary or application-specific networks are today migrating to IP networks. There is, however, the question of whether these smart objects are now on the same IP network as any other application. Controlled applications, like the
过去位于专有网络或特定于应用程序的网络中的设备现在正在迁移到IP网络。然而，问题在于这些智能对象现在是否与任何其他应用程序位于同一IP网络上。受控应用程序，如
fountains in front of the Bellagio hotel in Las Vegas that are operated as a distributed control system [Dolin], probably are not exchanging their control messages over the same network that is also used by hotel guests for their Internet traffic. The same had been argued for smart grids, which are described as follows in [SmartGrid]:
拉斯维加斯Bellagio酒店前的喷泉作为分布式控制系统[Dolin]运行，可能没有通过酒店客人用于互联网流量的同一网络交换控制信息。智能电网也是如此，在[SmartGrid]中描述如下：
A smart grid is a digitally enabled electrical grid that gathers, distributes, and acts on information about the behavior of all participants (suppliers and consumers) in order to improve the efficiency, reliability, economics, and sustainability of electricity services.
智能电网是一个数字化电网，它收集、分发所有参与者（供应商和消费者）的行为信息，并根据这些信息采取行动，以提高电力服务的效率、可靠性、经济性和可持续性。
The question that was raised during the workshop is, therefore, in what sense are we talking about one Internet or about using IP technology for a separate, "walled garden" network that is independent of the Internet?
因此，研讨会期间提出的问题是，在什么意义上，我们谈论的是一个互联网，还是将IP技术用于独立于互联网的独立的“围墙花园”网络？
Cullen Jennings compared the current state of smart object deployment with the evolution of Voice over IP (VoIP): "Initially, many vendors recommended to run VoIP over a separate VLAN or a separate infrastructure. Nobody could imagine how to make the type of real-time guarantees, how to debug it, and how to get it to work because the Internet is not ideally suited for making any types of guarantees for real-time systems. As time went on, people got better at making voice work across that type of IP network. They suddenly noticed that having voice running on a separate virtual network than their other applications was a disaster. They couldn't decide if a PC was running a softphone and whether it went on a voice or a data network. At that point, people realized that they needed a converged network and all moved to one. I wouldn't be surprised to see the same happen here. Initially, we will see very separated networks. Then, those will be running over the same hardware to take advantage of the cost benefits of not having to deploy multiple sets of wires around buildings. Over time, there will be strong needs to directly communicate with each other. We need to be designing the system for the long run. Assume everything will end up on the same network even if you initially plan to run it in separate networks."
Cullen Jennings将智能对象部署的当前状态与IP语音（VoIP）的发展进行了比较：“最初，许多供应商建议在单独的VLAN或单独的基础设施上运行VoIP。没有人能想象如何进行实时保证，如何调试，以及如何使其工作，因为互联网并不适合为实时系统进行任何类型的保证。随着时间的推移，人们越来越善于让语音在这种类型的IP网络上工作。他们突然发现，让语音在一个独立的虚拟网络上运行，而不是在其他应用程序上运行，是一场灾难。他们无法确定PC是否运行软电话，以及它是通过语音还是数据网络运行。那时，人们意识到他们需要一个融合的网络，于是全部转移到一个网络上。看到同样的事情在这里发生，我不会感到惊讶。最初，我们将看到非常分离的网络。然后，它们将在相同的硬件上运行，以利用不必在建筑物周围部署多组电线的成本优势。随着时间的推移，将有强烈的相互直接沟通的需求。从长远来看，我们需要设计这个系统。假设所有内容都将在同一个网络上结束，即使您最初计划在不同的网络中运行。”
It is clearly possible to let sensors in a building communicate through the wireless access points and through the same infrastructure used for Internet access, if you want to. Those who want separation at the physical layer can do so as well. What is important is to make sure that these different deployment philosophies do not force loss of interoperability.
很明显，如果您愿意，可以让建筑物中的传感器通过无线接入点和用于互联网接入的相同基础设施进行通信。那些想要在物理层分离的人也可以这样做。重要的是确保这些不同的部署理念不会导致互操作性的丧失。
The level of interoperability that IP accomplished fostered innovation at the application layer. Ralph Droms reinforced this message by saying: "Bright people will take a phone, build an application and connect it, with the appropriate security controls in place, to the things in my house in ways we have never thought about before. Otherwise, we are just building another telephone network."
IP实现的互操作性水平促进了应用层的创新。拉尔夫·德罗姆斯（Ralph Droms）进一步强调了这一点，他说：“聪明人会拿起一部手机，构建一个应用程序，并在适当的安全控制下，以我们从未想过的方式将其连接到我家里的东西。否则，我们只是在构建另一个电话网络。”
Imagine a building network scenario where a new light bulb is installed that should, out of the box without further configuration, interoperate with the already present light switch from a different vendor in the room. For many, this is the desired level of interoperability in the area of smart object design. To accomplish this level of interoperability, it is not sufficient to provide interoperability only at the network layer. Even running the same transport protocol and application-layer protocol (e.g., HTTP) is insufficient since both devices need to understand the semantics of the payloads for "Turn the light on" as well.
设想一个建筑网络场景，其中安装了一个新的灯泡，该灯泡应能够在不进行进一步配置的情况下与房间中其他供应商提供的已存在的灯开关进行互操作。对于许多人来说，这是智能对象设计领域所需的互操作性级别。要实现这一级别的互操作性，仅在网络层提供互操作性是不够的。即使运行相同的传输协议和应用层协议（例如HTTP）也不够，因为两个设备都需要理解“打开灯”的有效负载语义。
Standardizing the entire protocol stack for this specific "light switch / light bulb" scenario is possible. A possible stack would, for example, use IPv6 with a specific address configuration mechanism (such as stateless address autoconfiguration), a network access authentication security mechanism such as Protocol for carrying Authentication for Network Access (PANA) [RFC5191], a service discovery mechanism (e.g., multicast DNS with DNS-Based Service Discovery [DNS-SD]), an application-layer protocol, for example, Constrained Application Protocol (CoAP) [CoAP] (which uses UDP), and the syntax and semantic for the light on/off functionality.
为这种特定的“灯开关/灯泡”场景标准化整个协议栈是可能的。例如，可能的堆栈将使用IPv6和特定的地址配置机制（例如无状态地址自动配置）、网络访问身份验证安全机制，例如用于承载网络访问身份验证的协议（PANA）[RFC5191]，服务发现机制（例如，具有基于DNS的服务发现[DNS-SD]的多播DNS），应用层协议，例如，受限应用协议（CoAP）[CoAP]（使用UDP），以及点亮/熄灭功能的语法和语义。
As this list shows, there is already some amount of protocol functionality that has to be agreed on by various stakeholders to make this scenario work seamlessly. As we approach more complex protocol interactions, the functionality quickly becomes more complex: IPv4 and IPv6 on the network layer, various options at the transport layer (such as UDP, TCP, the Stream Control Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP) [RFC4340]), and there are plenty of choices at the application layer with respect to communication protocols, data formats and data models. Different requirements have led to the development of a variety of communication protocols: client-server protocols in the style of the original HTTP, publish-subscribe protocols (like the Session Initiation Protocol (SIP) [RFC3261] or Extensible Messaging and Presence Protocol (XMPP) [RFC6121]), and store-and-forward messaging (borrowed from the delay tolerant
正如这个列表所示，为了使这个场景无缝地工作，已经有一些协议功能需要各涉众同意。随着我们接近更复杂的协议交互，功能迅速变得更复杂：网络层上的IPv4和IPv6，传输层上的各种选项（如UDP、TCP、流控制传输协议（SCTP）[RFC4960]和数据报拥塞控制协议（DCCP）[RFC4340]），在应用层，在通信协议、数据格式和数据模型方面有很多选择。不同的需求导致了各种通信协议的开发：原始HTTP风格的客户机-服务器协议、发布-订阅协议（如会话启动协议（SIP）[RFC3261]或可扩展消息和状态协议（XMPP）[RFC6121]）以及存储和转发消息（借用《延迟容忍》一书）
networking community). Along with the different application-layer communication protocols come various identity and security mechanisms.
网络社区）。随着不同的应用层通信协议，出现了各种身份和安全机制。
With the smart object constraints, it feels natural to develop these stacks since each application domain (e.g., healthcare, smart grids, building networking) will have their unique requirements and their own community involved in the design process. How likely are these profiles going to be the right match for the future, specifically for the new innovations that will come? How many of these stacks are we going to have? Will the differences in the profiles purely be the result of different requirements coming from the individual application domains or will these mismatches reflect the spirit, understanding, and preferences of the community designing them? How many stacks will multipurpose devices have to implement?
在智能对象约束下，开发这些堆栈感觉很自然，因为每个应用领域（例如，医疗保健、智能电网、建筑网络）在设计过程中都有其独特的需求和自己的社区。这些配置文件与未来，特别是即将到来的新创新相匹配的可能性有多大？我们将有多少个这样的堆栈？概要文件中的差异纯粹是来自各个应用程序域的不同需求的结果，还是这些不匹配反映了设计它们的社区的精神、理解和偏好？多用途设备需要实现多少堆栈？
Standardizing profiles independently for each application is not the only option. Another option is to let many different applications utilize a common foundation, i.e., a protocol stack that is implemented and utilized by every device. This, however, requires various application domains to be analyzed for their common characteristics and to identify requirements that are common across all of them. The level of difficulty for finding an agreement of how such a foundation stack should look depends on how many layers it covers and how lightweight it has to be.
独立地为每个应用程序标准化配置文件并不是唯一的选择。另一种选择是让许多不同的应用利用共同基础，即，由每个设备实现和利用的协议栈。然而，这需要分析各种应用程序域的共同特征，并确定它们之间的共同需求。寻找这样一个基础堆栈应该如何达成的难度取决于它覆盖了多少层和它必须是多么轻。
From the discussions at the workshop, it was clear that the available options are not ideal and further discussions are needed.
从研讨会上的讨论可以看出，现有的备选方案并不理想，需要进一步讨论。
The end-to-end principle states that functionality should be put into the end points instead of into the networks. An additional recommendation, which is equally important, is to put functionality higher up in the protocol stack. While it is useful to make common functionality available as building blocks to higher layers, the wide range of requirements by different applications led to a model where lower layers provide only very basic functionality and more sophisticated features were made available by various applications. Still, there has been the desire to put application-layer functionality into the lower layers of the networking stack. A common belief is that performance benefits can be gained if functionality is placed at the lower layers of the protocol stack. This new functionality may be offered in the form of a gateway, which bridges different communication technologies, acts on behalf of other nodes, and offers more generic functionality (such as name-based routing and caching).
端到端原则指出，功能应该放在端点而不是网络中。另一个同样重要的建议是将功能放在协议栈的更高位置。虽然将通用功能作为构建块提供给更高层是有用的，但不同应用程序的广泛需求导致了一种模型，其中较低层只提供非常基本的功能，而更复杂的功能由各种应用程序提供。尽管如此，人们还是希望将应用层功能放在网络堆栈的较低层中。人们普遍认为，如果将功能放在协议栈的较低层，则可以获得性能优势。这种新功能可以以网关的形式提供，网关桥接不同的通信技术，代表其他节点，并提供更通用的功能（例如基于名称的路由和缓存）。
Two examples of functionality offered at the network layer and discussed during the workshops were location and name-based routing:
研讨会期间讨论的网络层提供的两个功能示例是基于位置和名称的路由：
Location:
地点：
The notion of location gives each network node the understanding of proximity (e.g., 'I am a light bulb and in the same room as the light switch.'). Today, a router may provide information as to whether other nodes belong to the same subnet or they may provide location information (for example, in the form of GPS-based coordinates). However, providing a sense of the specific environment (e.g., a room, building, campus, etc.) is not possible without manual configuration. While it has been a desirable feature for many ubiquitous computing applications to know this type of information and to use it for richer application-layer interactions, widespread deployment has not happened yet.
位置的概念为每个网络节点提供了对邻近性的理解（例如，“我是一个灯泡，与电灯开关在同一个房间里”）。今天，路由器可以提供关于其他节点是否属于同一子网的信息，或者它们可以提供位置信息（例如，以基于GPS的坐标的形式）。但是，如果没有手动配置，则无法提供特定环境（例如房间、建筑物、校园等）的感知。虽然对于许多普适计算应用程序来说，了解这类信息并将其用于更丰富的应用层交互是一种可取的功能，但尚未实现广泛的部署。
Name-Based Routing:
基于名称的路由：
With the work on recent "clean slate" architecture proposals, such as named data networking, flexible naming concepts are being researched to allow application developers to express their application-layer concepts in a way that they can be used natively by the underlying networking stack without translation. For example, Jeff Burke provided the example of his work in a theater with a distributed control system of technical equipment (such as projectors, dimmers, and light systems). Application developers name their equipment with human-readable identifiers, which may change after the end of a rehearsal, and address them using these names. These naming concepts based on variable-length strings raise questions regarding scalability.
随着最近“干净板岩”体系结构提案（如命名数据网络）的研究，正在研究灵活的命名概念，以允许应用程序开发人员以一种无需翻译即可由底层网络堆栈本地使用的方式来表达其应用程序层概念。例如，杰夫·伯克（Jeff Burke）提供了他在一家剧院工作的例子，该剧院配备了技术设备的分布式控制系统（如投影仪、调光器和灯光系统）。应用程序开发人员用人类可读的标识符命名他们的设备，这些标识符在排练结束后可能会改变，并使用这些名称对设备进行命名。这些基于可变长度字符串的命名概念提出了有关可伸缩性的问题。
The workshop participants were not able to come to an agreement about what functionality should be moved from the application layer to the network layer.
研讨会参与者未能就应将哪些功能从应用程序层移动到网络层达成一致。
One limitation of smart objects is their available energy. To extend battery life, for example, of a watch battery or single AAA battery for months, these low-power devices have to sleep 99% to 99.5% of their time. For example, a light sensor may only wake up to check whether it is nighttime to turn on light bulbs. Most parts of the system, particularly communication components, are put into a sleeping state (e.g., WLAN radio interface) and selected components,
智能对象的一个限制是其可用能量。例如，为了延长手表电池或单个AAA电池的电池寿命数月，这些低功耗设备必须睡眠99%到99.5%的时间。例如，光传感器可能只会醒来检查是否在夜间打开灯泡。系统的大多数部分，尤其是通信组件，都处于休眠状态（例如WLAN无线电接口），并且选定的组件，
such as sensors, periodically check for relevant events and, if necessary, turn on other hardware modules. Every bit is precious, as is every round trip and every millisecond of radio activity.
如传感器，定期检查相关事件，如有必要，打开其他硬件模块。每一点都是宝贵的，就像每一次往返和每一毫秒的无线电活动一样。
Many IETF protocols are implicitly designed to be always on, i.e., the protocol implementation waits for and reacts to incoming messages, and may maintain session state (at various layers of the stack). These protocols work well when energy consumption is not a concern and when receiving and sending messages happen at a low cost. It should be understood that energy is consumed both in transmitting messages (and often more importantly) in keeping the receiver awake. Allowing devices to sleep most of the time preserves energy but creates challenges for protocol designs.
许多IETF协议被隐式设计为始终开启，即，协议实现等待传入消息并对其作出反应，并且可以维护会话状态（在堆栈的各个层）。当能量消耗不是一个问题并且接收和发送消息的成本较低时，这些协议工作得很好。应该理解的是，在发送消息（通常更重要的是）和保持接收器清醒时都会消耗能量。允许设备大部分时间处于睡眠状态可以节省能源，但会给协议设计带来挑战。
The inherent issue encountered by a stationary node resuming from sleep is that another node may have chosen the same address while the node was asleep. A number of steps have to be taken before sending a packet. A new address may have to be obtained, for example using the Dynamic Host Configuration Protocol (DHCP) or stateless address autoconfiguration. Optionally, Detecting Network Attachment (DNA) procedures (see [RFC4436] and [RFC6059]) can be used to shorten the setup time by noticing that the node is using the same default gateway.
从睡眠中恢复的固定节点遇到的固有问题是，另一个节点可能在该节点睡眠时选择了相同的地址。在发送数据包之前，必须采取许多步骤。可能必须获得新地址，例如使用动态主机配置协议（DHCP）或无状态地址自动配置。或者，可以使用检测网络连接（DNA）过程（参见[RFC4436]和[RFC6059]）来缩短设置时间，方法是注意到节点正在使用相同的默认网关。
The issue with a mobile node that is sleeping is that the node may have been moved to another network (e.g., a sleeping laptop being transported to a new environment) where on resumption it may discover that its address has become invalid.
处于睡眠状态的移动节点的问题是，该节点可能已移动到另一个网络（例如，正在将处于睡眠状态的笔记本电脑传输到新环境），在恢复时，该节点可能会发现其地址已变得无效。
The following design considerations should be taken into account when energy efficiency is a concern:
当考虑能源效率时，应考虑以下设计因素：
1. Rethink the Always-On Assumption
1. 重新思考“始终基于”的假设
When designing a protocol that assumes that the nodes are always on, alternatives need to be considered. This could involve eliminating functionality (e.g., not implementing DNA or duplicate address detection) or considering the use of a sleep proxy. While sleep proxies (e.g., proxZzzy(TM) [proxZzzy]) enable periodic messages to be sent on behalf of sleeping nodes, this approach assumes that energy management constraints do not apply to the sleep proxy, which may not always be the case (e.g., if the entire network is deployed in the field without access to power). Yet another option is for devices to explicitly communicate sleep cycles so that they can only check for messages periodically (be it measured in milliseconds, seconds, or hours).
当设计一个假定节点始终处于开启状态的协议时，需要考虑其他方案。这可能涉及取消功能（例如，不实施DNA或重复地址检测）或考虑使用睡眠代理。虽然睡眠代理（例如Proxzzy（TM）[Proxzzy]）能够代表睡眠节点发送周期性消息，但该方法假设能量管理约束不适用于睡眠代理，这可能并不总是如此（例如，如果整个网络部署在现场而没有通电）。另一种选择是设备显式地传递睡眠周期，以便它们只能定期检查消息（以毫秒、秒或小时为单位）。
This is the approach taken in IEEE 802.11, which supports multiple energy conservation mechanisms designed to enable a station to spend a large fraction of the time sleeping.
这是IEEE 802.11中采用的方法，该方法支持多种节能机制，旨在使站点花费大部分时间睡眠。
2. Reduce Network Attachment Costs
2. 降低网络连接成本
As noted above, the procedures for obtaining an address and assuring its uniqueness can be costly. In a network where nodes spend a large fraction of the time sleeping, but are not necessarily mobile, are all of these procedures really necessary?
如上所述，获取地址并确保其唯一性的过程可能代价高昂。在一个节点大部分时间处于睡眠状态但不一定是移动的网络中，所有这些过程真的都是必要的吗？
Can we find ways to reduce the number of protocol interactions without sacrificing correctness? The main focus of past investigations has been on IPv6 and ND, but other protocols do also deserve a deeper investigation, such as DNS and DHCP.
我们能找到在不牺牲正确性的情况下减少协议交互次数的方法吗？过去的研究主要集中在IPv6和ND上，但其他协议也值得深入研究，如DNS和DHCP。
3. Avoid Verbose Protocols
3. 避免冗长的协议
Protocols involving multiple roundtrips and/or lengthy messages with verbose encodings (e.g., XML) are not always well-suited for constrained environments. Low-power nodes utilizing verbose protocols have to use more energy in sending messages and have to stay powered on for a longer period of time as they wait for the multi-roundtrip protocol exchanges to complete.
涉及多个往返和/或带有详细编码（如XML）的冗长消息的协议并不总是非常适合受约束的环境。使用详细协议的低功耗节点在发送消息时必须使用更多的能量，并且在等待多回程协议交换完成时必须保持通电更长时间。
The best way to address these problems is to ensure that the simplest possible protocol exchanges are used when the protocols in question are designed. In some cases, alternative encoding formats and compression may also help.
解决这些问题的最佳方法是确保在设计相关协议时使用最简单的协议交换。在某些情况下，替代编码格式和压缩也可能有所帮助。
4. Think about System-Wide Efficiency
4. 想想全系统的效率
While energy efficiency is critical for low-power devices running on batteries, it is also beneficial for other devices as well, including notebook computers, desktop computers, and smartphones. However, if the goal is energy efficiency as opposed to battery life extension for low-power devices, then it is important to consider the total energy consumption of all the elements of the system.
虽然能源效率对于使用电池的低功耗设备至关重要，但它也有利于其他设备，包括笔记本电脑、台式电脑和智能手机。然而，如果目标是能量效率，而不是低功率器件的电池寿命延长，那么重要的是要考虑系统的所有元件的总能量消耗。
For example, consider energy consumption in a home environment. In these scenarios it is important to evaluate the energy usage of the entire system. A light bulb utilizing Internet technology described in this document may use less power but there is also the device that controls the bulb that may consume a lot of energy. If the goal is to reduce overall energy usage, then it is important to consider these two devices (and potentially many others) together.
例如，考虑家庭环境中的能源消耗。在这些情况下，重要的是评估整个系统的能源使用情况。本文档中描述的利用互联网技术的灯泡可能耗电较少，但也有控制灯泡的装置可能会消耗大量能源。如果目标是减少整体能源使用，那么重要的是要考虑这两个设备（和潜在的许多其他）一起。
In the development of smart object applications, as with any other protocol application solution, security has to be considered early in the design process. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 [RFC3552] and RFC 4101 [RFC4101], apply also to the smart object space.
在智能对象应用程序的开发过程中，与任何其他协议应用程序解决方案一样，必须在设计过程的早期考虑安全性。因此，目前提供给IETF协议架构师的建议，如RFC 3552[RFC3552]和RFC 4101[RFC4101]也适用于智能对象空间。
While there are additional constraints, as described in Section 2, security has to be a mandatory part of the solution. The hope is that this will lead to implementations that provide security features, deployments that utilize them, and finally use of better security mechanisms. It is important to point out that the lack of direct user interaction will place hard requirements on deployment models, configuration mechanisms, and software upgrade / crypto-agility mechanisms.
如第2节所述，虽然存在其他限制，但安全性必须是解决方案的强制性部分。希望这将导致提供安全功能的实现、利用这些功能的部署，以及最终使用更好的安全机制。必须指出的是，缺乏直接用户交互将对部署模型、配置机制和软件升级/加密敏捷性机制提出严格要求。
Since many of the security mechanisms allow for customization, particularly with regard to the cryptographic primitives utilized, many believe that IETF security solutions are usable without modifications in a large part of the smart object domain. Others call for new work on cryptographic primitives that make use of a single primitive (such as the Advanced Encryption Standard (AES) [AES]) as a building block for all cryptographic functions. The benefit would be a smaller footprint of the overall solution, specifically with respect to hardware limitations (e.g., the hardware architecture of certain embedded devices prevents pipelining from being used). In the excitement for new work on optimizations of cryptographic primitives, other factors have to be taken into consideration that influence successful deployment, such as widespread support in libraries, as well as intellectual property rights (IPR). As an example of the latter aspect, the struggle of Elliptic Curve Cryptography (ECC)-based cryptographic algorithms [ECC] to find deployment can partially be attributed to its IPR situation. The reuse of libraries providing cryptographic functions is clearly an important way to use available memory resources in a more efficient way. To deal with the performance and footprint concerns, investigations into offloading certain resource-hungry functions to parties that possess more cryptographic power have been considered. For example, the ability to delegate certificate validation to servers has been standardized in the IETF before, for the support of the Online Certificate Status Protocol (OCSP) in the Internet Key Exchange protocol version 2 (IKEv2) and in Transport Layer Security (TLS); see [RFC4806] and [RFC5246], respectively.
由于许多安全机制允许定制，特别是关于所使用的加密原语，许多人认为IETF安全解决方案在智能对象领域的很大一部分无需修改即可使用。其他人则要求对加密原语进行新的研究，这些原语使用单个原语（如高级加密标准（AES）[AES]）作为所有加密功能的构建块。好处是整个解决方案的占地面积更小，特别是在硬件限制方面（例如，某些嵌入式设备的硬件架构阻止使用流水线）。在对加密原语优化的新工作感到兴奋的同时，还必须考虑影响成功部署的其他因素，如图书馆的广泛支持以及知识产权（IPR）。作为后一方面的一个例子，基于椭圆曲线密码术（ECC）的密码算法[ECC]寻找部署的斗争可以部分归因于其知识产权状况。重用提供加密功能的库显然是以更有效的方式使用可用内存资源的重要途径。为了解决性能和占用空间的问题，已经考虑了将某些资源匮乏的功能卸载给拥有更多加密能力的各方的调查。例如，为了支持Internet密钥交换协议版本2（IKEv2）和传输层安全协议（TLS）中的在线证书状态协议（OCSP），IETF之前已经对将证书验证委托给服务器的能力进行了标准化；分别参见[RFC4806]和[RFC5246]。
Focusing only on the cryptographic primitives would be shortsighted; many would argue that this is the easy part of a smart object security solution. Key management and credential enrollment,
只关注密码原语是短视的；许多人认为，这是智能对象安全解决方案的简单部分。密钥管理和凭证注册，
however, are considered a big challenge by many, particularly when usability requirements have to be taken into account. Another group of challenges concern privacy; with smart grids, for example, some have voiced concerns regarding the ability of third parties to keep track of an individual's energy consumption (and draw associated conclusions). As another example, it is easy to see how a scale that is connected to the Internet for uploading weight information to a social network could lead to privacy concerns. While security mechanisms that are used to offer protection of the communication between different parties also provide a certain degree of privacy protection, they are clearly not enough to address all concerns. Even with the best communication security and access control mechanisms in place, one still needs additional safeguards against the concerns mentioned in the examples.
然而，许多人认为这是一个巨大的挑战，特别是当必须考虑可用性需求时。另一组挑战涉及隐私；例如，对于智能电网，一些人对第三方跟踪个人能源消耗（并得出相关结论）的能力表示担忧。另一个例子是，很容易看出连接到互联网用于将体重信息上传到社交网络的秤会导致隐私问题。虽然用于保护不同当事方之间通信的安全机制也提供了一定程度的隐私保护，但它们显然不足以解决所有问题。即使有了最好的通信安全和访问控制机制，仍然需要针对示例中提到的问题采取额外的保护措施。
While better deployment of security protocols on the entire Internet would be very desirable, practical considerations regarding usability and the incentives of the stakeholders involved have often lead to slower adoption.
虽然在整个互联网上更好地部署安全协议是非常可取的，但有关可用性的实际考虑和相关利益相关者的激励往往导致采用速度较慢。
A smart object network environment may also employ routers under similar constraints as the end devices. Currently two approaches to routing in these low-power and lossy networks are under consideration -- namely, mesh-under and route-over. The so-called "mesh-under" approach places routing functions at the link layer, and consequently all devices appear as immediate neighbors at the network layer. With the "route-over" approach, routing is done in the IP layer and not at all in the link layer. Each physical hop appears as a single IP hop (ignoring devices that just extend the physical range of signaling, such as repeaters). Routing in this context means running a routing protocol. The IPv6 Routing Protocol for Low-power and Lossy Networks (RPL) [RPL], for example, belongs to the route-over category.
智能对象网络环境也可以在与终端设备类似的约束下使用路由器。目前，在这些低功耗和有损网络中，有两种路由方法正在考虑之中，即“网下”和“路由上”。所谓的“网格下”方法将路由功能放置在链路层，因此所有设备在网络层都显示为直接邻居。使用“路由覆盖”方法，路由在IP层完成，而不是在链路层完成。每个物理跃点显示为单个IP跃点（忽略仅扩展信令物理范围的设备，如中继器）。在此上下文中，路由意味着运行路由协议。例如，用于低功耗和有损网络的IPv6路由协议（RPL）[RPL]属于路由覆盖类别。
From an architectural point of view there are several questions that arise from where routing is provided, for example:
从架构的角度来看，在提供布线的地方会出现几个问题，例如：
o Protocols often assume that link characteristics are predictable when communicating with any device attached to the same link. Latency, throughput, and reliability may vary considerably between different devices that are multiple link-layer hops away. What timeout should be used? What happens if a device is unreachable? In case of default router selection, two advertised routers may be a different number of hops away. Should a device have visibility into the path to make a decision, and what path characteristics would be useful to have?
o 协议通常假定，当与连接到同一链路的任何设备通信时，链路特性是可预测的。延迟、吞吐量和可靠性在多链路层跳转的不同设备之间可能会有很大差异。应该使用什么超时？如果无法访问设备，会发生什么情况？在默认路由器选择的情况下，两个播发的路由器之间的跳数可能不同。设备是否应该能够看到路径以做出决策，以及哪些路径特征是有用的？
o Scoped message delivery to a neighboring IP hop (via link-local addressing) allows certain types of IP protocols to communicate with their immediate neighbors and to therefore scope their recipients. A link-local multicast message will be received by all nodes in the same IP link-local realm unless some special optimizations are provided by the link layer.
o 作用域消息传递到相邻IP跃点（通过链路本地寻址）允许某些类型的IP协议与其直接邻居通信，从而作用域其收件人。除非链路层提供了一些特殊的优化，否则同一IP链路本地域中的所有节点都将接收链路本地多播消息。
o When path computations are done at the link layer as well as on the network layer, then what coordination needs to take place?
o 当在链路层和网络层进行路径计算时，需要进行什么协调？
When multiple different link-layer technologies are involved in a network design, routing at layer 3 has to be provided in any case. [IoT-ARCH] talks about these tradeoffs between route-over and mesh-under in detail. Furthermore, those who decide about the deployment have to determine how to connect smart objects to the Internet infrastructure, and a number of wired and wireless technologies may be suitable for a specific deployment. Depending on the chosen technologies the above-mentioned mesh-under vs. route-over approach will have to be decided, and further decisions will have to be made about the choice of a specific routing protocol.
当网络设计涉及多种不同的链路层技术时，在任何情况下都必须在第3层提供路由。[IoT ARCH]详细讨论了路由覆盖和网格覆盖之间的权衡。此外，决定部署的人必须确定如何将智能对象连接到互联网基础设施，许多有线和无线技术可能适用于特定部署。根据所选择的技术，必须确定上述“网下vs.路由覆盖”方法，并就特定路由协议的选择做出进一步的决定。
In 2008, the IETF formed the Routing Over Low power and Lossy networks (ROLL) working group to specify a routing solution for smart object environments. During its first year of existence, the working group studied routing requirements in detail (see [RFC5867], [RFC5826], [RFC5673], and [RFC5548]), and it worked on a protocol survey comparing a number of existing routing protocols, including Ad hoc On-Demand Distance Vector (AODV)-style protocols [RFC3561], against the identified requirements. The protocol survey [PROT-SURVEY] was inconclusive and abandoned without giving rise to publication of an RFC.
2008年，IETF成立了低功耗和有损网络路由（ROLL）工作组，以指定智能对象环境的路由解决方案。在成立的第一年，工作组详细研究了路由需求（见[RFC5867]、[RFC5826]、[RFC5673]和[RFC5548]），并进行了协议调查，将一些现有路由协议（包括特殊按需距离向量（AODV）式协议[RFC3561]）与确定的需求进行了比较。协议调查[PROT-survey]未得出结论，在未发布RFC的情况下被放弃。
The ROLL WG concluded that a new routing protocol satisfying the documented requirements has to be developed and the work on RPL was started as the IETF routing protocol for smart object networks. Nevertheless, controversial discussions at the workshop about which routing protocols is best in a given environment are still ongoing. Thomas Clausen, for example, argued for using an AODV-like routing protocol in [Clausen].
ROLL WG得出结论，必须开发满足文件要求的新路由协议，并且RPL的工作作为智能对象网络的IETF路由协议开始。尽管如此，研讨会上关于在给定环境中哪种路由协议最好的争议仍在进行中。例如，Thomas Clausen主张在[Clausen]中使用类似AODV的路由协议。
The workshop allowed the participants to be exposed to interesting applications and their requirements (buildings, fountains, theater, etc.), to have discussions about radically different architectures and their issues (e.g., information centric networking), to look at existing technology from a new angle (sleeping nodes, energy consumption), to focus on some details of the protocol stack (neighbor discovery, security, routing) and to learn about implementation experience.
研讨会允许参与者接触有趣的应用程序及其需求（建筑物、喷泉、剧院等），讨论截然不同的架构及其问题（例如，以信息为中心的网络），从新的角度看待现有技术（睡眠节点、能耗），重点介绍协议栈的一些细节（邻居发现、安全性、路由），并了解实现经验。
One goal of the workshop was to identify areas that require further investigation. The list below reflects the thoughts of the workshop participants as expressed on the day of the workshop. Note that the suggested items concern potential work by the IETF and the IRTF, and the order does not imply a particular preference.
讲习班的一个目标是确定需要进一步调查的领域。以下列表反映了研讨会参与者在研讨会当天表达的想法。请注意，建议的项目涉及IETF和IRTF的潜在工作，顺序并不意味着特定的偏好。
Security:
安全：
A discussion of security is provided in Section 3.3. In general, security-related protocol exchanges and the required amount of computational resource requirements can contribute significantly to the overall processing. Therefore, it remains a challenge to accomplish performance improvements without sacrificing the overall security level, taking the usability of the entire system into consideration.
第3.3节对安全性进行了讨论。一般来说，与安全相关的协议交换和所需的计算资源需求量会对整体处理产生重大影响。因此，考虑到整个系统的可用性，在不牺牲总体安全级别的情况下实现性能改进仍然是一个挑战。
Another challenge is how to balance the security and performance needs of smart objects with the interoperability requirements of hosts on the Internet since different suites of algorithms tend to be chosen for these different environments. This involves trade-offs between performance on the smart objects versus end-to-end security. Solutions that mandate a "trusted" middlebox whose only role is to terminate security associations tend to be frowned upon from the security perspective, especially since end users of challenged devices (where those exist) are unlikely to understand the security consequences of such middleboxes.
另一个挑战是如何平衡智能对象的安全性和性能需求与Internet上主机的互操作性需求，因为这些不同的环境往往会选择不同的算法套件。这涉及智能对象性能与端到端安全性之间的权衡。从安全角度来看，不赞成强制使用“受信任”的中间箱（其唯一作用是终止安全关联）的解决方案，特别是因为受质疑设备（如果存在）的最终用户不太可能理解此类中间箱的安全后果。
The discussion concluded with the following recommendations:
讨论结束时提出以下建议：
* Investigate usability in cryptographic protocol design with regard to credential management. As an example, the Bluetooth pairing mechanism was mentioned as a simple and yet reasonably secure method of introducing devices into a new environment. In fact, the IETF working group Credential and Provisioning (ENROLL) was established years ago to deal with residential
* 调查密码协议设计中有关凭证管理的可用性。例如，蓝牙配对机制被认为是将设备引入新环境的一种简单而合理的安全方法。事实上，IETF工作组凭证和资源调配（ENROLL）是在几年前成立的，目的是处理住宅问题
networks but was terminated prematurely due to lack of progress. The email archive still exists and is available [ENROLL] and may provide useful historical information.
但由于缺乏进展而提前终止。电子邮件存档仍然存在，并且可用[ENROLL]，可能会提供有用的历史信息。
* Standardized authentication and key exchange mechanisms should be surveyed for suitability in smart object environments with respect to message size, computational performance, number of messages, code size, and main memory requirements. A starting point of such an investigation (in the case of IKEv2) was provided by Tero Kivinen with [MINIMAL-IKEv2], and a suitable venue for discussion could be the recently established Light-Weight Implementation Guidance (LWIG) working group [LWIG].
* 应调查标准化身份验证和密钥交换机制在智能对象环境中是否适合消息大小、计算性能、消息数量、代码大小和主内存要求。Tero Kivinen与[MINIMAL-IKEv2]一起提供了此类调查的起点（在IKEv2的情况下），最近成立的轻型实施指南（LWIG）工作组[LWIG]是讨论的合适场所。
* Research has to be done in the area of lightweight cryptographic primitives -- namely, block ciphers, stream ciphers, and cryptographic hash functions. It's worthwhile to mention the early work with the National Institute of Standards and Technology (NIST) new cryptographic hash algorithm 'SHA-3' competition [SHA3]. A suitable forum for discussion is the IRTF Crypto Forum Research Group (CFRG) [CFRG].
* 必须在轻量级密码原语领域进行研究——即分组密码、流密码和加密哈希函数。值得一提的是，美国国家标准与技术研究所（NIST）新密码散列算法“SHA-3”竞赛的早期工作[SHA3]。一个合适的讨论论坛是IRTF加密论坛研究小组（CFRG）[CFRG]。
The difficulty and impact of choosing specialized algorithms for smart objects should not be underestimated. Issues that arise include the additional specification complexity (e.g., TLS already has hundreds of ciphersuites defined, most of which are unused in practice), the long latency in terms of roll out (many hosts are still using deprecated algorithms 5-10 years after those algorithms were deprecated), and the barriers that IPR-encumbered schemes present to widespread deployment. While research on this topic within CFRG and the cryptographic research community is a very worthwhile goal, any such algorithms will likely have to offer very significant benefits before they will be broadly adopted. 20% less CPU usage is unlikely to be a winning argument no matter what an algorithm inventor believes.
不应低估为智能对象选择专门算法的难度和影响。出现的问题包括额外的规范复杂性（例如，TLS已经定义了数百个密码套件，其中大多数在实践中未使用）、推出方面的长延迟（许多主机在这些算法被弃用5-10年后仍在使用弃用的算法），以及阻碍知识产权保护计划广泛实施的障碍。虽然在CFRG和密码学研究社区内对这一主题的研究是一个非常有价值的目标，但任何此类算法在被广泛采用之前都可能会提供非常显著的好处。无论算法发明家相信什么，CPU使用率降低20%都不可能是一个成功的论据。
Energy Design Considerations:
能源设计注意事项：
One part of the workshop was focused on the discussion of energy implications for IETF protocol design with proposals being made about how to extend protocols to better support nodes that are mostly sleeping. Discussions are encouraged to take place on the RECIPE mailing list [RECIPE]. The workshop position paper [Wasserman] by Margaret Wasserman provides a good starting point for further investigations.
研讨会的一部分重点讨论了IETF协议设计的能源影响，并就如何扩展协议以更好地支持大部分处于睡眠状态的节点提出了建议。鼓励在配方邮寄列表[配方]上进行讨论。Margaret Wasserman撰写的研讨会立场文件[Wasserman]为进一步调查提供了良好的起点。
Information-/Content-Centric Networking:
以信息/内容为中心的网络：
Information/Content Centric Networking is about accessing named content, and a number of research projects have emerged around this theme. At this point in time, the work is not yet ready for standardization in the IETF. Instead, the formation of an IRTF research group has been proposed, and more details are available on the IRTF DISCUSS mailing list [irtf-discuss].
以信息/内容为中心的网络是关于访问命名内容的，围绕这一主题出现了许多研究项目。目前，这项工作尚未准备好在IETF中进行标准化。相反，已提议成立一个IRTF研究小组，更多详细信息可在IRTF讨论邮件列表[IRTF讨论]中找到。
Architectural Guidelines:
建筑指南：
Participants suggested developing an architectural write-up about what can be done with the IETF protocols we have today and how these different elements may be combined to offer an explanation for the broader community. This would be a task for the IAB. An example of prior work that serves as input is [RFC6272].
与会者建议编写一份体系结构报告，说明我们现在使用的IETF协议可以做些什么，以及如何将这些不同的元素结合起来，为更广泛的社区提供解释。这将是IAB的一项任务。[RFC6272]是作为输入的先前工作的一个示例。
Network Management:
网络管理：
While this topic did not make it onto the workshop agenda, it was considered useful to start a discussion about how to implement network management protocols, such as Network Configuration Protocol (NETCONF) [RFC6241], on smart objects. The following position papers may be useful as a starting point for further discussions: [Ersue] and [Schoenwaelder]. An IETF draft document is also available: [SNMP-OPT].
虽然本主题未列入研讨会议程，但人们认为，开始讨论如何在智能对象上实施网络管理协议（如网络配置协议（NETCONF）[RFC6241]）是有益的。以下立场文件可作为进一步讨论的起点：[Ersue]和[Schoenwaeld]。IETF草案文件也可提供：[SNMP-OPT]。
Congestion Control:
拥塞控制：
When smart objects transmit sensor readings to some server on the Internet, these protocol interactions often carry a small amount of data and happen infrequently, although regularly. With the work on new application protocols, like CoAP [CoAP], the question of whether a congestion control mechanism should be used at the underlying transport protocol or by the application protocol itself arises. [CoAP-CC] is a starting point for CoAP, but further work is needed.
当智能对象将传感器读数传输到互联网上的某个服务器时，这些协议交互通常携带少量数据，并且不经常发生，尽管有规律。随着对新的应用协议（如CoAP[CoAP]）的研究，出现了拥塞控制机制是应该在底层传输协议中使用还是由应用协议本身使用的问题。[CoAP CC]是CoAP的起点，但还需要进一步的工作。
Data Models:
数据模型：
Standardization of application-layer protocols is important but does not ensure that, for example, a light switch and a light bulb are able to interact with each other. One area where participants saw the need for further work was in the area of data models. While prior IETF standardization work on, for example, location [GEOPRIV] can be reused, the question was raised where the IETF
应用层协议的标准化很重要，但不能确保，例如，灯开关和灯泡能够相互作用。与会者认为需要进一步开展工作的一个领域是数据模型领域。虽然之前的IETF标准化工作涉及位置[GEOPRIV]等可重用性，但问题是IETF在哪里
should focus its standardization efforts since domain expertise in each area will be needed. As a potential example, energy pricing was discussed, with an example provided by [ENERGY-PRICING].
应集中其标准化工作，因为每个领域都需要领域专家。作为一个潜在的例子，讨论了能源定价，其中一个例子由[能源定价]提供。
Building Networking:
楼宇联网：
Network architectures in residential as well as commercial buildings should take the presence of smart objects and dedicated subnetworks focusing on smart objects into account. A new working group, Home Networking (HOMENET) [HOMENET], was created after the workshop to look at this topic.
住宅和商业建筑中的网络架构应考虑智能对象的存在，以及专注于智能对象的专用子网。研讨会结束后，成立了一个新的工作组，即家庭网络（HOMENET）[HOMENET]，研究这一主题。
Discovery:
发现：
Additional extensions to developed discovery protocols, such as multicast DNS (mDNS), may be needed for the smart object environment. For instance, the HOMENET working group wants to extend current discovery protocols to work across multiple subnets. Smart object networks are often organized in separate subnets, so these extensions may be useful in that environment as well.
智能对象环境可能需要对已开发的发现协议（如多播DNS（MDN））进行其他扩展。例如，HOMENET工作组希望扩展当前的发现协议以跨多个子网工作。智能对象网络通常组织在单独的子网中，因此这些扩展在该环境中也可能有用。
Routing:
路由：
Changing radio conditions and link fluctuation may lead to the need for renumbering. Workshop participants argued that work should be started on the multi-link subnetworks to mitigate this problem, i.e., to extend the notion of a subnet to be able to span multiple links. With the publication of RFC 4903 [RFC4903], the Internet Architecture Board had looked into this topic already and provided pros and cons.
改变无线电条件和链路波动可能导致需要重新编号。研讨会参与者认为，应着手研究多链路子网，以缓解这一问题，即扩展子网的概念，使其能够跨越多个链路。随着RFC 4903[RFC4903]的出版，互联网体系结构委员会已经研究了这个主题，并提供了利弊。
The applicability of specific routing protocols designed for smart object networks needs further investigation. The ROLL working group is chartered with the task of constructing an applicability document for RPL, for instance.
为智能对象网络设计的特定路由协议的适用性需要进一步研究。例如，滚动工作组的任务是构建RPL的适用性文件。
The workshop discussions covered a range of potential engineering activities, each with its own security considerations. As the IETF community begins to pursue specific avenues arising out of this workshop, addressing relevant security requirements will be crucial.
研讨会讨论了一系列潜在的工程活动，每个活动都有自己的安全考虑。随着IETF社区开始寻求本次研讨会产生的具体途径，解决相关安全需求将至关重要。
As described in this report, part of the agenda was focused on the discussion of security; see Section 3.3.
如本报告所述，部分议程侧重于安全问题的讨论；见第3.3节。
We would like to thank all the participants for their position papers. The authors of the accepted position papers were invited to the workshop.
我们要感谢所有与会者的立场文件。接受的立场文件的作者被邀请参加研讨会。
Big thanks to Elwyn Davies for helping us to fix language bugs. We would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas Clausen, Bruce Nordman, Alissa Cooper, Dave Thaler, Bernard Aboba, and Henning Schulzrinne for their review comments.
非常感谢Elwyn Davies帮助我们修复语言错误。我们还要感谢Andrei Robachevsky、Ulrich Herberg、Thomas Clausen、Bruce Nordman、Alissa Cooper、Dave Thaler、Bernard Aboba和Henning Schulzrinne的评论意见。
Additionally, we would like to thank Ericsson and Nokia Siemens Networks for their financial support.
此外，我们还要感谢爱立信和诺基亚西门子网络公司的财务支持。
[AES] Wikipedia, "Advanced Encryption Standard", December 2011, <http://en.wikipedia.org/w/ index.php?title=Advanced_Encryption_Standard& oldid=481153988>.
[AES]维基百科，“高级加密标准”，2011年12月<http://en.wikipedia.org/w/ index.php？title=Advanced\u Encryption\u Standard&oldid=481153988>。
[CFRG] McGrew (Chair), D., "IRTF Crypto Forum Research Group (CFRG)", June 2011, <http://irtf.org/cfrg>.
[CFRG]McGrew（主席），D.，“IRTF加密论坛研究小组（CFRG）”，2011年6月<http://irtf.org/cfrg>.
[Clausen] Clausen, T. and U. Herberg, "Some Considerations on Routing in Particular and Lossy Environments", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, March 2011, <http://www.iab.org/wp-content/IAB-uploads/ 2011/03/Herberg.pdf>.
[Clausen]Clausen，T.和U.Herberg，“特定和有损环境中路由的一些考虑”，IAB智能对象与互联网互连研讨会，捷克共和国布拉格，2011年3月<http://www.iab.org/wp-content/IAB-uploads/ 2011/03/Herberg.pdf>。
[CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", Work in Progress, October 2011.
[CoAP]Shelby，Z.，Hartke，K.，Bormann，C.，和B.Frank，“受限应用协议（CoAP）”，正在进行的工作，2011年10月。
[CoAP-CC] Eggert, L., "Congestion Control for the Constrained Application Protocol (CoAP)", Work in Progress, January 2011.
[CoAP CC]Eggert，L.，“受限应用协议（CoAP）的拥塞控制”，正在进行的工作，2011年1月。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, December 2011.
[DNS-SD]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，正在进行的工作，2011年12月。
[Dolin] Dolin, B., "Application Communications Requirements for 'The Internet of Things'", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, March 2011, <http://www.iab.org/ wp-content/IAB-uploads/2011/03/Dolin.pdf>.
[Dolin]Dolin，B.，“物联网的应用通信要求”，IAB智能对象与互联网互联研讨会，捷克共和国布拉格，2011年3月<http://www.iab.org/ wp content/IAB uploads/2011/03/Dolin.pdf>。
[ECC] Wikipedia, "Elliptic Curve Cryptography", December 2011, <http://en.wikipedia.org/w/ index.php?title=Elliptic_curve_cryptography& oldid=480053167>.
[ECC]维基百科，“椭圆曲线密码术”，2011年12月<http://en.wikipedia.org/w/ index.php？title=椭圆曲线加密&oldid=480053167>。
[ENERGY-PRICING] Jennings, C. and B. Nordman, "Communication of Energy Price Information", Work in Progress, July 2011.
[能源定价]Jennings，C.和B.Nordman，“能源价格信息的沟通”，正在进行的工作，2011年7月。
[ENROLL] "The ietf-enroll Archives", <http://mailman.mit.edu/pipermail/ietf-enroll/>.
[注册]“ietf注册档案”<http://mailman.mit.edu/pipermail/ietf-enroll/>.
[Ersue] Ersue, M. and J. Korhonen, "Position Paper on 'Interconnecting Smart Objects with the Internet'", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, February 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/03/ Ersue.pdf>.
[Ersue]Ersue，M.和J.Korhonen，“关于“智能对象与互联网互联”的立场文件”，IAB智能对象与互联网互联研讨会，捷克共和国布拉格，2011年2月<http://www.iab.org/wp-content/IAB-uploads/2011/03/ Ersue.pdf>。
[GEOPRIV] IETF, "Geographic Location/Privacy (geopriv) Working Group", <http://datatracker.ietf.org/wg/geopriv/>.
[GEOPRIV]IETF，“地理位置/隐私（GEOPRIV）工作组”<http://datatracker.ietf.org/wg/geopriv/>.
[HOMENET] "Home Networking (homenet) Working Group", <http://datatracker.ietf.org/wg/homenet>.
[HOMENET]“家庭网络（HOMENET）工作组”<http://datatracker.ietf.org/wg/homenet>.
[IoT-ARCH] Hui, J. and J. Vasseur, "Routing Architecture in Low-Power and Lossy Networks (LLNs)", Work in Progress, March 2011.
[IoT ARCH]Hui，J.和J.Vasseur，“低功耗和有损网络（LLN）中的路由架构”，正在进行的工作，2011年3月。
[LWIG] IETF, "Light-Weight Implementation Guidance (lwig) Working Group", June 2011, <http://datatracker.ietf.org/wg/lwig/charter/>.
[LWIG]IETF，“轻型实施指南（LWIG）工作组”，2011年6月<http://datatracker.ietf.org/wg/lwig/charter/>.
[MINIMAL-IKEv2] Kivinen, T., "Minimal IKEv2", Work in Progress, February 2011.
[MINIMAL-IKEv2]Kivinen，T.，“MINIMAL-IKEv2”，正在进行的工作，2011年2月。
[PROT-SURVEY] Tavakoli, A., Dawson-Haggerty, S., and P. Levis, "Overview of Existing Routing Protocols for Low Power and Lossy Networks", Work in Progress, April 2009.
[PROT-SURVEY]Tavakoli，A.，Dawson Haggerty，S.，和P.Levis，“低功耗和有损网络的现有路由协议概述”，正在进行的工作，2009年4月。
[RECIPE] "Reducing Energy Consumption with Internet Protocols Exploration (RECIPE) Mailing List", <https://www.ietf.org/mailman/listinfo/recipe>.
[配方]“通过互联网协议探索（配方）邮件列表降低能耗”<https://www.ietf.org/mailman/listinfo/recipe>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[RFC3561]Perkins，C.，Belding Royer，E.，和S.Das，“临时按需距离向量（AODV）路由”，RFC 3561，2003年7月。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101]Rescorla，E.和IAB，“编写协议模型”，RFC 41012005年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007.
[RFC4806]Myers，M.和H.Tschofenig，“IKEv2的在线证书状态协议（OCSP）扩展”，RFC 4806，2007年2月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903]Thaler，D.，“多链路子网问题”，RFC 49032007年6月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191]Forsberg，D.，Ohba，Y.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 51912008年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548]Dohler，M.，Watteyne，T.，Winter，T.，和D.Barthel，“城市低功率和有损网络的路由要求”，RFC 5548，2009年5月。
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673]Pister，K.，Thubert，P.，Dwars，S.，和T.Phinney，“低功率和有损网络中的工业路由要求”，RFC 5673，2009年10月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826]Brandt，A.，Buron，J.，和G.Porcu，“低功率和有损网络中的家庭自动化路由要求”，RFC 5826，2010年4月。
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867]Martocci，J.，De Mil，P.，Riou，N.，和W.Vermeylen，“低功率和有损网络中的楼宇自动化路由要求”，RFC 58672010年6月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 60592010年11月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121]圣安德烈，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC61212011年3月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]Enns，R.，Bjorklund，M.，Schoenwaeld，J.，和A.Bierman，“网络配置协议（NETCONF）”，RFC 62412011年6月。
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011.
[RFC6272]Baker，F.和D.Meyer，“智能电网的互联网协议”，RFC 62722011年6月。
[RPL] Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. Winter, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", Work in Progress, March 2011.
[RPL]Brandt，A.，Vasseur，J.，Hui，J.，Pister，K.，Thubert，P.，Levis，P.，Struik，R.，Kelsey，R.，Clausen，T.，和T.Winter，“RPL：低功耗和有损网络的IPv6路由协议”，正在进行的工作，2011年3月。
[SHA3] NIST, "Cryptographic Hash Algorithm Competition", December 2010, <http://csrc.nist.gov/groups/ST/ hash/sha-3/index.html>.
[SHA3]NIST，“加密哈希算法竞赛”，2010年12月<http://csrc.nist.gov/groups/ST/ hash/sha-3/index.html>。
[SNMP-OPT] Schoenwaelder, J., Mukhtar, H., Joo, S., and K. Kim, "SNMP Optimizations for Constrained Devices", Work in Progress, October 2010.
[SNMP-OPT]Schoenwaeld，J.，Mukhtar，H.，Joo，S.，和K.Kim，“受约束设备的SNMP优化”，正在进行的工作，2010年10月。
[Schoenwaelder] Schoenwaelder, J., Tsou, T., and B. Sarikaya, "Protocol Profiles for Constrained Devices", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, February 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/03/ Schoenwaelder.pdf>.
[Schoenwaeld]Schoenwaeld，J.，Tsou，T.，和B.Sarikaya，“受约束设备的协议配置文件”，IAB智能对象与互联网互连研讨会，捷克共和国布拉格，2011年2月<http://www.iab.org/wp-content/IAB-uploads/2011/03/ Schoenwaeld.pdf>。
[SmartGrid] Wikipedia, "Smart Grid", December 2011, <http://en.wikipedia.org/w/ index.php?title=Smart_grid&oldid=479750548>.
[智能电网]维基百科，“智能电网”，2011年12月<http://en.wikipedia.org/w/ index.php？title=Smart\u grid&oldid=479750548>。
[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", In Proc. ACM SIGCOMM, 2002, <http://conferences.sigcomm.org/sigcomm/2002/ papers/tussle.html>.
克拉克，D.，沃克罗夫斯基，J.，索林斯，K.，和R.布拉登，“网络空间中的争斗：定义明天的互联网”，在Proc。ACM SIGCOMM，2002年<http://conferences.sigcomm.org/sigcomm/2002/ 文件/tussle.html>。
[Wasserman] Wasserman, M., "It's Not Easy Being 'Green'", IAB Interconnecting Smart Objects with the Internet Workshop, Prague, Czech Republic, March 2011, <http://www.iab.org/wp-content/IAB-uploads/2011/03/ Wasserman.pdf>.
[Wasserman]Wasserman，M.，“绿色并不容易”，IAB智能对象与互联网互联研讨会，捷克共和国布拉格，2011年3月<http://www.iab.org/wp-content/IAB-uploads/2011/03/ Wasserman.pdf>。
[irtf-discuss] Ohlman, B., "Draft ICN RG Charter", message to IRTF DISCUSS Mailing List, May 2011, <http://www.ietf.org/mail-archive/web/irtf-discuss/ current/msg00041.html>.
[irtf讨论]Ohlman，B.，“ICN RG章程草案”，致irtf讨论邮件列表的信息，2011年5月<http://www.ietf.org/mail-archive/web/irtf-discuss/ 当前/msg00041.html>。
[proxZzzy] ECMA, "proxZzzy(TM) for sleeping hosts", Standard ECMA-393, February 2010, <http://www.ecma-international.org/publications/ standards/Ecma-393.htm>.
[Proxzzy]ECMA，“睡眠主机的Proxzzy（TM）”，标准ECMA-393，2010年2月<http://www.ecma-international.org/publications/ 标准/Ecma-393.htm>。
The following persons are responsible for the organization of the associated workshop and are responsible also for this event: Jari Arkko, Hannes Tschofenig, Bernard Aboba, Carsten Bormann, David Culler, Lars Eggert, JP. Vasseur, Stewart Bryant, Adrian Farrel, Ralph Droms, Geoffrey Mulligan, Alexey Melnikov, Peter Saint-Andre, Marcelo Bagnulo, Zach Shelby, Isidro Ballesteros Laso, Fred Baker, Cullen Jennings, Manfred Hauswirth, and Lukas Kencl.
以下人员负责相关研讨会的组织，也负责本次活动：Jari Arkko、Hannes Tschofenig、Bernard Aboba、Carsten Bormann、David Culler、Lars Eggert，JP。瓦修尔、斯图尔特·布莱恩特、阿德里安·法雷尔、拉尔夫·德罗姆斯、杰弗里·穆利根、阿列克谢·梅尔尼科夫、彼得·圣安德烈、马塞洛·巴格鲁、扎克·谢尔比、伊西德罗·巴列斯特罗斯·拉索、弗雷德·贝克、卡伦·詹宁斯、曼弗雷德·豪斯沃思和卢卡斯·肯克尔。
Main page:
http://www.iab.org/about/workshops/smartobjects/
Main page:
http://www.iab.org/about/workshops/smartobjects/
Position papers:
http://www.iab.org/about/workshops/smartobjects/papers/
Position papers:
http://www.iab.org/about/workshops/smartobjects/papers/
Slides:
http://www.iab.org/about/workshops/smartobjects/agenda/
Slides:
http://www.iab.org/about/workshops/smartobjects/agenda/
Minutes:
http://www.iab.org/activities/workshops/smartobjects/
smartobjectworkshopmeetingminutes/
Minutes:
http://www.iab.org/activities/workshops/smartobjects/
smartobjectworkshopmeetingminutes/
1. Deployment Experience with Low Power Lossy Wireless Sensor Networks" by C. Adjih, E. Baccelli, P. Jacquet, P. Minet, M. Philipp, and G. Wittenburg
1. C.Adjih、E.Baccelli、P.Jacquet、P.Minet、M.Philipp和G.Wittenburg的《低功耗无线传感器网络部署经验》
2. CoAP improvements to meet embedded device hardware constraints" by Davide Barbieri
2. CoAP改进，以满足Davide Barbieri的“嵌入式设备硬件约束”
3. "Unified Device Networking Protocols for Smart Objects" by Daniel Barisic and Anton Pfefferseder
3. Daniel Barisic和Anton Pfefferseder的“智能对象的统一设备网络协议”
4. "Simplified neighbour cache implementation in RPL/6LoWPAN" by Dominique Barthel
4. Dominique Barthel的“RPL/6LoWPAN中的简化邻居缓存实现”
5. "Home Control in a consumer's perspective" by Anders Brandt
5. Anders Brandt的“消费者视角下的家庭控制”
6. "Authoring Place-based Experiences with an Internet of Things: Tussles of Expressive, Operational, and Participatory Goals" by Jeff Burke
6. Jeff Burke的“利用物联网创作基于地点的体验：表达性、操作性和参与性目标之争”
7. "A Dynamic Distributed Federated Approach for the Internet of Things" by Diego Casado Mansilla, Juan Ramon Velasco Perez, and Mario Lopez-Ramos
7. Diego Casado Mansilla、Juan Ramon Velasco Perez和Mario Lopez Ramos合著的《物联网的动态分布式联邦方法》
8. "Quickly interoperable Internet of Things using simple transparent gateways" by Angelo P. Castellani, Salvatore Loreto, Nicola Bui, and Michele Zorzi
8. Angelo P.Castellani、Salvatore Loreto、Nicola Bui和Michele Zorzi的“使用简单透明网关的快速互操作物联网”
9. "Position Paper of the Brno University of Technology Department of Telecommunications" by Vladimir Cervenka, Lubomir Mraz, Milan Simek, and Karel Pavlata
9. Vladimir Cervenka、Lubomir Mraz、米兰西梅克、Karel Pavlata《布尔诺科技大学电信系立场文件》
10. "Secure Access to IOT Network: An Application-based Group Key Approach" by Samita Chakrabarti and Wassim Haddad
10. Samita Chakrabarti和Wassim Haddad的“物联网安全接入：基于应用程序的组密钥方法”
11. "Domain-Insulated Autonomous Network Architecture (DIANA)" by W. Chun
11. “域绝缘自治网络架构（DIANA）”，作者：W.Chun
12. "Yet Another Definition on Name, Address, ID, and Locator (YANAIL)" by W. Chun
12. “关于姓名、地址、ID和定位符（YANAIL）的另一个定义”，W.Chun
13. "The Challenge of Mobility in Low Power Networks" by E. Davies
13. E.Davies的“低功率网络中的移动性挑战”
14. "If the routing protocol is so smart, why should neighbour discovery be so dumb?" by Nicolas Dejean
14. Nicolas Dejean说：“如果路由协议如此智能，为什么邻居发现会如此愚蠢？”
15. "Making Smart Objects IPv6 Ready: Where are we?" by M. Durvy and M. Valente
15. M.Durvy和M.Valente的《让智能对象做好IPv6准备：我们在哪里？》
16. "Position Paper on 'Interconnecting Smart Objects with the Internet'" by Mehmet Ersue and Jouni Korhonen
16. Mehmet Ersue和Jouni Korhonen撰写的《关于“智能对象与互联网互联”的立场文件》
17. "The Real-time Enterprise: IoT-enabled Business Processes" by Stephan Haller and Carsten Magerkurth
17. Stephan Haller和Carsten Magerkurth的“实时企业：物联网支持的业务流程”
18. "Making Internet-Connected Objects readily useful" by Manfred Hauswirth, Dennis Pfisterer, and Stefan Decker
18. Manfred Hauswirth、Dennis Pfister和Stefan Decker的“让互联网连接的对象变得更有用”
19. "Some Considerations on Routing in Particular and Lossy Environments" by Thomas Clausen and Ulrich Herberg
19. Thomas Clausen和Ulrich Herberg的“特殊和有损环境中路由的一些考虑”
20. "A Security Protocol Adaptation Layer for the IP-based Internet of Things" by Rene Hummen, Tobias Heer, and Klaus Wehrle
20. Rene Hummen、Tobias Heer和Klaus Wehrle的“基于IP的物联网的安全协议适配层”
21. "Simplified SIP Approach for the Smart Object" by Ryota Ishibashi, Takumi Ohba, Arata Koike, and Akira Kurokawa
21. 石桥良田、大叶拓美、小池Arata和黑川昭一的“智能对象的简化SIP方法”
22. "Mobility support for the small and smart Future Internet devices" by Antonio J. Jara and Antonio F. G. Skarmeta
22. Antonio J.Jara和Antonio F.G.Skarmeta合著的“为小型智能未来互联网设备提供移动支持”
23. "The Need for Efficient Reliable Multicast in Smart Grid Networks" by J. Jetcheva, D. Popa, M.G. Stuber, and H. Van Wyk
23. J.Jetcheva、D.Popa、M.G.Stuber和H.Van Wyk的《智能电网网络中高效可靠组播的需求》
24. "Lightweight Cryptography for the Internet of Things" by Masanobu Katagi and Shiho Moriai
24. Masanobu Katagi和Shiho Morai的“物联网轻量级加密”
25. "Thoughts on Reliability in the Internet of Things" by James Kempf, Jari Arkko, Neda Beheshti, and Kiran Yedavalli
25. 詹姆斯·肯普夫、贾里·阿尔科、内达·贝赫什蒂和基兰·耶达瓦利的《关于物联网可靠性的思考》
26. "IKEv2 and Smart Objects" by Tero Kivinen
26. Tero Kivinen的“IKEv2和智能对象”
27. "Position Paper on Thing Name Service (TNS) for the Internet of Things (IoT)" by Ning Kong and Shuo Shen
27. “物联网（IoT）物名服务（TNS）的立场文件”，由Ning Kong和Shuo Shen撰写
28. "Connecting Smart Objects to Wireless WANs" by Suresh Krishnan
28. Suresh Krishnan的“将智能对象连接到无线WAN”
29. "Towards an Information-Centric Internet with more Things" by D. Kutscher and S. Farrell
29. D.Kutscher和S.Farrell的《走向以信息为中心、拥有更多东西的互联网》
30. "Application of 6LoWPAN for the Real-Time Positioning of Manufacturing Assets" by Jaacan Martinez and Jose L. M. Lastra
30. Jaacan Martinez和Jose L.M.Lastra的“6LoWPAN在制造业资产实时定位中的应用”
31. "Lighting interface to wireless network" by Jaroslav Meduna
31. Jaroslav Meduna的“无线网络照明接口”
32. "Social-driven Internet of Connected Objects" by Paulo Mendes
32. Paulo Mendes的“社交驱动的互联对象互联网”
33. "Protocols should go forward that are required by non IP based protocols" by Tsuyoshi Momose
33. Tsuyoshi Momose的“非基于IP的协议所需的协议应向前发展”
34. "Web services for Wireless Sensor and Actuator Networks" by Guido Moritz
34. Guido Moritz的“无线传感器和执行器网络的Web服务”
35. "Connecting BT-LE sensors to the Internet using Ipv6" by Markus Isomaki, Kanji Kerai, Jari Mutikainen, Johanna Nieminen, Basavaraj Patil, Teemu Savolainen, and Zach Shelby
35. Markus Isomaki、Kanji Kerai、Jari Mutikainen、Johanna Nieminen、Basavaraj Patil、Teemu Savolainen和Zach Shelby的“使用Ipv6将BT-LE传感器连接到互联网”
36. "Building Networks" by Bruce Nordman
36. 布鲁斯·诺德曼的《构建网络》
37. "Issues and Challenges in Provisioning Keys to Smart Objects" by Yoshihiro Ohba and Subir Das
37. Yoshihiro Ohba和Subir Das的“为智能对象提供密钥的问题和挑战”
38. "Challenges and Solutions of Secure Smart Environments" by Eila Ovaska and Antti Evesti
38. Eila Ovaska和Antti Evesti的“安全智能环境的挑战和解决方案”
39. "Research Experiences about Internetworking Mechanisms to Integrate Embedded Wireless Networks into Traditional Networks" by Jose F. Martinez, Ivan Corredor, and Miguel S. Familiar
39. Jose F.Martinez、Ivan Corredor和Miguel S.Knowner的“关于将嵌入式无线网络集成到传统网络中的互联机制的研究经验”
40. "Scalable Video Coding in Networked Environment" by Naeem Ramzan, Tomas Piatrik, and Ebroul Izquierdo
40. Naeem Ramzan、Tomas Piatrik和Ebroul Izquierdo的“网络环境中的可伸缩视频编码”
41. "Challenges in Opportunistic Networking" by Mikko Pitkaenen and Teemu Kaerkkaeinen
41. Mikko Pitkaenen和Teemu Kaerkkaeinn的《机会主义网络的挑战》
42. "Position Statement" by Neeli R. Prasad and Sateesh Addepalli
42. Neeli R.Prasad和Sateesh Addepalli的“立场声明”
43. "A Gateway Architecture for Interconnecting Smart Objects to the Internet" by Akbar Rahman, Dorothy Gellert, Dale Seed
43. Akbar Rahman、Dorothy Gellert、Dale Seed的《智能对象与互联网互联的网关体系结构》
44. "Routing Challenges and Directions for Smart Objects in Future Internet of Things" by T. A. Ramrekha, E. Panaousis, and C. Politis
44. T.A.Ramrekha、E.Panaousis和C.Politis的“未来物联网中智能对象的路由挑战和方向”
45. "6LoWPAN Extension for IPsec" by Shahid Raza, Thiemo Voigt, and Utz Roedig
45. Shahid Raza、Thiemo Voigt和Utz Roedig的“IPsec的6LoWPAN扩展”
46. "Connected Vehicle as Smart Object(s)" by Ryuji Wakikawa
46. 由Ryuji Wakikawa编写的“作为智能对象的连接车辆”
47. "Problem and possible approach of development and operation of Smart Objects" by Shoichi Sakane
47. Sakane Shoichi的“智能对象开发和运行的问题和可能途径”
48. "Connecting Passive RFID Tags to the Internet of Things" by Sandra Dominikus and Joern-Marc Schmidt
48. Sandra Dominikus和Joern Marc Schmidt的“将无源RFID标签连接到物联网”
49. "Protocol Profiles for Constrained Devices" by Juergen Schoenwaelde, Tina Tsou, and Behcet Sarikaya
49. Juergen Schoenwaelde、Tina Tsou和Behcet Sarikaya的“受限设备的协议配置文件”
50. "Multihoming for Sensor Networks" by J. Soininen
50. J.Soininen的“传感器网络的多宿”
51. "Internet Objects for Building Control" by Peter van der Stok and Nicolas Riou
51. Peter van der Stok和Nicolas Riou的“用于楼宇控制的互联网对象”
52. "Optimal information placement for Smart Objects" by Shigeya Suzuki
52. Shigeya Suzuki的“智能对象的最佳信息放置”
53. "Multi-National Initiative for Cloud Computing in Health Care (MUNICH)" by Christoph Thuemmler
53. Christoph Thuemmler的“医疗云计算多国倡议（慕尼黑）”
54. "The time of the hourglass has elapsed" by Laurent Toutain, Nicolas Montavont, and Dominique Barthel
54. 洛朗·图坦、尼古拉斯·蒙塔冯和多米尼克·巴塞尔的《沙漏时代已经过去》
55. "Sensor and Actuator Resource Architecture" by Vlasios Tsiatsis, Jan Hoeller, and Richard Gold
55. Vlasios Tsiasis、Jan Hoeller和Richard Gold的“传感器和执行器资源架构”
56. "IT'S NOT EASY BEING 'GREEN'" by Margaret Wasserman
56. 玛格丽特·沃瑟曼的《做‘绿色’并不容易》
57. "Trustworthy Wireless Industrial Sensor Networks" by Markus Wehner, Thomas Bartzsch, Dirk Burggraf, Sven Zeisberg, Alexis Olivereau, and Oualha Nouha
57. Markus Wehner、Thomas Bartzsch、Dirk Burggraf、Sven Zeisberg、Alexis Olivereau和Oualha Nouha的“可靠的无线工业传感器网络”
58. "Interconnecting smart objects through an overlay networking architecture" by Anastasios Zafeiropoulos, Athanassios Liakopoulos and Panagiotis Gouvas
58. Anastasios Zafeiropoulos、Athanasios Liakopoulos和Panagiotis Gouvas的“通过覆盖网络架构互连智能对象”
59. "Building trust among Virtual Interconnecting Smart Objects in the Future Internet" by Theodore Zahariadic, Helen C. Leligou, Panagiotis Trakadas, and Mischa Dohler
59. Theodore Zahariadic、Helen C.Leligou、Panagiotis Trakadas和Misha Dohler的《在未来互联网中建立虚拟互联智能对象之间的信任》
60. "Experience and Challenges of Integrating Smart Devices with the Mobile Internet" by Zhen Cao and Hui Deng
60. 曹震和邓辉的“智能设备与移动互联网整合的经验和挑战”
61. "The 'mesh-under' versus 'route over' debate in IP Smart Objects Networks" by JP. Vasseur and Jonathan Hui
61. JP的“IP智能对象网络中的“网格下”与“路由上”之争”。华硕与许宗仁
62. "Identification and Authentication of IoT Devices" by Alper Yegin
62. Alper Yegin的“物联网设备的识别和认证”
63. "Security Challenges For the Internet of Things" by Tim Polk and Sean Turner
63. Tim Polk和Sean Turner的“物联网的安全挑战”
64. "Application Communications Requirements for 'The Internet of Things'" by Bob Dolin
64. Bob Dolin的《物联网的应用通信要求》
65. "Interoperability Concerns in the Internet of Things" by Jari Arkko
65. Jari Arkko的“物联网中的互操作性问题”
66. "Privacy in Ubiquitous Computing" by Ivan Gudymenko and Katrin Borcea-Pfitzmann
66. Ivan Gudymenko和Katrin Borcea Pfizmann的“普适计算中的隐私”
67. "The 10 Laws of Smart Object Security Design" by Hannes Tschofenig and Bernard Aboba
67. Hannes Tschofenig和Bernard Aboba的“智能对象安全设计的十大法则”
68. "Position Paper on 'In-Network Object Cloud' Architecture and Design Goals" by Alex Galis and Stuart Clayman
68. Alex Galis和Stuart Clayman撰写的“关于“网络对象云”架构和设计目标的立场文件”
69. "Temptations and Difficulties of Protocols for Smart Objects and the Internet" by Alexandru Petrescu
69. Alexandru Petrescu的“智能对象和互联网协议的诱惑和困难”
70. "The Internet of Things - Challenge for a New Architecture from Problems" by Gyu Myoung Lee and Noel Crespi
70. 由Gyu Myoung Lee和Noel Crespi撰写的“物联网-从问题中挑战新架构”
71. "Garrulity and Fluff" by Carsten Bormann and Klaus Hartke
71. 卡斯滕·鲍曼和克劳斯·哈特克的《絮絮叨叨与蓬松》
We would like to than the following workshop participants for attending the workshop:
我们非常感谢以下研讨会参与者参加研讨会：
Adrian Farrel Akbar Rahman Alissa Cooper Alper Yegin Anastasios Zafeiropoulos Anders Brandt Angelo P. Castellani Antonio F. G. Skarmeta Antonio Jara Arvind Ramrekha Behcet Sarikaya Bernard Aboba Bruce Nordman Carsten Bormann Cullen Jennings Daniel Barisic Dave Thaler Davide Barbieri Diego Casado Mansilla Dirk Kutscher Dominique Barthel Dorothy Gellert Elwyn Davis Emmanuel Baccelli Fred Baker Guido Moritz Gyu Myoung Lee Hannes Tschofenig Hui Deng Ivan Gudymenko Jaacan Martinez Jari Arkko Jaroslav Meduna Jeff Burke Johanna Nieminen Jonathan Hui Jonne Soininen Jouni Korhonen
阿德里安·法雷尔·阿克巴尔·拉赫曼·阿里萨·库珀·阿尔卑斯·耶金·阿纳斯塔西奥斯·扎菲洛普洛斯·安德斯·布兰德·安杰洛·P·卡斯特拉尼·安东尼奥·F·G·斯卡梅塔·安东尼奥·贾拉·阿文德·拉姆雷卡·贝塞特·萨里卡亚·伯纳·阿博巴·布鲁斯·诺德曼·卡斯滕·鲍曼·库伦·詹宁斯·丹尼尔·巴里西克·戴夫·塔勒·大卫·大卫·巴比里·迭戈·卡萨多·曼西Gellert Elwyn Davis Emmanuel Baccelli Fred Baker Guido Moritz Gyu Myoung Lee Hannes Tschofening Hui Deng Ivan Gudymenko Jaacan Martinez Jari Arkko Jaroslav Meduna Jeff Burke Johanna Nieminen Jonathan Hui Jonne Soininen Journi Journi Korhonen
JP. Vasseur Karel Pavlata Klaus Hartke Lars Eggert Laura Gheorghe Laurent Toutain Lukas Kencl Marcelo Bagnulo Marco Valente Margaret Wasserman Markus Isomaki Markus Wehner Masanobu Katagi Mathilde Durvy Mehmet Ersue Mikko Pitkaenen Milan Simek Neeli R. Prasad Nicolas Dejean Ning Kong Pascal Thubert Paulo Mendes Pete Resnick Peter van der Stok Ralph Droms Rene Hummen Ross Callon Ruediger Martin Russ Housley Ryota Ishibashi Ryuji Wakikawa Samita Chakrabarti Sandra Dominikus Sean Shen Sean Turner Shahid Raza Shoichi Sakane Spencer Dawkins Stephan Haller Stephen Farrell Stewart Bryant Subir Das Suresh Krishnan Tea Sang Choi Tero Kivinen Theodore Zahariadis Thomas Clausen Tim Polk
JP。瓦瑟尔·卡雷尔·帕夫拉塔·克劳斯·哈特克·拉尔斯·艾格特·劳拉·盖奥格·洛朗·图坦·卢卡斯·肯克尔·马塞洛·巴格努洛·马可·瓦伦特·瓦瑟曼·马库斯·伊索马基·马库斯·韦纳·马萨诺布·卡塔吉·马蒂尔德·杜维·梅米特·米科·皮特卡恩·尼利·普拉萨德·尼古拉·德让·宁·帕斯卡尔·图伯特·保罗·门德斯·雷斯尼克·彼得·范德斯托克·拉尔夫Droms Rene Hummen Ross Callon Ruediger Martin Russ Housley Ryota Ishibashi Ryuji Wakikawa Samita Chakrabarti Sandra Dominikus Sean Shen Sean Turner Shahid Raza Shoichi Sakane Spencer Dawkins Stephen Haller Stephen Farrell Stewart Bryant Subir Das Suresh Krishna Tea Sang Choi Tero Kivinen Theodore Zahariadis Thomas Clausen Tim Polk
Tina Tsou Tsuyoshi Momose Vladimir Cervenka Wassim Haddad Woojik Chun Zach Shelby
Tina Tsou Tsuyoshi Momose Vladimir Cervenka Wassim Haddad Woojik Chun Zach Shelby
Bernard Aboba Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Olaf Kolkman Danny McPherson Jon Peterson Andrei Robachevsky Dave Thaler Hannes Tschofenig
伯纳德·阿博巴·罗斯·卡隆·艾莉莎·库珀·斯宾塞·道金斯·乔尔·哈尔佩恩·鲁斯·霍斯利·大卫·凯森斯·奥拉夫·科尔克曼·丹尼·麦克弗森·乔恩·彼得森·安德烈·罗巴切夫斯基·戴夫·泰勒·汉内斯·茨霍芬尼
Authors' Addresses
作者地址
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Internet Architecture Board
互联网架构委员会
EMail: iab@iab.org
EMail: iab@iab.org