Grant agreement for: Collaborative project Grant agreement ...
Transcript of Grant agreement for: Collaborative project Grant agreement ...
Universal Integration of the Internet of Things through an IPv6-based
Service Oriented Architecture enabling heterogeneous components
interoperability
Grant agreement for: Collaborative project
Grant agreement no.: 288445
Start date of project: October 1st, 2011 (36 months duration)
Deliverable D8.3.3
Standardisation Activities & Efforts
Contract Due Date 30/09/2013
Submission Date 30/09/2013
Version v1.0
Responsible Partner University of Luxembourg (UL)
Author List L. Ladid (UL), S. Ziegler (MI), S. Krčo (Ericsson), A.
Skarmeta (UMU) M.R. Palattella (UL)
Dissemination level PU
Keywords Internet of Things, IPv6, Roadmap, Standardisation
Project Coordinator: Mandat International (MI)
Sébastien Ziegler <[email protected]>
D8.3.3 Standardization Activities and Efforts
2
Abstract
This Deliverable describes the new initiatives undertaken in Y3 by the IoT6 project partners for the
standardisation and awareness creation during and beyond the lifetime of the project following the
reviewers Y2 review recommendations, in order to take a strong step in getting the findings and
results out to industry and major stakeholders,
The IoT6 project partners did not spare any effort to form coalitions and partnerships and undertook
convincing stances and positive energy and attitude to win influencers of Standards and key
industry advocates to endorse the mature results of the project and spread them for adoption.
D8.3.3 Standardization Activities and Efforts
3
Table of Contents
1. Introduction .................................................................................. 4
2. Year 3 Standardisation Activities ......................................................... 5
2.1. New Standardization Efforts with ETSI and IETF ............................................... 5
2.1.1. Direct Cooperation with ETSI ................................................................ 5
2.1.2. IETF work performed ......................................................................... 7
2.1.3. Interaction with the ITU ..................................................................... 9
2.1.4. Cooperation with fora and international Organisations (IEEE ComSoc) ............... 9
2.2. Ongoing standardization effort at OASIS ....................................................... 15
2.3. New standardization effort: Web Service specification for home and building automation .................................................................................................. 15
3. Conclusion ................................................................................... 17
4. Annexes ...................................................................................... 18
4.1. Annex I – ETSI ISG IP6 (first 6 pages from 15) .................................................. 18
4.2. Annex II – IoT Standardisation Chapter, IERC Book 2014 (first 2 pages from 56) ......... 23
4.3. Annex III – Handle System ......................................................................... 25
4.3.1. Some Features of the Handle System ..................................................... 25
4.3.2. Handles as Persistent Identifiers........................................................... 25
4.3.3. Handle Syntax ................................................................................. 25
4.3.4. Handle Resolution and relevance to IoT applications ................................... 26
4.3.5. Administering Handles – Security Provisions and Implications ........................ 26
4.3.6. Handle System Scalability ................................................................... 27
4.3.7. Storage scalability ........................................................................... 27
4.3.8. Security aspects .............................................................................. 28
4.3.9. Authentication ................................................................................ 28
4.3.10. Security Services in Handle ................................................................. 28
4.3.11. Handle Value Types .......................................................................... 29
4.3.12. Template Handles ............................................................................ 29
4.4. Annex IV – IETF Standardisation Efforts ......................................................... 30
D8.3.3 Standardization Activities and Efforts
4
1. Introduction
The IoT6 project aimed at exploiting the potential of IPv6 and related standards (6LoWPAN,
COAP, etc.) to overcome current shortcomings and fragmentation of the Internet of Things, in
line with the IERC (Internet of Things European Research Cluster) and EC recommendations.
Its main challenges and objectives were to research, design and develop a highly scalable IPv6-
based Service-Oriented Architecture to achieve interoperability, mobility, cloud computing
integration and intelligence distribution among heterogeneous smart things components,
applications and services. Its potential has been researched by exploring innovative forms of
interactions such as:
Information and intelligence distribution.
Multi-protocol interoperability with - and among - heterogeneous devices.
Device mobility and mobile phone networks integration, to provide ubiquitous access and
seamless communication.
Cloud computing integration with Software as a Service (SaaS).
IPv6 - STIS Information Service (Smart Things Information Services) innovative
interactions.
The main outcomes of IoT6 are recommendations on IPv6 feature exploitation for the Internet of
Things and an open and well-defined IPv6-based Service Oriented Architecture (SOA) enabling
interoperability, mobility, cloud computing and intelligence distribution among heterogeneous
smart things components, applications and services, including business process management
tools.
To achieve these ambitious goals, the consortium consists of seven international academic or
research partners and two industrial partners that bring in expertise from complementary
research areas such as IPv6, multi-protocol interoperability, routing protocols, security, SOAs,
sensor networks, building automation, mobile phone networks, cloud computing, business
processes and STIS/RFID. IoT6 was supported by a large industry support group with renowned
members, who acted as general advisors and supported the dissemination, exploitation and
standardisation activities.
D8.3.3 Standardization Activities and Efforts
5
2. Year 3 Standardisation Activities
The main standardisation bodies targeted by the IoT6 partners are ETSI and the IETF. The close
cooperation with the IERC has proved to be of very strategic value. In particular, the core IoT6
partners are championing some IERC WG activities and conference tracks through their leading
roles in the IoT Forum and IoT Week organisation, facilitating smooth and credible interactions
and peering with the other influencers on the strategy of IoT research and standardisation. The
standardisation activities can be summarised as follows:
2.1. New Standardization Efforts with ETSI and IETF
Following the recommendation of the reviewers to take a strong step in getting the findings and
results out to industry and major stakeholders, a closer working relationship has been established
with ETSI in Y3, due mainly to the realisation and acceptance by the IERC standardisation task
run by Patrick Guillemin at ETSI. This has resulted in the realisation that IPv6 is a key
communication protocol for IoT, thereby transforming earlier perceptions of IPv6 as a
controversial technology within the IoT research community which worked for 5 to 6 years on
RFID-only based IoT.
A follow-up workshop was organized by IoT6 on IPv6-and-IoT, within the framework of the IoT
Week 2014 in London. It brought together ETSI, IoT6 partners, the IERC Cluster project as well
as various European research projects to explore the potential of IPv6 and IoT.
2.1.1. Direct Cooperation with ETSI
In a new consultation with our ETSI representative, we have further pursued our standardisation
activities with the following decisive actions:
2.1.1.1 Creation of the ETSI Industry Specification Group IP6 (IPv6 ISG)
Following an evaluation of the IoT6 standardisation efforts from the first and second years of the
project, we have decided to create a new Industry Specification Group (ISG) at ETSI called
“IP6”.
Latif Ladid, a 3GPP board member since 1999, has been asked by ETSI to convene a first
meeting of this ISG. Latif had already established back in 2009 the very first ETSI ISG for
Autonomics called the “Autonomic Future Internet” (AFI), which was formed from the FP7
project EFIPSANS and concluded its work with industry-oriented recommendations.
The first meeting with the ETSI management for the discussion and application of the ETSI ISG
“IP6” was held on February 18, 2014. The application was submitted four weeks later and - after
many re-iterations – it was submitted to the ETSI Board at the end of June. The Board asked for
some detailed definition of the precise objectives and tasks which were resubmitted at the end of
July for review at the next ETSI meeting at the end of September 2014. The Board’s acceptance
at that meeting will enable the start of the work in October 2014 and we have the assurance that
this ISG will be accepted by our ETSI representative on the IoT6 Advisory Board which has a
keen interest in seeing this happen. The complete application can be viewed in Annex 1.
D8.3.3 Standardization Activities and Efforts
6
Logo of the ETSI “IP6” ISG
The IP6 ISG has the ambition to define Best Practices and garner support and create awareness
of the IPv6 impact on critical infrastructure in the first round, and then on hot topics such as IoT,
Cloud Computing, SDN-NFV and 5G which are similarly built on IPv6.
The “IPv6 integration” Industry Specification Group (“IP6 ISG”) is a Best Practice Working
Group focusing on the investigation of requirements and Use Cases identifying what and where
pre-standardization consensus and harmonization can be reached.
In the case of future wireless networks, the IP6 ISG will decouple its work from radio and focus
on v4-v6 impact in early technical discussions, integrating new technologies with a holistic
approach such as IPv6-based Software Defined Networks (SDN), Machine-to-Machine, Mobile
Internet of Things, Mobile Cloud Computing and Fringe Internet, focusing on commonly agreed
requirements toward the emergence of an “IPv6 integration”.
The tasks of the IP6 ISG will be implemented in three phases:
Phase 1:
The core team will select and define 3 focused Use Cases, where IPv6 can have real
impact, such as:
o Mobile networks and services
o Critical infrastructure in the safety and emergency networks,
o Security and privacy
At the start of Phase 1, new members (to reach some 50 experts and over 200 members
organisations) will be attracted to support not only the groundwork, but also prepare for
Phase 2.
Phase 2:
Attract IPv6 experts with focused and practical knowledge, to define the impact of IPv6
on:
o Mobile Cloud Computing and the impact of Mobile IPv6.
o Internet of Things and the impact of addressing billions of devices.
o SDN and Network Functions Virtualization (NFV) and the role IPv6 will play in
the Internet Data Centres (IDCs) and the Operators networks.
o Fringe Internet and the impact of scalability of the edge network.
Phase 3:
Coordinate with the 5G PPP researchers and attract IPv6 experts with focused and
practical knowledge in 5G networking to:
D8.3.3 Standardization Activities and Efforts
7
o Define the interaction impact of IPv6 with the 5G radio research (5G PPP)
especially in areas of spectrum efficiency and latency when using IPv6 packets.
2.1.1.2 Contribution to the Global Standardisation Book
The IoT6 has contributed to the Global Standardisation chapter of the IERC Book 2014. The
main focus was to make sure that IPv6 is specified as the preferred IP communication protocol.
The IERC standardisation community that contributed and edited this 56 pages long chapter have
not touched or edited the IPv6 and all related IPv6 sections. This is because for years IPv6 has
been perceived as a controversial topic especially since all past IoT research and standardisation
efforts have concluded that RFID is the Internet of Things.
The complete text can be read on the IERC web site: http://www.internet-of-things-
research.eu/pdf/IoT-
From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_Cluster_e
Book_978-87-93102-95-8_P.pdf
2.1.1.3 Contribution of UCL to ETSI with the Handle System
UCL has participated in the ETSI/EC work on standardisation by participating in the July 3rd
- 4th
meeting on “Standards in IoT” in Nice, France. Peter Kirstein made a presentation entitled:
“Standards for a Digital Object Approach to IoT”. This presentation discussed the Handle
approach to identifier resolution, and how this class of system could be used in the management
of properties of the Handles associated with the identifiers. In particular, he discussed how their
approach to an authorization requirement for any access to the Handles resulted in a system that
revealed much less information about the nature of physical systems to unauthorised agents. The
link to IPv6 addresses was effected by making these attributes to a Handle. The nature of IPv6
multiple addresses for the same object, allows independent agents to access the same IoT
interfaces through independent network paths – which reflects their organisation’s network
routing in their application domain. It also permits the storage of security tokens securely in a
data repository of security tokens associated with specific Handles.
In a related dissemination activity, the same authors contributed to the recent IERC activity on
Governance and Security in IoT.
The features of the Handle System are outlined in Annex III.
2.1.2. IETF work performed
2.1.2.1 Draft Standard submission to the IETF
HESSO and UL have resubmitted the Internet draft “IPv6 mapping to non-IP” draft-rizzo-6lo-
6legacy-01 under the new IETF WG 6lo replacing the 6LowPAN WG.
Abstract:
IPv6 is an important enabler of the Internet of Things, since it provides an addressing space large
enough to encompass a vast and ubiquitous set of sensors and devices, allowing them to
interconnect and interact seamlessly. To date, an important fraction of those devices is based on
networking technologies other than IP. An important problem to solve in order to include them
into an IPv6-based Internet of Things, is to define a mechanism for assigning an IPv6 address to
each of them, in a way which avoids conflicts and protocol aliasing.
D8.3.3 Standardization Activities and Efforts
8
The only existing proposal for such a mapping leaves many problems unsolved and it is
nowadays inadequate to cope with the new scenarios which the Internet of Things presents. This
document defines a mechanism, 6TONon-IP, for assigning automatically an IPv6 address to
devices which do not support IPv6 or IPv4, in a way which minimizes the chances of address
conflicts, and of frequent configuration changes due to connection instability among devices.
Such a mapping mechanism enables stateless autoconfiguration for legacy technology devices,
allowing them to interconnect through the Internet and to fully integrate into a world wide scale,
IPv6-based IoT.
The Internet draft is listed under Annex IV: http://www.ietf.org/mail-archive/web/i-d-
announce/current/msg56550.html
2.1.2.2 UMU Standardisation activity at the IETF
Within Y3, UMU has been active following the newly created WG Authentication and
Authorization for Constrained Environments (ACE). Specifically the UMU team has presented a
draft related to IoT6 work on the use of EAP and CoAP for authentication and authorization
http://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-00:
Abstract
This document describes an authentication service that uses EAP transported by means of CoAP
messages with two purposes:
o Authenticate two CoAP endpoints.
o Bootstrap key material to protect CoAP messages exchanged between them.
2.1.2.3 6TiSCH Standardization activities
UL have contributed to the Internet draft 6TiSCH On-the-Fly Scheduling draft-dujovne-6tisch-
on-the-fly-03 under the IETF WG 6TiSCH.
Abstract
This document describes the environment, problem statement, and goals of On-The-Fly (OTF)
scheduling, a Layer-3 mechanism for 6TiSCH networks. The purpose of OTF is to dynamically
adapt the aggregate bandwidth, i.e., the number of reserved soft cells between neighbor nodes,
based on the specific application constraints to be satisfied. When using OTF, softcell and
bundle reservation is distributed: through the 6top interface, neighbor nodes negotiate the cell(s)
to be (re)allocated/deleted, with no intervention needed of a centralized entity. This document
aims at defining a module which uses the functionalities provided by the 6top sublayer to (i)
extract statistics and (ii) determine when to reserve/delete soft cells in the schedule. The exact
reservation and deletion algorithm, and the number and type of statistics to be used in the
algorithm are out of scope. OTF deals only with the number of softcells to be reserved/deleted; it
is up to 6top to select the specific soft cells within the TSCH schedule.
The Internet draft can be viewed under: https://datatracker.ietf.org/doc/draft-dujovne-6tisch-on-the-fly/
D8.3.3 Standardization Activities and Efforts
9
University of Murcia (UMU) is also involved in the 6TiSCH activities related to the security
aspect of the 6TiSCH architecture. In detail, UMU has co-authors the draft [15]. This document
introduces a more secure and scalable key management framework for 6TiSCH networks using
PANA (Protocol for carrying Authentication for Network Access) as the bootstrapping
mechanism and identifies requirements for key management protocols to be used in the
framework.
2.1.3. Interaction with the ITU
MI has maintained an active link with the International Telecommunication Union (ITU). The
effort was focused on three ITU fora:
• The ITU World Telecom Conference in Bangkok, where UL and MI have organized an
IoT6 workshop on IPv6 for IoT. The workshop has been well attended and managed to
explore links of cooperation with the Asian research community.
• The JCA-IoT, which coordinates the standardization effort on the IoT. MI attended
several meetings and made two presentations of its research effort on IoT and IPv6.
• Green ICT Week, which focuses on green ICT and climate changes. MI attended two
Green ICT Weeks and made each time a presentation of its research efforts and
outcomes.
At the last Green ICT Week organized by the ITU in Beijing, MI has formally submitted
a proposal to organize a session and a demonstration on IoT technologies, in the
framework of an ITU IoT-JCA and/or Green ICT meetings. The idea is to present not
only IoT6 results, but to involve other European research projects too, including IoT Lab.
The targeted time would be in 2015 and will be further discussed with the ITU. Finally,
the ITU Regional Office for Asia and the Pacific has requested MI to provide support on
IPv6 and security strategy.
2.1.4. Cooperation with fora and international Organisations (IEEE
ComSoc)
The IoT6 partners have contributed in the foundation of the IoT Forum under the leadership of
MI based now in Switzerland: http://iotforum.org/contact/.
The IEEE ComSoc IoT initiative proved to be a strategic channel to get the results of the IoT6
out to the world. The chair of the IEEE ComSoc Emerging Technologies Committee, Prof
Andrea Schmidt from Stanford, a highly recognized expert in the IEEE world has been very
laudable with the IoT subC work and was very supportive of the new initiatives in 5G and SDN-
NFV.
The work done by Antonio Jara with the IPSO alliance is very important to note.
2.1.4.1 IoT Forum
IoT6 took part in the Technology WG session of the International IoT Forum (London, June
2014) and presented the vision of IPv6’s role in IoT. Moreover, MI organized with the other
IoT6 members a special session on IoT and IPv6 which gave the opportunity to strengthen the
links and align the visions on IPv6 potential for IoT related projects.
D8.3.3 Standardization Activities and Efforts
10
2.1.4.2 IPSO Alliance
Antonio Jara has contributed to the IPSO alliance IoT Starter Pack 1.0 working with the inventor
of 6LoWPAN Geoff Mulligan with a quote in this press release listed below.
“Thanks to contributions such as GLoWBAL IPv6 developed in the context of IoT6, IPv6
support is being offered for Bluetooth Smart devices. This means that millions of Smart Phones
and SOHO devices can be benefited of IPv6 capabilities, presenting a disruptive innovation for
the Internet of Things market powered by IPv6. This IPv6 capabilities in conjunction with the
other protocols addressed such as CoAP are enabling this personal area network devices,
invisible until now for Internet, be able to interact with Cloud Computing services, and cross
borders between capillary and cellular networks. In fact, the solution based on Bluetooth Smart
is considered the reference implementation from OMA LWM2M (http://oma.post.camp/source-
code/lab-kit/) and being considered the most innovative solution during the IPSO Challenge
2014 (Best people's choice award) and Sensors Expo (Attendees Award) during its last edition in
Chicago (USA). The innovation value was to offer the first Bluetooth Smart and IPv6-ready
solution in the market (http://www.ipso-alliance.org/challenge/ipso-challenge-2014-
interviews/hop-into-the-iot-through-ipv6-ready-bluetooth-smart-devices).”
Nowadays, these capabilities are making echo in other EU projects such as BUTLER and
OpenIoT (in the context of the Smart Action initiative), which is integrating this IPv6-ready
devices into their platforms.
Finally, the HOP Ubiquitous team continues contributing to OMA LWM2M for the mapping of
Bluetooth Smart functions and emerging devices, which will be released in the coming releases
of OMA Web objects definitions from the IPSO Alliance.
IPSO Alliance Publishes Smart Objects Guideline – Starter Pack 1.0
Smart Objects promote web scale interoperability between IP-connected devices and
Internet of Things (IoT) applications
Colorado Springs, CO – September 30, 2014—The Internet Protocol for Smart Objects
(IPSO) Alliance has published its Smart Objects Guideline – Starter Pack 1.0. The Smart
Objects Starter Pack (SOSP) 1.0 provides a basis for interoperability across devices
connected to the IoT through an open common object model. This open standards based
data design is crucial for the wide scale deployment and success of IoT and Machine to
Machine (M2M) applications.
In its role as the leader in the use of Internet Protocol (IP) across the IoT, IPSO has been
working to promote the use of open standards and explain the benefits of an IP based
end-to-end IoT. With this publication, IPSO is moving from “Why use IP” to “How to
use IP”. Geoff Mulligan, IPSO Chairman, explains, “This document is the first in a series
that will serve as a guide to developers, product designers and anyone choosing between
closed proprietary systems and open standards based solutions. These guidelines will help
innovators more easily use IP in Smart Objects for new application domains and help
facilitate growth in the IoT.”
The Alliance is now working on IoT architecture guidelines that will bring together the
knowledge of IPSO members from across industries including Smart Energy, Smart
Cities, Healthcare, Home Automation, Process Control and Building Automation. These
documents will provide a guide to understanding how various open standards can be
D8.3.3 Standardization Activities and Efforts
11
combined to build a secure, interoperable, extensible and maintainable IoT and M2M
communications stack.
“Much like the LAMP (Linux, Apache, MySQL and PHP) stack brought growth to the
Internet, a standards based IoT Architecture and Stack design will bring growth,
understanding and stability to the IoT”, Antonio J. Jara, IEEE ComSoc IoT ETC and
HOP Ubiquitous CEO, stated.
To contribute to the development of future technical guidelines, join IPSO Alliance
today. Members receive exclusive access to the IPSO think tank and are instrumental in
driving the direction for the IoT. For more information, visit www.ipso-
alliance.org/membership.
About The IPSO Alliance
The IPSO Alliance was formed in 2008 to promote the use of IP in Smart Objects.
The IPSO Smart Object Committee formed in 2011 to provide guidance on how to use IP
and other standards to enable interoperability between IP-connected devices and IoT
applications.
For more information, contact Jessica Barnes at [email protected].
https://www.linkedin.com/company/ipso-alliance
https://www.facebook.com/IPSOAlliance
https://www.twitter.com/IPSOAlliance
2.1.4.3 IEEE ComSoc IoT subCommittee
http://committees.comsoc.org/IoT
In the context of the project, an IEEE ComSoc technical working group on Internet of Things
(IoT) has been created in November 2012. The group is chaired by Latif Ladid (UL), and vice-
chaired by: Antonio Jara (UMU), Antonio Skarmeta (UMU) and Sebastien Ziegler (MI).
The objective of this subcommittee is to facilitate a global definition of IoT architecture and
governance; investigate the sensitive security and privacy issues; and explore the different
technology scenarios and impacts when enabling Internet protocols over the emerging
generations of IoT devices and networks in order to reach harmonization and end to end
transparency through IPv6. For this reason it is supported by IPv6 Forum (www.ipv6forum.org).
Moreover, this subcommittee has pursued a global collaboration with IEEE ComSoc and non-
IEEE organizations from academia and industry. For this purpose, current members from the
TPCs in the GLOBECOM 2013 IoT Symposium track have been invited as well as members
from industrial alliances such as IPSO Alliance, Open Mobile Alliance (OMA) and
standardization groups such as ETSI M2M, oneM2M and IETF. The worldwide research
community such as the European IERC community has been invited too (http://www.internet-of-
D8.3.3 Standardization Activities and Efforts
12
things-research.eu/ ). This multi-discipline of the members from this TC will promote a common
understanding to enable harmonization and convergence on governance, integration and security
of the Internet of Things.
IEEE ComSoc IoT is supporting different conferences such as Globecom 2014 with an Industry
Forum session with participation of the Project Officer Dr. Jorge Pereira to influence the IEEE
ComSoc community to adopt the IoT6 results for a global good. It is also supporting the IEEE
World Forum on Internet of Things, WF-IoT, (http://sites.ieee.org/wf-iot/).
IEEE ComSoc IoT has edited some special issues in journals such as the Journal of Networks
and Computer Applications (http://www.journals.elsevier.com/journal-of-network-and-
computer-applications/).
2.1.4.4 IEEE ComSoc 5G subCommittee
Following the highly successful IEEE ComSoc IoT subcommittee in 2013 start by the IoT6
partners, two new IEEE ComSoc initiatives have been started: 5G and SDN-NFV
IEEE ComSoc 5G subC:
http://committees.comsoc.org/5gmwi
The IoT6 project has taken again a strategic step in applying at the end of 2013 for the IEEE
COMSOC 5G subcommittee and won it to build a set of Best Practices for the industry
deployment in enabling IPv6 as well as IoT on 5G. This 5G subC has started in January 2014.
A certain number of experts from academia and “industry-oriented” has been invited to support
this work, such as but not limited to:
Chair of 5G subC: 3GPP PCG Board member, Founder & President of the IPv6 Forum,
Latif Ladid
Member of the ETSI standardization Group and the Industrial Forum about M2M/IoT:
Patrick Guillemin
Work for leading vendors: Fredrik Garneij, 3-4-5G and IPv6 Specialist at Ericsson;
Pascal Thubert, IoT and IPv6 Expert at the IETF, designer of 6LoWPAN/6TiSH, Cisco
5G Mobile Wirless Internet web site: http://committees.comsoc.org/5gmwi
5G in EU
On the EU side, a very important programme is the 5G –PPP (Public Private Partnership)
programme.
D8.3.3 Standardization Activities and Efforts
13
The 5G Infrastructure Public-Private Partnership, in short 5G PPP, has been initiated by the EU
Commission and industry manufacturers, telecommunications operators, service providers,
SMEs and researchers. The 5G PPP will deliver solutions, architectures, technologies and
standards for the ubiquitous next generation communication infrastructures of the coming
decade. See www.5g-ppp.eu
The challenge for the 5G Public-Private Partnership (5G PPP) is to secure Europe’s leadership in
the particular areas where Europe is strong or where there is potential for creating new markets
such as smart cities, e-health, intelligent transport, education or entertainment and media. The 5G
PPP initiative will reinforce the European industry to successfully compete on global markets
and open new innovation opportunities. It will “open a platform that helps us reach our common
goal to maintain and strengthen the global technological lead”. Our key challenges for the 5G
Infrastructure PPP are:
1. Providing 1000 times higher wireless area capacity and more varied service
capabilities compared to 2010.
2. Saving up to 90% of energy per service provided. The main focus will be in mobile
communication networks where the dominating energy consumption comes from the
radio access network.
3. Reducing the average service creation time cycle from 90 hours to 90 minutes.
4. Creating a secure, reliable and dependable Internet with a “zero perceived” downtime
for services provision.
5. Facilitating very dense deployments of wireless communication links to connect over
7 trillion wireless devices serving over 7 billion people.
6. Ensuring for everyone and everywhere the access to a wider panel of services and
applications at lower cost.
There are currently some very strategic 5G academic research community from around the world
namely with the newly European Commission funded 5G projects such as METIS and 5GNOW
and the newly founded 5G Fora in South Korea (5 Forum Korea), China and Japan:
METIS (Nov. 2012) The first stage of the 5G EU “missile”.
China - “IMT-2020 (5G) Promotion group” (Feb. 2013) Program 863.
Korea - 5G Forum (June 2013) Ambitious plan.
Japan - 2020 and Beyond AdHoc (Oct. 2013) ARIB established new AdHoc working
group called “2020 and Beyond AdHoc”.
D8.3.3 Standardization Activities and Efforts
14
There is an H2020 Open Call for 5G PPP projects, closing 25th
November 2014 for a total budget
of 125 Million Euros ( http://5g-ppp.eu/call/).
2.1.4.5 IEEE ComSoc SDN-NFV subcommittee
http://www.comsoc.org/about/committees/emerging#sdnnfv
The Software Defined Networking (SDN) and Network Functions Virtualization (NFV) ComSoc
Emerging Technology sub-committee focuses on exploring next generation networking
technologies and their interaction with the other major IT inflexion points: IPv6, Cloud and
Mobility.
The Software Defined Networking (SDN) and Network Functions Virtualization (NFV) IEEE
ComSoc Technical Sub-committee focuses on exploring next generation networking
technologies enabling software defined service delivery, network virtualization, network
function virtualization, and the enablement of mobility. The subcommittee will analyze and drive
integration around the touch points with all the other major IT inflexion points such as next
generation IP, compute and storage virtualization, cloud, mobility and the next generation
applications. The key challenge to be addressed is to support multivendor networks in a software
defined infrastructure that meets the demands of the next generation IT environments.
Topics addressed by the subcommittee will include network architecture, protocols and
implementations that fully leverage the SDN/NFV concepts, strengths and weakness of current
standards such as OpenFlow, alignment with cloud standards and IPv6 concepts, security
considerations of SDN/NFV, innovative architectures, operations and service assurance in
SDN/NFV-enabled environments; and education to develop the engineering talent needed to
design, deploy and operate SDN/NFV environments. This committee will harmonize its work
with the Open Networking Foundation (ONF), IEEE and non-IEEE organizations from academia
and industry including the academic research community, SDN/NFV and next-generation
infrastructure projects, and standardization bodies.
Committee Members:
Chairperson: Ciprian Ciprianou, Founder & CEO of Nephos6
Vice-chairs: Adam Johnson, General Manager Midokura
Dan Torbet, Technology Lead Arris
Latif Ladid, Founder & President, IPv6 Forum, Senior Researcher, UL
D8.3.3 Standardization Activities and Efforts
15
2.2. Ongoing standardization effort at OASIS
VUT worked on the standardization of efficient IoT protocol bindings for OBIX. The latest draft
has been enhanced with REST bindings to CoAP and with message encoding bindings to JSON
and EXI.
Achievements:
15th
January 2014
30-day public reviews for five specifications begins. The original announcement with
instructions for commenting are at https://www.oasis-
open.org/news/announcements/30-day-public-review-for-5-open-building-
information-exchange-obix-committee-spec.
OBIX v1.1 provides the core information model and interactions for interactions with
building control systems. It also describes the default XML encoding for OBIX.
Encodings for OBIX: Common Encodings v1.0 specifies different encodings for
OBIX objects adhering to the OBIX object model. Elaborates the XML encodings
used in the core specification as well as common alternate encodings, including
CoAP, EXI, and JSON.
Bindings for OBIX: REST Bindings v1.0 specifies REST bindings for OBIX. REST
can be used in conjunction with XML, EXI, CoAP, and JSON encodings, as well as
other encodings that may be specified elsewhere.
Bindings for OBIX: SOAP Bindings v1.0 specifies SOAP protocol bindings for
OBIX. The specification includes a WSDL artefact.
Bindings for oBIX: WebSocket Bindings v1.0 specifies WebSocket protocol bindings
for OBIX.
17th January 2014:
The TC began the discussion of broadcast and peer-to-peer interactions for OBIX 2.0.
This joins service interactions and potential WS-Calendar interactions on the work
plan. The Committee invites other suggestions for inclusion in OBIX 2.0.
2.3. New standardization effort: Web Service specification for home and
building automation
VUT is assisting a well-known home and building automation association as editor for a
standardized Web service interface specification. Findings of the IoT6 research project are
incorporated into the proposed interface specification. The underlying association is the
organization responsible for maintaining a worldwide standard for home and building control
with the highest market share in Europe. A first draft of a Web service specification based on
OBIX together with IoT protocol bindings has been presented at a technical board meeting to
members of the association.
D8.3.3 Standardization Activities and Efforts
16
Timetable of events in the context of standardisation
Dates Location Role Title Partner
18/2/2014 Sophia Antipolis, France Presentation of
ISG
ETSI ISG IPv6 UL, Mandat
International
26/6/2014 London Workshops IoT6 and IPv6 UL, UMU, UCL,
Mandat
International,
HESSO
17/7/2014 Frankfurt Moderator Home and Building
Web Service
Interface
Specification
VUT
Table 1 – Participation in Standardisation Organisation Meetings
D8.3.3 Standardization Activities and Efforts
17
3. Conclusion
The IoT6 project has participated directly and led some initiatives in the strategic standardisation
bodies such ETSI, the IETF, ITU and IEEE ComSoc and standards influencing projects such as
the IoT Forum and the IERC Cluster.
The creation of the ETSI IP6 ISG and the IEEE ComSoc IoT/5G/SDN-NFV as well as the IoT
Forum and IERC will contribute to the dissemination of Best Practices beyond the project
lifetime with a strategic sustainability vision and also beyond IoT including pre-standardisation
efforts of IoT or MTC for 5G networks.
Some lasting impacts in this area are:
Leading the adoption of IPv6 as key communication protocol
Winning ETSI’s support to lead the ETSI IP6 ISG.
Leading the IoT Forum.
Leading the IEEE ComSoc IoT subcommittee.
Contributing to the IoT Book for the 4th
time.
Leading the IoT Week program.
Chairing many conferences and invited as speakers in standardisation.
D8.3.3 Standardization Activities and Efforts
18
4. Annexes
4.1. Annex I – ETSI ISG IP6 (first 6 pages from 15)
D8.3.3 Standardization Activities and Efforts
19
D8.3.3 Standardization Activities and Efforts
20
D8.3.3 Standardization Activities and Efforts
21
D8.3.3 Standardization Activities and Efforts
22
D8.3.3 Standardization Activities and Efforts
23
4.2. Annex II – IoT Standardisation Chapter, IERC Book 2014
(first 2 pages from 56)
D8.3.3 Standardization Activities and Efforts
24
D8.3.3 Standardization Activities and Efforts
25
4.3. Annex III – Handle System
4.3.1. Some Features of the Handle System
The following description of HS features is not an exhaustive list. We discuss features that we
believe are pertinent to IoT applications and where the HS architecture can provide the necessary
infrastructure and network operations to make these applications a reality with the least effort. In
addition, the infrastructure satisfies many of the requirements of the IoT architectures and in
particular, many of the desired functions of the IoT6 architecture.
4.3.2. Handles as Persistent Identifiers
Handles are persistent identifiers for Internet resources. A handle does not have to be derived in
any way from the entity that it names – the connection is maintained within the Handle System.
This allows the name to persist over changes of location, ownership, and other ‘current state’
conditions. When a named resource moves from one location to another, e.g., from an old server
to a new server, the handle is kept current by updating its value in the Handle System to reflect
the new location.
The Handle system is designed to meet the following requirements for persistence.
Handles are:
Not based on any changeable attributes of the entity they identify (location, ownership, or
any other attribute that may change over time);
Opaque, preferably ‘dumb numbers’ from which no potentially confusing meaning can be
drawn, and from which no assumptions about ownership or use can be made;
Unique within the Handle System, avoiding collisions and referential uncertainty;
Easy to make user friendly, human-readable, cut-and-paste-able, and can be embedded, if
needed;
Easily fit into common systems, e.g., URI specification.
Handle resolution is:
Reliable, using redundancy, with no single points of failure and resolution time fast
enough never to appear broken;
Scalable, so that higher loads are easily managed with more computers;
Flexible and easily adapted to changing computing environments and new applications;
Trusted, with both resolution and administration built on proven trust methods;
Built on an open architecture that encourages the community of users to build
applications on top of the infrastructure;
Transparent to users who don't need to know the infrastructure details.
The above requirements for persistence fit most, if not all, the requirements of IoT architectures,
including IoT6. In particular, where IETF-compliant standards have been defined for IoT
operations, such as the CoRE group’s specifications of link formats and CoAP operations based
on URIs, the above features cover all these aspects.
4.3.3. Handle Syntax
Within the Handle namespace, every identifier consists of two parts: its Handle prefix, and a
suffix or unique “local name” under the prefix. The prefix and suffix are separated by the ASCII
character “/”. An identifier may thus be defined as
<handle> ::= <handle prefix> “/” <handle suffix>
D8.3.3 Standardization Activities and Efforts
26
4.3.4. Handle Resolution and relevance to IoT applications
The Handle System allows identifiers (Handles) to be resolved in a distributed fashion, using
dedicated clients, common clients such as web browsers using special extensions or plug-ins, or
un-extended clients going through various proxies. In all cases, communication with the Handle
System is carried out using Handle System protocols, and in all cases, those protocols have both
a formal specification and some specific implementations.
4.3.5. Administering Handles – Security Provisions and Implications
Conducting handle administration (i.e., creating, modifying, and deleting individual Handles)
requires that you authenticate yourself to the Handle System. To authenticate yourself, you need
to have an ID that uniquely identifies you, and since the Handle System is global in nature, your
ID must also be globally unique. Since globally unique identifiers are the Handle System’s
specialty, it is natural that administrators should be identified by Handles.
An administrator handle contains either a public key or a secret key (password) that authenticates
the individual identified by that handle. If an administrator handle is specified with permission to
perform some operation in the Handle System, then that administrator can perform that operation
as long as he can authenticate himself against the public or secret key in the administrator
handle.
The above descriptions clearly define the access control mechanisms embedded into Handle
systems, which can be suitable to the IoT. The mechanisms provide a strong framework for
authentication and authorisation that can be extended to operate in a M2M environment,
involving gateways or end-nodes of an IoT subsystem and the Handle infrastructure (see details
in Figure 1).
Where the nodes of an IoT subsystem are involved, further DTLS-based provisions can be
applied to create secure end-to-end transactions (noted as green curved arrows). In particular, the
CoAP DeviceNet-side access to the Handle infrastructure is not mandated to be secure, therefore
we foresee use of DTLS when CoAP-enabled Handle proxies are used for interaction towards a
Handle Service (i.e., from DeviceNets to the ServiceNet and from DeviceNets to the Internet).
Figure 1: Secure end-to-end handle administration from DeviceNets to the Internet.
D8.3.3 Standardization Activities and Efforts
27
4.3.6. Handle System Scalability
Scalability has been a fundamental requirement and design criterion for Handle. It reflects on
storage and performance issues. We examine each separately below.
The basic questions to address are whether some limits exist in the number of identifiers that can
be added and whether performance decreases with the number of Handles served.
Scalability can be a relatively subjective issue. It may be addressed differently at design stage or
at implementation phase. A design that is fundamentally scalable, may exhibit problems with a
specific implementation instance.
Furthermore, the use of intermediary services, such as http proxies, may introduce other
scalability issues, which the basic Handle System design does not and cannot address.
4.3.7. Storage scalability
The Handle System has been designed at a very basic level as a distributed system; that is, it will
run across as many computers and domains as are required to provide the desired functionality.
There are three architectural concepts that have been implemented in Handle to satisfy storage
scalability: Handle Servers, Handle Sites and Handle Services.
Figure 2: Logical separation of Handle Service to Servers and Sites
As shown in Figure 2, Handles are held in, and resolved by, Handle servers and the servers are
grouped into one or more Handle sites within each Handle service. There are no design limits on
the total number of Handle services which constitute the Handle System, there are no design
limits on the number of sites which make up each service, and there are no limits on the number
of servers which make up each site. Replication by site, within a Handle service, does not require
D8.3.3 Standardization Activities and Efforts
28
that each site contain the same number of servers; that is, while each site will have the same
replicated set of Handles, each site may allocate that set of Handles across a different number of
servers. Thus, increased numbers of Handles within a site can be accommodated by adding
additional servers, either on the same or additional computers, additional sites can be added to a
Handle service at any time, and additional Handle services can be created. Every service must be
registered with the Global Handle Registry, but that Handle service can also have as many sites
with as many servers as needed.
The result is that the number of identifiers that can be accommodated in the current Handle
System is limited only by the number of computers available.
4.3.8. Security aspects
In the previous section, we discussed how the architecture ensures the administration, storage
and access of Handles can be secured (Section 0). To implement the secure functions, the Handle
server uses cryptographic libraries that come with Java v.5 distribution (called Sun Java™
Cryptography Extension and Provider). We revisit and analyse below the key security aspects of
the system implementation.
4.3.9. Authentication
The Handle System provides two forms of authentication: public key and secret key. The system
can authenticate all administrators of the Handles stored in its database, main and delegated
administrators in the hierarchical chain of prefixes and identifiers, allowing for fine-grained
control of each structure.
Handle clients can request that a handle server cryptographically certify its messages with its
public key. This certification can be used to verify the authenticity of handle server
transmissions. The current implementation of the Handle System uses DSA for this purpose. The
DSA public key for a handle server is stored in its site information record.
4.3.10. Security Services in Handle
There are two important differences, and one similarity, between the security services provided
in Handle from those in the DNS (with its DNSSEC extension). Both have the same constraints
on entry creation, deletion and replication. Both require strong authorisation with specific
administration credentials. Both provide proof of source and integrity. However, Handle has two
additional features: session services and access control.
Handle allows a client to establish secure sessions with a server for encrypted communication.
This functionality is permitted for example when operating in batch execution mode. This is
equivalent to using SSL or TLS (as used by HTTPS), as it affords protection from eavesdropping
and man-in-the middle attacks (currently encrypting sessions using 56 bit DES).
Handle also can require credentials to permit access to the contents of the Handle. This feature is
very important for IoT, for two reasons. First the attributes of the Handle may reveal properties
of the DO that should be protected information. Second, by requiring fine-grained authorisation
to access of the Handle contents, one can greatly simplify the authorisation needs in the IoT
processes. Provided the relevant access is vouched for by the Handle-provided credentials, no
further authorisation is required.
D8.3.3 Standardization Activities and Efforts
29
4.3.11. Handle Value Types
A handle has a set of values assigned to it and may be thought of as a record that consists of a
group of fields. Each handle value must have a data type specified in its <type> field that defines
the syntax and semantics of its data, and a unique <index> value that distinguishes it from the
other values of the set.
Types are identified by handles and can be any UTF8-string. Handle System users must take care
of potential conflicts introduced by custom handle clients if users assign types that are not
registered and recognised across the global handle infrastructure.
In IoT applications, one would probably specify a set of data types that are common in the
application domain or technology registered in the Handle System serving the IoT domain. For
example, a particular building management infrastructure may employ a standardised legacy
DeviceNet, such as a KNX or LonWorks set of A/C units. These may come pre-arranged in a
networked configuration with proprietary communications (signalling) protocols.
4.3.12. Template Handles
A single template Handle can be created as a base that will allow any number of extensions to
that base to be resolved as full Handles, according to a pattern, without each such Handle being
individually registered. This would allow, for example, the use of Handles to reference an
unlimited number of resources or service endpoints in a building (lights, switches, sockets, etc.,
as exhibited by sensor measurements, actuation and other operations) without each potential
resource or service having to be registered with a separate handle. If the pattern needs to be
changed, e.g., a light bulb moves location or a different kind of server is used to deliver the
building’s resources, only the single base handle needs to be changed to allow an unlimited
number of previously constructed extensions to continue to resolve properly.
D8.3.3 Standardization Activities and Efforts
30
4.4. Annex IV – IETF Standardisation Efforts
6lo G. Rizzo, Ed.
Internet-Draft AJ. Jara, Ed.
Intended status: Standards Track A. Olivieri
Expires: February 15, 2015 Y. Bocchi
HES-SO
MR. Palattella
SnT/Univ. of Luxembourg
L. Ladid
SnT/Univ. of Luxembourg/IPv6 Forum
August 14, 2014
IPv6 mapping to non-IP protocols
draft-rizzo-6lo-6legacy-01
Abstract
IPv6 is an important enabler of the Internet of Things, since it
provides an addressing space large enough to encompass a vast and
ubiquitous set of sensors and devices, allowing them to interconnect
and interact seamlessly. To date, an important fraction of those
devices is based on networking technologies other than IP. An
important problem to solve in order to include them into an
IPv6-based Internet of Things, is to define a mechanism for assigning
an IPv6 address to each of them, in a way which avoids conflicts and
protocol aliasing.
The only existing proposal for such a mapping leaves many problems
unsolved and it is nowadays inadequate to cope with the new scenarios
which the Internet of Things presents. This document defines a
mechanism, 6TONon-IP, for assigning automatically an IPv6 address to
devices which do not support IPv6 or IPv4, in a way which minimizes
the chances of address conflicts, and of frequent configuration
changes due to instability of connection among devices. Such a
mapping mechanism enables stateless autoconfiguration for legacy
technology devices, allowing them to interconnect through the
Internet and to fully integrate into a world wide scale, IPv6-based
IoT.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
D8.3.3 Standardization Activities and Efforts
31
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Rizzo, Ed., et al. Expires February 15, 2015 [Page 1]
Internet-Draft 6TONon-IP August 2014
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Example 1 - Building automation systems and IoT . . . 4
2.1.2. Example 2 - KNX and demand-side management . . . . . 5
3. Reference System . . . . . . . . . . . . . . . . . . . . . . 5
4. Issues addressed through the 6TONon-IP mapping mechanism . . 6
5. 6TONon-IP Mapping Method . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Example 1 - EIB/KNX . . . . . . . . . . . . . . . . . . . 9
6.2. Example 2 - RFID . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
D8.3.3 Standardization Activities and Efforts
32
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Rizzo, Ed., et al. Expires February 15, 2015 [Page 2]
Internet-Draft 6TONon-IP August 2014
2. Introduction
The Future Internet and the IPv6 protocol enable a new generation of
techniques for accessing the network, which extend the Internet
seamlessly to personal devices, sensors, home appliances, enabling
the so called ''Internet of Things'' (IoT). One of the key issues
which presently hampers the development of IoT and limits its
potential is the lack of an efficient common framework for the
integration among the vast and diverse set of protocols and
technologies which compose it. Current sensors and their application
environments employ a large set of technologies which lack efficient
interoperability. Some associations of manufacturers have been
formed to build a common technological framework in specific
application domains, e.g. KNX for building automation
(http://www.knx.org/), ZigBee (ZigBee Alliance)
(http://www.zigbee.org/), and protocols such as X10 and CAN. Such
frameworks are based on very different architectures, and the
protocols which compose them are generally not interoperable.
Finally, most of these technologies were designed in a context of
small and local networks, with limited capabilities, and they were
not conceived for integration within the Internet. One of the ideas
at the basis of the IoT is the constitution of a common set of
protocols which enables the interaction between devices through the
Internet. By enabling interaction through the Internet, new services
could be conceived and implemented, increasing the value produced by
the IoT infrastructure. The adoption of a common framework may make
more economically convenient its deployment, and foster the
development of new smart environments (buildings, cities, etc),
ultimately making possible the full realization of the potential of
the IoT. As deployment of new sensors is typically expensive, it is
unthinkable of putting to disuse an installed set of sensors, once a
new set of devices (typically, IPv6 enabled) is deployed. This is
not an uncommon case, as the set of deployed legacy devices (sensors,
actuators) is to date very large. Rather, mechanisms are needed to
integrate legacy devices into a common IoT platform, in order to
include them in all the present and future services (e.g. devices and
services directory, localization services, etc) which will be
implemented on the IoT. For these reasons, many designers of the
Internet of Things are focusing on building such common access and
D8.3.3 Standardization Activities and Efforts
33
communications framework. All the proposals (e.g. CoAP, RESTful Web
services) presently under discussion are based on IPv6. This has
important implications on the addressing of the devices. Indeed a
common addressing at the device level is mandatory, in order to
implement true Machine to Machine (M2M) communications without Portal
Servers, which would make the whole system difficult to integrate and
scale. The present document focuses on the network layer aspects of
such IPv6 based integration. At the network layer, a mechanism which
assigns an IPv6 address to each device is needed, to solve the
Rizzo, Ed., et al. Expires February 15, 2015 [Page 3]
Internet-Draft 6TONon-IP August 2014
addressing problem. In this document, we propose a new mechanism for
the users and devices to map the different addressing spaces to a
common IPv6 one. Our proposed mechanism solves several issues posed
by some of the mappings adopted so far. Such mapping makes it
possible for every device from each technology to operate through a
common framework based on IPv6 and protocols over IPv6 such as
RESTFul WebServices and Constrained Application Protocol (CoAP). For
each technology, the proposed mechanism maps technology-specific
features to a set of fields defined within the IPv6 address. This
allows the location and identification of the devices in a multi-
protocol card, or in any gateway or Portal Server.
2.1. Examples
In this subsection, we present two examples which help understanding
the importance of adopting a common IPv6 based framework for
interaction between things, and the need for legacy devices to be
individually addressable through IPv6.
2.1.1. Example 1 - Building automation systems and IoT
The IoT is composed by a very large set of devices, which is poised
to grow exponentially in the near future. For this reason, a
directory service is needed, which offers the possibility to
individuate a specific device or set of devices, with given
capabilities or within a given geographical region. Let us assume
such directory lists devices with their IPv6 addresses, and their
function (say a temperature sensor, or a mobile phone, etc). For
instance, let us consider the case of someone willing to build a map
of temperatures in a given geographical region. Such directory
service would allow retrieving the list of available devices within
that region, each with its own IPv6 address. Assume some of those
devices are legacy, non IP based temperature sensors and part of a
given building automation system. Assume also that such system
manages several of those temperature sensors. Even if such system
D8.3.3 Standardization Activities and Efforts
34
would be reachable via IP, without having those sensors individually
listed in the directory and appearing as ''autonomous'' things, which
can be polled directly, one should resort to techniques for
retrieving the temperature reading of those sensors which are
specific of that building automation technology. This would make
more complex the implementation of such a temperature map.
Instead, by having the building automation system expose each sensor
as an IPv6 enabled device, the whole set of temperature sensors would
be accessible in a homogeneous way, greatly simplifying the task.
Rizzo, Ed., et al. Expires February 15, 2015 [Page 4]
Internet-Draft 6TONon-IP August 2014
2.1.2. Example 2 - KNX and demand-side management
KNX is a standardized (EN 50090, ISO/IEC 14543), OSI-based network
communications protocol for intelligent buildings. Among the devices
typically managed through KNX, we find:
o Lighting control systems;
o Heating/ventilation and air conditioning devices;
o Shutter/blind and shading control systems; and
o Energy management and electricity/gas/water metering devices.
KNX devices do not support IP. Therefore, in order to connect a KNX
home network to the Internet, a gateway (KNXnet/IP router) is
necessary. Other technologies for home automation are available
nowadays, in which each smart device (air conditioners, washing
machines, etc) supports IPv6. Let us consider a scenario in which an
utility company offers an agreement to a fraction of its clients. In
exchange for a cut on the energy bill, the utility company gains
direct control over some appliances at the premises of the client.
In this way, by powering off some of those devices in periods when
the production cost of power are very high, the utility company
realizes potentially high savings.
In order to implement this, the utility company sends commands to a
set of devices under its direct control. For recently installed
devices, the utility can assume that they support IPv6, and some
application layer protocols such as CoAP. Therefore a command to
switch off a device would use the IPv6 address to identify the
device, and the application layer protocol to send the actual
command. But for KNX devices, the command should have another
format: the IPv6 address should be the one of the router bridging the
D8.3.3 Standardization Activities and Efforts
35
IPv6 and the KNX networks, and upper layers protocols should take
care of identifying the specific device inside the KNX home network
to whom the command should be sent. Having to format a specific
query for each specific home automation protocol adds a level of
complexity which translates into higher costs of implementation and
maintenance of such a service.
3. Reference System
In this section we describe a reference system where the IPv6 mapping
is used. Such a system includes:
1. A set of networks running non-IPv6-compatible technologies, each
with one or more hosts connected. Such networks generally use
Rizzo, Ed., et al. Expires February 15, 2015 [Page 5]
Internet-Draft 6TONon-IP August 2014
different OSI layer 3 protocols, or they may adopt a technology
which does not have any layer 3 protocol.
2. A proxy, which hosts the IPv6 mapping functionality. Such device
is typically connected to each of the legacy protocols networks,
and it accesses the Internet via the IPv6 protocol. Such IPv6
addressing proxy performs all the necessary conversions and
adaptations between IPv6 and the (local) networking protocol of
the legacy technologies, in a way which depends on the specific
legacy technology considered. This proxy makes use of the IPv6
mapping mechanism in order to transforms the native addressing to
IPv6 Host ID and vice versa in a way that depends on the legacy
technology.
Though in what follows we will describe the proposed mapping with
reference to such a system, the main ideas behind it are more
general, and they apply to settings others than the one of reference
presented here.
4. Issues addressed through the 6TONon-IP mapping mechanism
In this section we highlight the main open issues regarding
assignment of IPv6 addresses to devices which do not support IPv6 or
IPv4, and we describe a set of desirable properties for a mechanism
for automatic assignment of IPv6 addresses to such devices, which we
name henceforth 6TONon-IP. In Appendix A of RFC 4291, a method is
described for creating modified EUI-64 format Interface Identifiers
out of links or nodes with IEEE EUI-64 Identifiers, or with IEEE 802
48-bit MACs. Moreover, for technologies having other link layer
interface identifier, some possible mapping methods are sketched,
D8.3.3 Standardization Activities and Efforts
36
leaving for each legacy protocol the possibility to define its own
mapping method.
In the present document, we propose a mapping mechanism which enables
stateless address autoconfiguration for legacy technologies, and
which exploits some protocol specific identifier such as link layer
interface identifiers, and the like. The proposed mapping mechanism
addresses the following issues:
1. Protocol identification: For the legacy protocols to which the
mapping described in RFC 4291 does not apply, a mechanism is
needed to map an IPv6 address to the right legacy protocol. This
feature is necessary in case of devices which operate as proxy
for more than one legacy technology at the same time.
2. Inter protocol aliasing: Without a mechanism for identifying the
legacy protocol from the host part of the IPv6 address, address
conflicts are possible among devices belonging to different
Rizzo, Ed., et al. Expires February 15, 2015 [Page 6]
Internet-Draft 6TONon-IP August 2014
legacy protocols. For instance, this may happen when the link
layer interface identifier is the same for two devices belonging
to different technologies. As several legacy technologies are
characterized by a small addressing space, address conflicts are
not so unlikely.
3. Conflicts between IPv6 mapped legacy technology addresses and
addresses derived from (modified or not) EUI-64 format interface
identifiers.
4. Intra-protocol aliasing: As several legacy technologies are
characterized by a small addressing space, it is not unlikely to
have two legacy devices, mapped to IPv6 addresses with the same
network ID (for instance, in the case in which they belong to two
separate networks of the same technology, both connected to a
same proxy), and with a same interface identifier, and mapping
therefore to a same IPv6 address.
Moreover, the following is a list of desirable properties for a
6TONon-IP mapping:
1. Consistency: A host should get the same IPv6 address every time
it connects to a same legacy network, assuming that the
configuration of all the other devices in that network remains
unchanged. This allows avoiding to advertise a new address every
time the host reconnects. This feature might be particularly
D8.3.3 Standardization Activities and Efforts
37
important for devices which are not always "on", or which are not
permanently connected.
2. Local Uniqueness: For devices which have an IPv6 address with a
same network part, the host part should be unique for each host.
This property allows avoiding address conflicts.
3. Uniqueness within the whole Internet: Coherently with the IoT
vision, the host part of an IPv6 address associated to a host
should be unique within the whole Internet.
Depending on the specific legacy protocol, there might be protocol
specific limitations to the satisfaction of these properties. In
particular, for those protocols which do not have an interface
identifier which is unique, properties 1) and 2) cannot be fully
satisfied. Indeed, no mapping can solve address conflicts which take
place inside a legacy protocol network. When legacy protocols have a
interface identifier which is unique, this can be used to produce a
unique host part of an IPv6 address, and its uniqueness would
guarantee the satisfaction of properties 1), 2) and 3).
Rizzo, Ed., et al. Expires February 15, 2015 [Page 7]
Internet-Draft 6TONon-IP August 2014
5. 6TONon-IP Mapping Method
In this section we describe the proposed strategy for forming IPv6
addresses from legacy protocol information, and the address format
that derives from it. We assume that (one or more) 64 bits Network
ID prefixes are given to the mapping function, which therefore
computes the 64 bits of the Host ID part of the address (IPv6
interface identifier), in order to form a full IPv6 address.
The input of the proposed mapping function consists in the interface
identifier of the legacy protocol.
In the proposed mapping method, the resulting Host ID part (IPv6
interface identifier) is composed by six fields, as shown in
Figure 1:
o A Technology ID field (11 bits), containing a code which
identifies the specific legacy protocol. This field is split into
two parts, one of 6 bits, and another of 5 bits.
o U/L bit (1 bit), in order to keep compatibility with the mapping
EUI-64 [RFC4291]. The U/L bit is the seventh bit of the first
byte and is used to determine whether the address is universally
or locally administered. This bit is set to "0", in order to
D8.3.3 Standardization Activities and Efforts
38
indicate local scope, analogously to what proposed in [RFC4291].
This choice prevents address conflicts with IPv6 interface
identifier generated from IEEE EUI-64 identifiers or IEEE 48-bit
MAC identifiers.
o A Reserved field (4 bits). This field can be used in the future
for the identification of different interfaces for a same
technology (in the same subnetwork).
o Technology Mapping field (32 bits), which maps the interface
identifier of the legacy protocol. For those protocols for which
the IID is not larger than 32 bits, this field contains the 32
bits of the IID. For IID which are larger than 32 bits, a hashing
function is used instead of direct mapping. In particular, some
hashing algorithms such as CRC-32 are suggested. Hashing
satisfies the requirements of consistency and uniqueness within a
subnet with a very high probability, which depends on the hashing
algorithm used. This field is split into two parts, one of 8
bits, and another of 24 bits.
o The fourth and fifth bytes are both set to to "0x00", in order not
to conflict with EUI-64 interface identifiers.
Rizzo, Ed., et al. Expires February 15, 2015 [Page 8]
Internet-Draft 6TONon-IP August 2014
The resulting format of the Host ID part of the IPv6 address obtained
from the mapping is indicated in Figure 1.
+--------+-------+-------+---------+--------+----------+---------+
| Tech. | U/L | Tech. | Reserved| Tech. | EUI-64 | Tech. |
| ID | "0" | ID | | Mapping| "0x0000" | Mapping |
| MSB | | LSB | | MSB | | LSBs |
|(6 bits)|(1 bit)|(5 bit)| (4 bits)|(8 bits)| (16 bits)|(24 bits)|
+--------+-------+-------+---------+--------+----------+---------+
Figure 1: general format of the host ID part for legacy protocols
6. Examples
In this section we illustrate the proposed mapping method by applying
it on some examples.
6.1. Example 1 - EIB/KNX
We assume the legacy protocol is EIB/KNX. This device has two kind
of addresses: On the one hand, a logical address for management of
group operations, and on the other hand, an individual address for
D8.3.3 Standardization Activities and Efforts
39
identification of the device in the topology.
The mapping will be focused for the individual address. This
includes an Area ID (4 bits), Line ID (8 bits), and Device ID (8
Bits). An example, is the value 0x1/0x01/0x01 for a sensor connected
in the Area ID 0x1, Line ID 0x01, and Device ID 0x01.
We apply a hash (CRC-32) to the sequence 0x10101. The result is
0xDEA258A5.
Let us assume that EIB/Konnex Technology ID is "0". Thereby, the
IPv6 interface identifier is "0000:DE00:00A2:58A5", considering the
documentation network 2001:db8::/32. The final IPv6 address for the
legacy device is "2001:db8::DE00:A2:58A5".
The address is presented in the Figure 2.
+--------+-------+-------+---------+--------+----------+---------+
| Tech. | U/L | Tech. | Reserved| Mapping| EUI-64 | Mapping |
| ID MSB | "0" | ID LSB| | MSB | "0x0000" | LSBs |
|(6 bits)|(1 bit)|(5 bit)| (4 bits)|(8 bits)| (16 bits)|(24 bits)|
| 0x00 | 0 | 0x00 | 0x00 | 0xDE | 0x0000 | 0xA258A5|
+--------+-------+-------+---------+--------+----------+---------+
Figure 2: EIB/KNX example: the IPv6 interface identifier.
Rizzo, Ed., et al. Expires February 15, 2015 [Page 9]
Internet-Draft 6TONon-IP August 2014
6.2. Example 2 - RFID
We assume the legacy protocol is RFID. Each RFID device is
identified by its Electronic Product Code (EPC), whose length may
vary from 96 to 256 bits. Let us assume to have an RFID device whose
EPC is given by 01.23F3D00.8666A3.000000A05 (12 bytes). Let us
assume that the RFID technology ID is "1".
We apply a hash (CRC-32) to the sequence 0x0123F3D008666A3000000A05.
The result is 0xA93AFFA0.
Thereby, the IPv6 interface identifier is "0004:A900:003A:FFA0",
considering the documentation network 2001:db8::/32. The final IPv6
address for the RFID tag is "2001:db8::400:A900:3A:FFA0".
The address is presented in the Figure 2.
+--------+-------+-------+---------+--------+----------+---------+
| Tech. | U/L | Tech. | Reserved| Mapping| EUI-64 | Mapping |
D8.3.3 Standardization Activities and Efforts
40
|ID MSB | "0" | ID | | MSB | "0x0000" | LSBs |
|(6 bits)|(1 bit)|(5 bit)| (4 bits)|(8 bits)| (16 bits)|(24 bits)|
| 0x00 | 0 | 0x04 | 0x00 | 0xA9 | 0x0000 | 0x3AFFA0|
+--------+-------+-------+---------+--------+----------+---------+
Figure 3: RFID example: the IPv6 interface identifier.
7. IANA Considerations
Not yet defined.
8. Security considerations
The proposed mapping mechanism, being based on mapping proprietary
protocol ID, results in such ID being incorporated in the final IPv6
address, exposing this piece of information to the Internet. The
concern has been that a user might not want to expose the details of
the system to outsiders. For such concern, which holds also for MAC
address mapping into EUI64 addresses, please refer to appendix B in
[RFC4942].
9. Acknowledgements
The authors wish to acknowledge the following for their review and
constructive criticism of this proposal: Robert Cragie. Thanks to
the IoT6 European Project (STREP) of the 7th Framework Program (Grant
288445), and the colleagues who have collaborated in this work. In
particular, Antonio Skarmeta from the University of Murcia, Peter
Rizzo, Ed., et al. Expires February 15, 2015 [Page 10]
Internet-Draft 6TONon-IP August 2014
Kirstein and Socrates Varakliotis from the University Colleague
London, and Sebastien Ziegler from Mandat International.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[SENSORS] Jara, A., Moreno-Sanchez, P., Skarmeta, A., Varakliotis,
S., and P. Kirstein,, "IPv6 Addressing Proxy: Mapping
Native Addressing from Legacy Technologies and Devices to
the Internet of Things (IPv6)", Sensors 13, no. 5,
6687-6712, 2013, 2013.
D8.3.3 Standardization Activities and Efforts
41
Authors' Addresses
Gianluca Rizzo, Ed.
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Phone: +41-76-6151758
Email: [email protected]
Antonio J. Jara, Ed.
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Email: [email protected]
Alex C. Olivieri
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Email: [email protected]
Rizzo, Ed., et al. Expires February 15, 2015 [Page 11]
Internet-Draft 6TONon-IP August 2014
Yann Bocchi
HES-SO Valais
Technopole 3
Sierre, Valais 3960
Switzerland
Email: [email protected]
Maria Rita Palattella
University of Luxembourg
4, rue Alphonse Weicker
Interdisciplinary Centre for Security, Reliability and Trust
Luxembourg
Phone: (+352) 46 66 44 5841
Email: [email protected]
D8.3.3 Standardization Activities and Efforts
42
Latif Ladid
University of Luxembourg / IPv6 Forum
4, rue Alphonse Weicker
Interdisciplinary Centre for Security, Reliability and Trust
Luxembourg
Phone: (+352) 46 66 44 5720
Email: [email protected]
Rizzo, Ed., et al. Expires February 15, 2015 [Page 12]