draft-iab-smart-object-workshop-05.txt   draft-iab-smart-object-workshop-06.txt 
Network Working Group H. Tschofenig Network Working Group H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Informational J. Arkko Intended status: Informational J. Arkko
Expires: April 26, 2012 Ericsson Expires: April 28, 2012 Ericsson
October 24, 2011 October 26, 2011
Report from the 'Interconnecting Smart Objects with the Internet' Report from the 'Interconnecting Smart Objects with the Internet'
Workshop, 25th March 2011, Prague Workshop, 25th March 2011, Prague
draft-iab-smart-object-workshop-05.txt draft-iab-smart-object-workshop-06.txt
Abstract Abstract
This document provides an overview of a workshop held by the Internet This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on 'Interconnecting Smart Objects with the Architecture Board (IAB) on 'Interconnecting Smart Objects with the
Internet'. The workshop took place in Prague on March, 25th. The Internet'. The workshop took place in Prague on March, 25th. The
main goal of the workshop was to solicit feedback from the wider main goal of the workshop was to solicit feedback from the wider
community on their experience with deploying IETF protocols in community on their experience with deploying IETF protocols in
constrained environments. This report summarizes the discussions and constrained environments. This report summarizes the discussions and
lists the conclusions and recommendations to the Internet Engineering lists the conclusions and recommendations to the Internet Engineering
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012. This Internet-Draft will expire on April 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 6 2. Constrained Nodes and Networks . . . . . . . . . . . . . . . . 6
3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 8 3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 8 3.1.1. One Internet vs. Islands . . . . . . . . . . . . . . . 8
3.1.2. Domain Specific Stacks and Profiles . . . . . . . . . 9 3.1.2. Domain Specific Stacks and Profiles . . . . . . . . . 9
3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Which Layer? . . . . . . . . . . . . . . . . . . . . . 10
3.2. Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Sleep Modes . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 18 4. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Informative References . . . . . . . . . . . . . . . . . . . . 25 8. Informative References . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 29 Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 29
Appendix B. Published Workshop Material . . . . . . . . . . . . . 30 Appendix B. Published Workshop Material . . . . . . . . . . . . . 30
Appendix C. Workshop Participants . . . . . . . . . . . . . . . . 35 Appendix C. Workshop Participants . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
skipping to change at page 3, line 19 skipping to change at page 3, line 19
Internet, and to suggest future directions for the Internet Internet, and to suggest future directions for the Internet
architecture. This long-term planning function of the IAB is architecture. This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working complementary to the ongoing engineering efforts performed by working
groups of the Internet Engineering Task Force (IETF), under the groups of the Internet Engineering Task Force (IETF), under the
leadership of the Internet Engineering Steering Group (IESG) and area leadership of the Internet Engineering Steering Group (IESG) and area
directorates. directorates.
Today's Internet is experienced by users as a set of applications, Today's Internet is experienced by users as a set of applications,
such as email, instant messaging, and services on the Web. While such as email, instant messaging, and services on the Web. While
these applications do not require users to be present at the time of these applications do not require users to be present at the time of
service execution in many cases they are. There are also substantial service execution, in many cases they are. There are also
differences in performance among the various end devices, but in substantial differences in performance among the various end devices,
general end devices participating in the Internet are considered to but in general end devices participating in the Internet are
have high performance. considered to have high performance.
There are, however, a large number of deployed embedded devices and There are, however, a large number of deployed embedded devices and
there is substantial value in interconnecting them with the Internet. there is substantial value in interconnecting them with the Internet.
The term "Internet of Things" denotes a trend where a large number of The term "Internet of Things" denotes a trend where a large number of
devices employ communication services offered by the Internet devices employ communication services offered by the Internet
Protocols. Many of these devices are not directly operated by Protocols. Many of these devices are not directly operated by
humans, but exist as components in buildings, vehicles, and the humans, but exist as components in buildings, vehicles, and the
environment. There is a large variation in the computing power, environment. There is a large variation in the computing power,
available memory, (electrical) power, and communications bandwidth available memory, (electrical) power, and communications bandwidth
between different types of devices. between different types of devices.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
often offer a web interface to the end user. In many cases the new, often offer a web interface to the end user. In many cases the new,
constrained environments can benefit from additional protocols and constrained environments can benefit from additional protocols and
protocol extensions that help optimize the communications and lower protocol extensions that help optimize the communications and lower
the computational requirements. Examples of currently ongoing the computational requirements. Examples of currently ongoing
standardization efforts targeted for these environments include the standardization efforts targeted for these environments include the
"Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN "Constrained RESTful Environments (CoRE)", "IPv6 over Low power WPAN
(6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and (6LoWPAN)", "Routing Over Low power and Lossy networks (ROLL)", and
the "Light-Weight Implementation Guidance (LWIG)" working groups at the "Light-Weight Implementation Guidance (LWIG)" working groups at
the IETF. the IETF.
This workshop explored the experiences of researchers and developers, This workshop explored the experiences of researchers and developers
when considering the characteristics of constrained devices. when considering the characteristics of constrained devices.
Engineers know that many design considerations need to be taken into Engineers know that many design considerations need to be taken into
account when developing protocols and architecture. Balancing account when developing protocols and architecture. Balancing
between the conflicting goals of code size, economical incentives, between the conflicting goals of code size, economic incentives,
power consumption, usability and security is often difficult, as power consumption, usability and security is often difficult, as
illustrated by Clark, et al. in "Tussle in Cyberspace: Defining illustrated by Clark, et al. in "Tussle in Cyberspace: Defining
Tomorrow's Internet". Tomorrow's Internet".
Participants at the workshop discussed the experience and approaches Participants at the workshop discussed the experience and approaches
taken when designing protocols and architectures for interconnecting taken when designing protocols and architectures for interconnecting
smart objects to the Internet. The scope of the investigations smart objects to the Internet. The scope of the investigations
included constrained nodes as well as constrained networks. included constrained nodes as well as constrained networks.
The call for position paper suggested investigating the area of The call for position papers suggested investigating the area of
integration with the Internet in the following categories: integration with the Internet in the following categories:
o Scalability o Scalability
o Power efficiency o Power efficiency
o Interworking between different technologies and network domains o Interworking between different technologies and network domains
o Usability and manageability o Usability and manageability
o Security and Privacy o Security and Privacy
The goals of the workshop can be summarized as follows: The goals of the workshop can be summarized as follows:
As many deployed smart objects demonstrate running protocols, like As many deployed smart objects demonstrate, running protocols like
IP, TCP, UDP, HTTP, etc., on constrained devices is clearly is IP, TCP, UDP, HTTP, etc., on constrained devices is clearly
possible. Still, protocol designers, system architects and possible. Still, protocol designers, system architects and
developers have to keep various limitations in mind. The developers have to keep various limitations in mind. The
organizers were interested to discuss the experience with organizers were interested to discuss the experience with
deploying IETF protocols in different constrained environments. deploying IETF protocols in different constrained environments.
Furthermore, the organizers were seeking to identify either issues Furthermore, the organizers were seeking to identify either issues
where current implementers do not yet have solutions or where where current implementers do not yet have solutions or where
researchers predict potential issues. researchers predict potential issues.
The workshop served as a venue to identify problems and to The workshop served as a venue to identify problems and to
skipping to change at page 6, line 7 skipping to change at page 6, line 7
changes in direction of already ongoing work at the IETF and or changes in direction of already ongoing work at the IETF and or
the Internet Research Task Force (IRTF). the Internet Research Task Force (IRTF).
Note that this document is a report on the proceedings of the Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB those of the workshop participants and do not necessarily reflect IAB
views and positions. views and positions.
2. Constrained Nodes and Networks 2. Constrained Nodes and Networks
An observation that lead to the scheduling of the workshop was the The workshop was spurred by the increasing presence of constrained
presence of constrained devices that are more and more interconnected devices on the network. It is quite natural to ask how these
to the network. So, it is quite natural to ask how these limitations limitations impact the design of the affected nodes. Note that not
impact the design of the affected nodes. Note that not all nodes all nodes suffer from the same set of limitations.
suffer from the same set of limitations.
Energy constraints: Energy constraints:
Since wireless communication can be a large portion of the power- Since wireless communication can be a large portion of the power-
budget for wireless devices, reducing unnecessary communication budget for wireless devices, reducing unnecessary communication
can significantly increase the battery life of a low-end device. can significantly increase the battery life of a low-end device.
The choice of low-power radio being used also has a lot of impact The choice of low-power radio can also significantly impact the
on the overall energy consumption. Sleeping periodically, and overall energy consumption, as can sleeping periodically, when the
often aggressively, when not in use. In some cases, these nodes device is not in use. In some cases, these nodes will only wake
will only wake periodically to handle needed communications. This periodically to handle needed communications. This constraint is
constraint is quite in contrast to the "always on" paradigm found quite in contrast to the "always on" paradigm found in regular
in regular Internet hosts. Even in case of non-battery operated Internet hosts. Even in the case of non-battery operated devices,
devices power is a constraint with respect to energy efficiency power is a constraint with respect to energy efficiency goals.
goals.
Bandwidth constraints: Bandwidth constraints:
Various low power radio networks offer only ~100 kbit/s or even Various low power radio networks offer only ~100 kbit/s or even
only a few KBits/s, and show high packet loss as well as high link only a few KBits/s, and show high packet loss as well as high link
quality variability. Nodes may be used in usually highly unstable quality variability. Nodes may be used in usually highly unstable
radio environments. The physical layer packet size may be limited radio environments. The physical layer packet size may be limited
(~100 bytes). (~100 bytes).
Memory constraints: Memory constraints:
The amount of volatile and persistent storage impacts the program The amount of volatile and persistent storage impacts the program
executtion has important implications for the functionality of the executtion has important implications for the functionality of the
protocol stack. The Arduino UNO board, for example, provides a protocol stack. The Arduino UNO board, for example, provides a
developer with 2 KByte RAM and 32 KByte flash memory (without any developer with 2 KByte RAM and 32 KByte flash memory (without any
extensions, such as microSD cards). extensions, such as microSD cards).
A system designer also needs to consider CPU constraints, which often A system designer also needs to consider CPU constraints, which often
relate to energy constraints: a processor with lower performance relate to energy constraints: a processor with lower performance
consumes less energy. As described later in this document the design consumes less energy. As described later in this document, the
of the mainboard may allow certain components to be put to sleep to design of the mainboard may allow certain components to be put to
further lower energy consumption. In general, embedded systems are sleep to further lower energy consumption. In general, embedded
often purpose built with only the hardware components needed for the systems are often purpose built with only the hardware components
given task while general purpose personal computers are less needed for the given task while general purpose personal computers
constrained with regard to their mainboard layout and typically offer are less constrained with regard to their mainboard layout and
a huge number of optional plug-in peripherals to be connected. A typically offer a huge number of optional plug-in peripherals to be
factor that also has to be taken into consideration is the intended connected. A factor that also has to be taken into consideration is
usage environment. For example, a humidity sensor deployed outside a the intended usage environment. For example, a humidity sensor
building may need to deal with temperatures from -50 C to +85 C even. deployed outside a building may need to deal with temperatures from
There are often physical size limitations for smart objects. While -50 C to +85 C. There are often physical size limitations for smart
traditional mainboards are rather large, such as the Advanced objects. While traditional mainboards are rather large, such as the
Technology eXtended (ATX) design with a board size of 305 x 244 mm Advanced Technology eXtended (ATX) design with a board size of 305 x
available in many PCs or the mini-ITX design typically found in home 244 mm available in many PCs or the mini-ITX design typically found
theater PCs with 170 x 170 mm, mainboard layouts for embedded systems in home theater PCs with 170 x 170 mm, mainboard layouts for embedded
are typically much smaller, such as the CoreExpress layout with 58 x systems are typically much smaller, such as the CoreExpress layout
65 mm, or even smaller. In addition to the plain mainboard with 58 x 65 mm, or even smaller. In addition to the plain mainboard
additional sensors, peripherals, a power adapter/battery, and a case additional sensors, peripherals, a power adapter/battery, and a case
have to be taken into consideration. Finally, there are cost have to be taken into consideration. Finally, there are cost
restrictions as well. restrictions as well.
The situation becomes more challenging when not only the hosts are The situation becomes more challenging when not only the hosts are
constrained but also the network nodes themselves. constrained but also the network nodes themselves.
While there are constantly improvements being made, Moore's law tends While there are constantly improvements being made, Moore's law tends
to be less effective in the embedded system space than in personal to be less effective in the embedded system space than in personal
computing devices: Gains made available by increases in transistor computing devices: Gains made available by increases in transistor
skipping to change at page 8, line 21 skipping to change at page 8, line 21
that had been raised by many authors. A summary of the identified that had been raised by many authors. A summary of the identified
issues are captured in the subsections below. issues are captured in the subsections below.
3.1. Architecture 3.1. Architecture
A number of architectural questions were brought up in the workshop. A number of architectural questions were brought up in the workshop.
This is natural, as the architectural choices affect the required This is natural, as the architectural choices affect the required
technical solutions and the need for standards. At this workshop technical solutions and the need for standards. At this workshop
questions regarding the separation of traffic, the need for profiling questions regarding the separation of traffic, the need for profiling
for application specific domains, the demand for data model specific for application specific domains, the demand for data model specific
standardization as well as the design choices of the layer at which standardization, as well as the design choices of the layer at which
functionality should be put were discussed and are briefly summarized functionality should be put were discussed and are briefly summarized
below. below.
3.1.1. One Internet vs. Islands 3.1.1. One Internet vs. Islands
Devices that used to be in proprietary or application-specific Devices that used to be in proprietary or application-specific
networks are today migrating to IP networks. There is, however, the networks are today migrating to IP networks. There is, however, the
question of whether these smart objects are now on the same IP question of whether these smart objects are now on the same IP
network as any other application as well. Controlled applications, network as any other application. Controlled applications, like the
like the fountains in front of the Bellagio hotel in Las Vegas which fountains in front of the Bellagio hotel in Las Vegas that are
are operated as a distributed control system [Dolin], probably are operated as a distributed control system [Dolin], probably are not
not exchanging their control messages over the same network that is exchanging their control messages over the same network that is also
also used by hotel guests for their Internet traffic. The same had used by hotel guests for their Internet traffic. The same had been
been argued for the smart grid as well. The question that was raised argued for the smart grid. The question that was raised during the
during the workshop is therefore in what sense are we talking about workshop is therefore in what sense are we talking about one Internet
one Internet or about using IP technology for a separate, walled or about using IP technology for a separate, walled garden network
garden network that is independent of the Internet? that is independent of the Internet?
Cullen Jennings compared the current state of smart object deployment Cullen Jennings compared the current state of smart object deployment
with the evolution of voice-over-IP: "Initially, many vendors with the evolution of voice-over-IP: "Initially, many vendors
recommended to run VoIP over a separate VLAN or a separate recommended to run VoIP over a separate VLAN or a separate
infrastructure. Nobody could imagine how to make the type of real- 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 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 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 for real-time systems. As time went on people got better at making
voice work across that type of IP network. They suddenly noticed voice work across that type of IP network. They suddenly noticed
that having voice running on a separate virtual network than their that having voice running on a separate virtual network than their
other applications was a disaster. They couldn't decide if a PC was 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. 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 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 and all moved to one. I wouldn't be surprised to see the same
happens here. Initially, we will see very separated networks. Then, happens here. Initially, we will see very separated networks. Then,
those will be running over the same hardware to take advantage of the 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 cost benefits of not having to deploy multiple sets of wires around
buildings. Over time there will be strong needs to directly buildings. Over time there will be strong needs to directly
communicate with each other. We need to be designing the system for communicate with each other. We need to be designing the system for
the long run. Assuming everything will end up on the same network the long run. Assume everything will end up on the same network even
even if you initially plan to run it in separate networks." if you initially plan to run it in separate networks."
It is clearly possible to let sensors in a building communicate It is clearly possible to let sensors in a building communicate
through the wireless access points and through the same through the wireless access points and through the same
infrastructure used for Internet access, if you want to. Those who infrastructure used for Internet access, if you want to. Those who
want separation at the physical layer can do so as well. What is, want separation at the physical layer can do so as well. What is
however, important is to make sure that these different deployment important is to make sure that these different deployment
philosophies do not force loss of interoperability. philosophies do not force loss of interoperability.
The level of interoperability that IP accomplished fostered The level of interoperability that IP accomplished fostered
innovation at the application layer. Ralph Droms reinforced this innovation at the application layer. Ralph Droms reinforced this
message by saying: "Bright people will take a phone, build an message by saying: "Bright people will take a phone, build an
application and connect it, with the appropriate security controls in application and connect it, with the appropriate security controls in
place, to the things in my house in ways we have never thought about place, to the things in my house in ways we have never thought about
before. Otherwise we are just building another telephone network." before. Otherwise we are just building another telephone network."
3.1.2. Domain Specific Stacks and Profiles 3.1.2. Domain Specific Stacks and Profiles
skipping to change at page 10, line 8 skipping to change at page 10, line 8
UDP), and the syntax and semantic for the light on/off functionality. UDP), and the syntax and semantic for the light on/off functionality.
As this list shows there is already some amount of protocol As this list shows there is already some amount of protocol
functionality that has to be agreed on by various stakeholders to functionality that has to be agreed on by various stakeholders to
make this scenario work seamlessly. As we approach more complex make this scenario work seamlessly. As we approach more complex
protocol interactions the functionality quickly becomes more complex: protocol interactions the functionality quickly becomes more complex:
IPv4 and IPv6 on the network layer, various options at the transport IPv4 and IPv6 on the network layer, various options at the transport
layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices layer (such as UDP, TCP, SCTP, DCCP), and there are plenty of choices
at the application layer with respect to communication protocols, at the application layer with respect to communication protocols,
data formats and data models. Different requirements have lead to data formats and data models. Different requirements have led to the
the development of a variety of communication protocols: client- development of a variety of communication protocols: client-server
server protocols in the style of the original HTTP, publish-subscribe protocols in the style of the original HTTP, publish-subscribe
protocols (like SIP or XMPP), store-and-forward messaging (borrowed protocols (like SIP or XMPP), store-and-forward messaging (borrowed
from the delay tolerant networking community). Along with the from the delay tolerant networking community). Along with the
different application layer communication protocols come various different application layer communication protocols come various
identity and security mechanisms. identity and security mechanisms.
With the smart object constraints it feels natural to develop these With the smart object constraints it feels natural to develop these
stacks since each application domain (e.g., health-care, smart grids, stacks since each application domain (e.g., health-care, smart grids,
building networking) will have their unique requirements and their building networking) will have their unique requirements and their
own community involved in the design process. How likely are these own community involved in the design process. How likely are these
profiles going to be the right match for the future, specifically for profiles going to be the right match for the future, specifically for
skipping to change at page 10, line 35 skipping to change at page 10, line 35
understanding and preferences of the community designing them? How understanding and preferences of the community designing them? How
many stacks will multi-purpose devices have to implement? many stacks will multi-purpose devices have to implement?
Standardizing profiles independently for each application is not the Standardizing profiles independently for each application is not the
only option. Another option is to let many different applications only option. Another option is to let many different applications
utilize a common foundation, i.e., a protocol stack that is utilize a common foundation, i.e., a protocol stack that is
implemented and utilized by every device. This, however, requires implemented and utilized by every device. This, however, requires
various application domains to be analyzed for their common various application domains to be analyzed for their common
characteristics and to identify requirements that are common across characteristics and to identify requirements that are common across
all of them. The level of difficulty for finding an agreement of how all of them. The level of difficulty for finding an agreement of how
such a foundation stack should look like depends on how many layers such a foundation stack should look depends on how many layers it
it covers and how lightweight it has to be. covers and how lightweight it has to be.
From the decisions at the workshop it was clear that the available From the discussions at the workshop it was clear that the available
options are not ideal and further discussions are needed. options are not ideal and further discussions are needed.
3.1.3. Which Layer? 3.1.3. Which Layer?
The end-to-end principle states that functionality should be put into The end-to-end principle states that functionality should be put into
the end points instead of into the networks. An additional the end points instead of into the networks. An additional
recommendation, which is equally important, is to put functionality recommendation, which is equally important, is to put functionality
higher up in the protocol stack. While it is useful to make common higher up in the protocol stack. While it is useful to make common
functionality available as building blocks to higher layers the wide functionality available as building blocks to higher layers the wide
range of requirements by different applications lead to a model where range of requirements by different applications led to a model where
lower layers provide only very basic functionality and more lower layers provide only very basic functionality and more
sophisticated features were made available by various applications. sophisticated features were made available by various applications.
Still, there has been the desire to put application layer Still, there has been the desire to put application layer
functionality into the lower layers of the networking stack. A functionality into the lower layers of the networking stack. A
common belief is that performance benefits can be gained if common belief is that performance benefits can be gained if
functionality is placed at the lower layers of the protocol stack. functionality is placed at the lower layers of the protocol stack.
This new functionality may be offered in the form of a gateway, which This new functionality may be offered in the form of a gateway, which
bridges different communication technologies, acts on behalf of other bridges different communication technologies, acts on behalf of other
nodes, and offers more generic functionality (such as name-based nodes, and offers more generic functionality (such as name-based
routing and caching). routing and caching).
Two examples of functionality offered at the network layer discussed Two examples of functionality offered at the network layer discussed
during the workshops were location, and name-based routing: during the workshops were location and name-based routing:
Location: Location:
The notion of location gives each network node the understanding 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 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 light switch.'). Today, a router may provide information as to
whether other nodes belong to the same subnet or they may provide whether other nodes belong to the same subnet or they may provide
location information (for example, in the form of GPS based location information (for example, in the form of GPS based
coordinates). However, providing a sense of the specific coordinates). However, providing a sense of the specific
environment (e.g., a room, building, campus, etc.) is not possible environment (e.g., a room, building, campus, etc.) is not possible
without manual configuration. While it has been a desirable without manual configuration. While it has been a desirable
feature for many ubiquitous computing applications to know this feature for many ubiquitous computing applications to know this
type of information and to use it for richer application layer type of information and to use it for richer application layer
interactions, widespread deployment has not happened yet. interactions, widespread deployment has not happened yet.
Name-based Routing: Name-based Routing:
With the work on recent clean slate architecture proposals, such With the work on recent clean slate architecture proposals, such
as the named data networking, flexible naming concepts are being as named data networking, flexible naming concepts are being
researched to allow application developer to express their researched to allow application developers to express their
application layer concepts in a way that they can be used natively application layer concepts in a way that they can be used natively
by the underlying networking stack without translation. For by the underlying networking stack without translation. For
example, Jeff Burke provided the example of his work in a theater example, Jeff Burke provided the example of his work in a theater
with a distributed control system of technical equipment (such as with a distributed control system of technical equipment (such as
projectors, dimmers, and light systems). Application developers projectors, dimmers, and light systems). Application developers
name their equipment with human readable identifiers, which may name their equipment with human readable identifiers, which may
change after the end of a rehearsal, and address them using these change after the end of a rehearsal, and address them using these
names. These variable length based naming concepts raise names. These variable length based naming concepts raise
questions regarding scalability. questions regarding scalability.
The workshop participants were not able to come to an agreement about The workshop participants were not able to come to an agreement about
what functionality should be moved from the application layer to the what functionality should be moved from the application layer to the
network layer. network layer.
3.2. Sleep Modes 3.2. Sleep Modes
One limitation of smart objects is the available energy. To extend One limitation of smart objects is their available energy. To extend
battery life, for example of a watch battery or single AAA battery battery life, for example of a watch battery or single AAA battery
for months, these small, low power devices have to sleep from 99% to for months, these small, low power devices have to sleep from 99% to
99.5% of their time. For example, a light sensor may wake up to 99.5% of their time. For example, a light sensor may wake up to
check whether it is night-time to turn on light bulbs. Most parts of check whether it is night-time to turn on light bulbs. Most parts of
the system are off-line most of the time and particularly the system are off-line most of the time and particularly
communication components are put into a sleeping state (e.g., WLAN communication components are put into a sleeping state (e.g., WLAN
radio interface) and only very few components of an embedded system radio interface) and only very few components of an embedded system
board, such as sensors, are triggered periodically. When interesting board, such as sensors, are triggered periodically. When interesting
events happen then these components wake-up other parts of the events happen, these components wake up other parts of the system,
system, for example a radio interface to connect to the Internet. for example a radio interface to connect to the Internet. Every bit
Every bit is precious, so is every round trip, and every millisecond is precious, as is every round trip, and every millisecond of radio
of radio activity. activity.
Many IETF protocols implicitly assume that nodes in a network are Many IETF protocols implicitly assume that nodes in a network are
always-on and respond to messages, i.e., to maintain a persistent always-on and respond to messages, i.e., to maintain a persistent
presence on the network in order to respond to periodic messages that presence on the network in order to respond to periodic messages that
are required in order to maintain persistent sessions, connections, are required in order to maintain persistent sessions, connections,
security associations, or state. These protocols work well on security associations, or state. These protocols work well on
networks with sufficient network bandwidth, where there is a low cost networks with sufficient network bandwidth, where there is a low cost
to receiving/sending messages, and nodes are persistently available to receiving/sending messages, and nodes are persistently available
on the network. on the network.
In the early days a machine had gotten a specific IP address In the early days a machine had been allocated a specific IP address
allocated and it could use it when it wanted to send an IP packet. and it could use it when it wanted to send an IP packet. The machine
You might need to execute an ARP exchange first before sending the might need to execute an ARP exchange first before sending the
packet but you could keep the mapping in the cache for 15 minutes. packet, but it could keep the mapping in the cache for 15 minutes.
Nowadays we want to make sure that we are on the right network before Nowadays a number of steps have to be taken before sending a packet.
we send an IP packet, we run neighbor discovery, we cannot keep We want to make sure that we are on the right network before we send
neighbor discovery for 15 minutes and so when a node wakes up again an IP packet. We run neighbor discovery. We cannot keep neighbor
it essentially has to re-do it to refresh the cache, we want to run discovery for 15 minutes and so when a node wakes up again it
essentially has to re-do it to refresh the cache. We want to run
Detecting Network Attachment (DNA) procedures to check that hosts are Detecting Network Attachment (DNA) procedures to check that hosts are
on the same network either by re-getting an address using the Dynamic on the same network either by re-obtaining an address using the
Host Configuration Protocol (DHCP) or by noticing that the node is Dynamic Host Configuration Protocol (DHCP) or by noticing that the
using the same default gateway because of a received Router node is using the same default gateway because of a received Router
Advertisement (RA). Essentially, a number of steps have to be taken Advertisement (RA).
before sending a packet.
However, these protocols do not work well, if at all, when the cost However, these protocols do not work well, if at all, when the cost
of sending/receiving those messages is high (in terms of bandwidth or of sending/receiving those messages is high (in terms of bandwidth or
battery life) or in cases where nodes sleep periodically and are not battery life) or in cases where nodes sleep periodically and are not
persistently available to receive those messages. A number of issue persistently available to receive those messages. A number of issue
arise from these almost-always-off nodes. arise from these almost-always-off nodes.
Also a lot of our protocols are getting more chatty. Keeping the Many protocols are also becoming more chatty. Keeping the receiver
receiver up for an additional roundtrip costs extra energy. Protocol up for an additional roundtrip costs extra energy. Protocol messages
messages can also be lengthy, e.g., many protocols carry XML-based can also be lengthy, e.g., many protocols carry XML-based payloads.
payloads.
There are a couple of ways to think about how to make the situation There are a couple of ways to think about how to make the situation
less worse: less worse:
1. The Always-On Assumption 1. The Always-On Assumption
When designing a protocol that assumes that the nodes will always When designing a protocol that assumes that the nodes will always
be there at least consider an alternative paradigm. For example, be there at least consider an alternative paradigm. For example,
with duplicate address detection an alternative would be not to with duplicate address detection an alternative would be not to
use it. There might be also the option to consider an use it. There might be also the option to consider an
skipping to change at page 13, line 25 skipping to change at page 13, line 23
they boot up to find out whether anyone tried to contact them or they boot up to find out whether anyone tried to contact them or
whether anything they care about has happened, or the proxy whether anything they care about has happened, or the proxy
answers on behalf of another node. Yet another option is to answers on behalf of another node. Yet another option is to
allow devices to expose their sleep cycles so that a device could allow devices to expose their sleep cycles so that a device could
go into a mode in which it only checks for messages periodically go into a mode in which it only checks for messages periodically
(be it measured in msec, sec, or hours) and let other devices (be it measured in msec, sec, or hours) and let other devices
know what sorts of delays there may be. know what sorts of delays there may be.
2. High Cost to Rejoin the Network 2. High Cost to Rejoin the Network
The goal of these things is to determine whether a wireless node The goal of these procedures is to determine whether a wireless
is not moved to another network while it was asleep and that node has not moved to another network while it was asleep and
might be a viable thing to do. Expecting a wirelss node to go that might be a viable thing to do. Expecting a wirelss node to
through all these steps every time it wakes up before it is go through all these steps every time it wakes up before it is
allowed to send an Ip packet could be considered rather allowed to send an IP packet could be considered rather
excessive. excessive.
Can we find ways to reduce the number of protocol interactions Can we find ways to reduce the number of protocol interactions
that have to be executed for network attachment, including that have to be executed for network attachment, including
determining whether a node has moved or the environment has determining whether a node has moved or the environment has
changed otherwise? changed otherwise?
3. Verbose Protocols 3. Verbose Protocols
Some protocols involve multiple roundtrips and/or lengthy Some protocols involve multiple roundtrips and/or lengthy
skipping to change at page 14, line 31 skipping to change at page 14, line 30
therefore one has to consider the overall energy consumption of the therefore one has to consider the overall energy consumption of the
entire solution. This is not always an easy question to answer. entire solution. This is not always an easy question to answer.
IEEE 802.11 nodes, for example, use a lot of power if they cannot be IEEE 802.11 nodes, for example, use a lot of power if they cannot be
made to sleep most of the time. A light bulb may use less power but made to sleep most of the time. A light bulb may use less power but
there is also the device that controls the bulb that may consume a there is also the device that controls the bulb that may consume a
lot of energy all the time. In total, more energy may be consumed lot of energy all the time. In total, more energy may be consumed
when considering these two devices together. when considering these two devices together.
3.3. Security 3.3. Security
In the development of a smart object applications, as with any other In the development of smart object applications, as with any other
protocol application solution, security has to be considered early in protocol application solution, security has to be considered early in
the design process. As such, the recommendations currently provided the design process. As such, the recommendations currently provided
to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101 to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101
[RFC4101], apply also to the smart object space. [RFC4101], apply also to the smart object space.
While there are additional constraints, as described in Section 2, While there are additional constraints, as described in Section 2,
security has to be a mandatory part of the solution. The hope is security has to be a mandatory part of the solution. The hope is
that this will lead to implementations that provide security that this will lead to implementations that provide security
features, deployments that utilize these, and finally that this leads features, deployments that utilize these, and finally that this leads
to use of better security mechanisms. It is important to point out to use of better security mechanisms. It is important to point out
skipping to change at page 15, line 5 skipping to change at page 14, line 52
on deployment models, configuration mechanisms, and software upgrade/ on deployment models, configuration mechanisms, and software upgrade/
crypto agility mechanisms. crypto agility mechanisms.
Since many of the security mechanisms allow for customization, Since many of the security mechanisms allow for customization,
particularly with regard to the cryptographic primitives utilized, particularly with regard to the cryptographic primitives utilized,
many believe that IETF security solutions are usable without many believe that IETF security solutions are usable without
modifications in a large part of the smart object domain. Others modifications in a large part of the smart object domain. Others
call for new work on cryptographic primitives that make use of a call for new work on cryptographic primitives that make use of a
single primitive (such as the Advanced Encryption Standard (AES)) as single primitive (such as the Advanced Encryption Standard (AES)) as
a building block for all cryptographic functions with the benefit of a building block for all cryptographic functions with the benefit of
a smaller footprint of the overall solution. Specifically the a smaller footprint of the overall solution, specifically with
different hardware limitations (e.g., the hardware architecture of respect to hardware limitations (e.g., the hardware architecture of
certain embedded devices prevents pipelining to be utilized). In the certain embedded devices prevents pipelining from being used). In
excitement for new work on optimizations of cryptograhpic primitives the excitement for new work on optimizations of cryptograhpic
other factors have to be taken into consideration that influence primitives other factors have to be taken into consideration that
successful deployment, such as widespread support in libraries, as influence successful deployment, such as widespread support in
well as intellectual property rights (IPR). As an example of the libraries, as well as intellectual property rights (IPR). As an
latter aspect the struggle of Elliptic Curve Cryptography (ECC)-based example of the latter aspect, the struggle of Elliptic Curve
cryptographic algorithms to find deployment can partially be Cryptography (ECC)-based cryptographic algorithms to find deployment
attributed to the IPR situation. The reuse of libraries providing can partially be attributed to its IPR situation. The reuse of
cryptographic functions is clearly an important way to use available libraries providing cryptographic functions is clearly an important
memory resources in a more efficient way. To deal with the way to use available memory resources in a more efficient way. To
performance and footprint concerns investigations into offloading deal with the performance and footprint concerns investigations into
certain resource-hungry functions to parties that possess more offloading certain resource-hungry functions to parties that possess
cryptographic power have been considered. For example, the ability more cryptographic power have been considered. For example, the
to delegate certificate validation to servers has been standardized ability to delegate certificate validation to servers has been
in the IETF before (see Online Certificate Status Protocol (OCSP) in standardized in the IETF before (see Online Certificate Status
the Internet Key Exchange protocol version 2 (IKEv2) and in Transport Protocol (OCSP) in the Internet Key Exchange protocol version 2
Layer Security (TLS)). (IKEv2) and in Transport Layer Security (TLS)).
Focusing only on the cryptographic primitives would be shortsighted; Focusing only on the cryptographic primitives would be shortsighted;
many would argue that this is the easy part of a smart object many would argue that this is the easy part of a smart object
security solution. Key management and credential enrollment, security solution. Key management and credential enrollment,
however, are considered a big challenge by many particularly when however, are considered a big challenge by many particularly when
usability requirements have to be taken into account. Another group usability requirements have to be taken into account. Another group
of challenges is seen in the privacy area where the ongoing work on of challenges concern privacy; with smart grids, for example, some
smart grids could be mentioned where concerns regarding the ability have voiced concerns regarding the ability of third parties to keep
of others to keep track of the user's energy usage consumption (and track of an individual's energy consumption (and draw associated
the associated conclusions) even in an aggregated form have been conclusions). As another example, it is easy to see how a scale that
voiced. As another example, it is easy to see how a scale that is is connected to the Internet for uploading weight information to a
connected to the Internet for uploading weight information to a
social network could lead to privacy concerns. While security social network could lead to privacy concerns. While security
mechanisms used to offer protection of the communication between mechanisms used to offer protection of the communication between
different parties also provide a certain degree of privacy protection different parties also provide a certain degree of privacy protection
they are clearly not enough to address all concerns. Even with the they are clearly not enough to address all concerns. Even with the
best communication security and access control mechanisms in place best communication security and access control mechanisms in place
one still needs additional safeguards against the concerns mentioned one still needs additional safeguards against the concerns mentioned
in the examples. in the examples.
While a lot can be said about how desirable it would be to deploy While a lot can be said about how desirable it would be to deploy
more security protocols on the entire Internet, practical more security protocols on the entire Internet, practical
considerations regarding usability and the incentives of the considerations regarding usability and the incentives of the
stakeholders involved have often lead to slower adaption. stakeholders involved have often lead to slower adoption.
3.4. Routing 3.4. Routing
A smart object network environment may also employ routers under A smart object network environment may also employ routers under
similar constraints as the end devices. Currently two approaches to similar constraints as the end devices. Currently two approaches to
routing in these low power and lossy networks are under routing in these low power and lossy networks are under
consideration, namely mesh-under and route-over. The so-called mesh- consideration, namely mesh-under and route-over. The so-called mesh-
under approach places routing functions below at the link layer and under approach places routing functions at the link layer and
consequently all devices appear as immediate neighbors at the network consequently all devices appear as immediate neighbors at the network
layer. With the route-over approach routing is done at the IP layer layer. With the route-over approach routing is done at the IP layer
and none in the link layer. Each physical hop appears as a single IP and none in the link layer. Each physical hop appears as a single IP
hop (ignoring devices that just extend the physical range of hop (ignoring devices that just extend the physical range of
signaling, such as repeaters). Routing in this context means running signaling, such as repeaters). Routing in this context means running
a routing protocol. IPv6 Routing Protocol for Low power and Lossy a routing protocol. IPv6 Routing Protocol for Low power and Lossy
Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the Networks (RPL) [I-D.ietf-roll-rpl], for example, belongs to the
route-over category. route-over category.
From an architectural point of view there are several questions that From an architectural point of view there are several questions that
skipping to change at page 16, line 45 skipping to change at page 16, line 38
addressing) allows certain types of IP protocols to communicate addressing) allows certain types of IP protocols to communicate
with their immediate neighbors and to therefore scope their with their immediate neighbors and to therefore scope their
recipients. A link-local multicast message will be received by recipients. A link-local multicast message will be received by
all nodes in the same IP link local realm unless some special all nodes in the same IP link local realm unless some special
optimizations are provided by the link layer. optimizations are provided by the link layer.
o When path computations are done at the link layer as well as on o When path computations are done at the link layer as well as on
the network layer then what coordination needs to take place? the network layer then what coordination needs to take place?
When multiple different link layer technologies are involved in a When multiple different link layer technologies are involved in a
network design then routing at layer 3 has to be provided in any network design, routing at layer 3 has to be provided in any case.
case. [I-D.routing-architecture-iot] talks about these tradeoffs [I-D.routing-architecture-iot] talks about these tradeoffs between
between route-over and mesh-under in detail. Furthermore, those who route-over and mesh-under in detail. Furthermore, those who decide
decide about the deployment have to determine how to connect smart about the deployment have to determine how to connect smart objects
objects to the Internet infrastructure and a number of wired and to the Internet infrastructure and a number of wired and wireless
wireless technologies may be suitable for a specific deployment. technologies may be suitable for a specific deployment. Depending on
Depending on the chosen technologies the above-mentioned mesh-under the chosen technologies the above-mentioned mesh-under vs. route-over
vs. route-over approach will have to be decided and further decisions approach will have to be decided and further decisions will have to
will have to be made about the choice of a specific routing protocol. be made about the choice of a specific routing protocol.
In 2008 the IETF formed the Routing Over Low power and Lossy networks In 2008 the IETF formed the Routing Over Low power and Lossy networks
(ROLL) working group to specify a routing solution for smart object (ROLL) working group to specify a routing solution for smart object
environments. During its first year of existence, the working group environments. During its first year of existence, the working group
studied routing requirements in details (see [RFC5867], [RFC5826], studied routing requirements in detail (see [RFC5867], [RFC5826],
[RFC5673], [RFC5548]), worked on a protocol survey comparing a number [RFC5673], [RFC5548]), worked on a protocol survey comparing a number
of existing routing protocols, including Ad hoc On-Demand Distance of existing routing protocols, including Ad hoc On-Demand Distance
Vector (AODV)-style of protocols [RFC3561], against the identified Vector (AODV)-style of protocols [RFC3561], against the identified
requirements. The protocol survey [I-D.ietf-roll-protocols-survey] requirements. The protocol survey [I-D.ietf-roll-protocols-survey]
was inconclusive and abandoned without giving rise to publication of was inconclusive and abandoned without giving rise to publication of
an RFC. an RFC.
The ROLL WG concluded that a new routing protocol satisfying the The ROLL WG concluded that a new routing protocol satisfying the
documented requirements has to be developed and the work on the RPL documented requirements has to be developed and the work on the RPL
was started, as the IETF routing protocol for smart object networks. was started as the IETF routing protocol for smart object networks.
Nevertheless, controversial discussions at the workshop about which Nevertheless, controversial discussions at the workshop about which
routing protocols is best in a given environment are still ongoing. routing protocols is best in a given environment are still ongoing.
Thomas Clausen, for example, argued for using an AODV-like routing Thomas Clausen, for example, argued for using an AODV-like routing
protocol in [Clausen]. protocol in [Clausen].
4. Conclusions and Next Steps 4. Conclusions and Next Steps
The workshop allowed the participants to get exposed to interesting The workshop allowed the participants to get exposed to interesting
applications and their requirements (buildings, fountains, theater, applications and their requirements (buildings, fountains, theater,
etc.), to have discussions about radically different architectures etc.), to have discussions about radically different architectures
and their issues (e.g., information centric networking), to look at and their issues (e.g., information centric networking), to look at
existing technology from a new angle (sleep nodes, energy existing technology from a new angle (sleep nodes, energy
consumption), to focus on some details of the protocol stack consumption), to focus on some details of the protocol stack
(neighbour discovery, security, routing) and to implementation (neighbour discovery, security, routing) and to learn about
experience. implementation experience.
One goal of the workshop was to identify areas that require further One goal of the workshop was to identify areas that require further
investigation. The list below reflects the thoughts of the workshop investigation. The list below reflects the thoughts of the workshop
participants as expressed on the day of the workshop. Note that the participants as expressed on the day of the workshop. Note that the
suggested items concern potential work by the IETF and the IRTF and suggested items concern potential work by the IETF and the IRTF and
the order does not imply a particular preference. the order does not imply a particular preference.
Security: Security:
A discussion of security is provided in Section 3.3. In general, A discussion of security is provided in Section 3.3. In general,
security related protocol exchanges and the required amount of security related protocol exchanges and the required amount of
computational resource requirements can contribute significantly computational resource requirements can contribute significantly
to the overall processing. Therefore, it remains a challenge how to the overall processing. Therefore, it remains a challenge to
to accomplish performance improvements without sacrifying the accomplish performance improvements without sacrifying the overall
overall security level taking the usability of the entire system security level, taking the usability of the entire system into
into consideration. consideration.
Another challenge is how to balance the security and performance Another challenge is how to balance the security and performance
needs of smart objects with the interoperability requirements of needs of smart objects with the interoperability requirements of
hosts on the Internet since different suites of algorithms may hosts on the Internet since different suites of algorithms may
tend to be chosen for these different environments. This involves tend to be chosen for these different environments. This involves
trade-offs between performance on the smart objects versus end-to- trade-offs between performance on the smart objects versus end-to-
end security. Solutions that mandate a "trusted" middlebox whose end security. Solutions that mandate a "trusted" middlebox whose
only role is to terminate security associations tend to be frowned only role is to terminate security associations tend to be frowned
upon from the security perspective, especially since end-users of upon from the security perspective, especially since end-users of
challenged devices (where those exist) are unlikely to understand challenged devices (where those exist) are unlikely to understand
the security consequences of such middleboxes. the security consequences of such middleboxes.
The discussion concluded with the following recommendations: The discussion concluded with the following recommendations:
* Investigate usability in cryptographic protocol design with * Investigate usability in cryptographic protocol design with
regard to credential management. As an example, the Bluetooth regard to credential management. As an example, the Bluetooth
pairing mechanism was mentioned as a simple and yet reasonably pairing mechanism was mentioned as a simple and yet reasonably
secure method of introducing devices into a new environment. secure method of introducing devices into a new environment.
In fact, the IETF working group 'Credential and Provisioning In fact, the IETF working group 'Credential and Provisioning
(ENROLL)' working group was established years ago to deal with (ENROLL)' was established years ago to deal with this topic but
this topic but was terminated prematurely due to lack of was terminated prematurely due to lack of progress. The email
progress. The email archive still exists and is available archive still exists and is available [enroll] and may provide
useful historical information.
[enroll] and may provide useful historical information.
* Standardized authentication and key exchange mechanisms should * Standardized authentication and key exchange mechanisms should
be surveyed for suitability in smart object environments with be surveyed for suitability in smart object environments with
respect to message size, computational performance, number of respect to message size, computational performance, number of
messages, codesize, and main memory requirements. A starting messages, codesize, and main memory requirements. A starting
point of such an investigation (in case of IKEv2) was provided point of such an investigation (in case of IKEv2) was provided
by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a by Tero Kivinen with [I-D.kivinen-ipsecme-ikev2-minimal] and a
suitable venue for discussion could be the recently established suitable venue for discussion could be the recently established
Light-Weight Implementation Guidance (LWIG) working group Light-Weight Implementation Guidance (LWIG) working group
[LWIG]. [LWIG].
skipping to change at page 19, line 43 skipping to change at page 19, line 42
topic within CFRG and the cryptographic research community is a topic within CFRG and the cryptographic research community is a
very worthwhile goal, any such algorithms will likely have to very worthwhile goal, any such algorithms will likely have to
offer very significant benefits before they will be broadly offer very significant benefits before they will be broadly
adopted. 20% less CPU is unlikely to be a winning argument no adopted. 20% less CPU is unlikely to be a winning argument no
matter what an algorithm inventor believes. matter what an algorithm inventor believes.
Energy Design Considerations: Energy Design Considerations:
One part of the workshop was focused on the discussion of energy One part of the workshop was focused on the discussion of energy
implications for IETF protocol design with proposals being made implications for IETF protocol design with proposals being made
how to extend protocols to better support nodes that are mostly about how to extend protocols to better support nodes that are
sleeping. Discussion are encouraged to take place at the RECIPE mostly sleeping. Discussion are encouraged to take place at the
mailing list [RECIPE]. The workshop position paper [Wasserman] by RECIPE mailing list [RECIPE]. The workshop position paper
Margaret Wasserman provides a good starting point for further [Wasserman] by Margaret Wasserman provides a good starting point
investigations. for further investigations.
Information/Content Centric Networking: Information/Content Centric Networking:
Information/Content Centric Networking is about accessing named Information/Content Centric Networking is about accessing named
content and a number of research projects have emerged around this content and a number of research projects have emerged around this
theme. At this point in time the work is not yet ready for theme. At this point in time the work is not yet ready for
standardization in the IETF. Instead, the formation of an IRTF standardization in the IETF. Instead, the formation of an IRTF
research group has been proposed and more details are available on research group has been proposed and more details are available on
the IRTF DISCUSS mailing list [irtf-discuss]. the IRTF DISCUSS mailing list [irtf-discuss].
skipping to change at page 20, line 34 skipping to change at page 20, line 34
papers may be useful as a starting point for further discussions papers may be useful as a starting point for further discussions
[Ersue], [Schoenwaelde]. An IETF draft is also available [Ersue], [Schoenwaelde]. An IETF draft is also available
[I-D.hamid-6lowpan-snmp-optimizations]. [I-D.hamid-6lowpan-snmp-optimizations].
Congestion Control: Congestion Control:
When smart objects transmit sensor readings to some server on the When smart objects transmit sensor readings to some server on the
Internet then these protocol interactions often carry a small Internet then these protocol interactions often carry a small
amount of data and happen infrequently, although regularly. With amount of data and happen infrequently, although regularly. With
the work on new application protocols, like the CoAP the work on new application protocols, like the CoAP
[I-D.ietf-core-coap], the question of congestion control mechanism [I-D.ietf-core-coap], the question of whether a congestion control
should be used at the underlying transport protocol or by the mechanism should be used at the underlying transport protocol or
application protocol itself. [I-D.eggert-core-congestion-control] by the application protocol itself arises.
is a starting point for the CoAP protocol but further work is [I-D.eggert-core-congestion-control] is a starting point for the
needed. CoAP protocol but further work is needed.
Data Models: Data Models:
Standardization of application layer protocols is important but Standardization of application layer protocols is important but
does not ensure that, for example, a light switch and a light bulb does not ensure that, for example, a light switch and a light bulb
are able to interact with each other. One area where participants are able to interact with each other. One area where participants
saw the need for further work was in the area of data models. saw the need for further work was in the area of data models.
While prior IETF standardization work on, for example, location While prior IETF standardization work on, for example, location
[GEOPRIV] can be re-used the question was raised where the IETF [GEOPRIV] can be re-used the question was raised where the IETF
should focus their standardization efforts on since domain should focus its standardization efforts since domain expertise in
expertise in each area will be needed. As potential example each area will be needed. As a potential example, energy pricing
energy pricing was discussed, with an example provided by was discussed, with an example provided by
[I-D.jennings-energy-pricing]. [I-D.jennings-energy-pricing].
Discovery: Discovery:
Additional extensions to developed discovery protocols (such as Additional extensions to developed discovery protocols (such as
mDNS) may be needed for the smart object environment. mDNS) may be needed for the smart object environment.
Building Networking: Building Networking:
Network architectures in residential as well as commercial Network architectures in residential as well as commercial
buildings should take the presence of smart objects and dedicated buildings should take the presence of smart objects and dedicated
subnetworks focusing on smart objects into account. A new working subnetworks focusing on smart objects into account. A new working
group, Home Networking (HOMENET) [FUN], has been proposed after group, Home Networking (HOMENET) [FUN], has been created after the
the workshop to look at this topic. workshop to look at this topic.
Routing: Routing:
Changing radio conditions and link fluctuation may lead to the Changing radio conditions and link fluctuation may lead to the
need for re-numbering. Workshop participants argued that work need for re-numbering. Workshop participants argued that work
should be started on the multi-link subnetworks to mitigate this 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 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 multiple links. With the publication of RFC 4903 [RFC4903] the
Internet Architecture Board had looked into this topic already and Internet Architecture Board had looked into this topic already and
provided pros and cons. provided pros and cons.
skipping to change at page 23, line 13 skipping to change at page 23, line 13
discussion of security, see Section 3.3. discussion of security, see Section 3.3.
6. Acknowledgements 6. Acknowledgements
We would like to thank all the participants for their position We would like to thank all the participants for their position
papers. The authors of the position papers were invited to the papers. The authors of the position papers were invited to the
workshop. workshop.
Big thanks to Elwyn Davies for helping us to fix language bugs. We Big thanks to Elwyn Davies for helping us to fix language bugs. We
would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas would also like to thank Andrei Robachevsky, Ulrich Herberg, Thomas
Clausen, Bruce Nordman, and Henning Schulzrinne for their review Clausen, Bruce Nordman, Alissa Cooper, and Henning Schulzrinne for
comments. their review comments.
Additionally, we would like to thank Ericsson and Nokia Siemens Additionally, we would like to thank Ericsson and Nokia Siemens
Networks for their financial support. Networks for their financial support.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Informative References 8. Informative References
 End of changes. 45 change blocks. 
162 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/