IETFにおけるM2M/IoTの動向

IETF におけるM2M/IoT の動向

Shoichi Sakane
Cisco Systems
21-Dec-2012

ISOC-JP IETF85報告会
Presentation_ID © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1

本日の流れ

  IETFにおけるM2M/IoT関連の背景
M2Mアプリケーションや
スマートグリッドからの要求事項

  IETFにおける
M2M/IoT関連技術の標準化動向


本日の対象エリア M2M/IoTアーキテクチャ例
Fog Computing, Cisco

Data Center Cloud
Network Management Applications
Application Hosting,
Management,
IoT Analytics

Core Networking
IP/MPLS, QoS,
Multicast, Security

Multi-Service Edge
3G, 4G, LTE, WiMAX, WiFi
Ethernet

Embedded Systems
and Sensors HERE !!
Low power & bandwidth,
Machines Wired or Wireless


Agenda

 M2M/IoTに関連した背景
 技術の標準化動向


Agenda



M2M/IoTのアプリケーションやネットワークの多様化
Improve Predictive
Enhanced
Productivity Maintenance
Safety &
Security

Healthcare Improve Food
Data Center and H2O
Energy
Saving

High-Confidence Intelligent
Transport and Buildings
Asset Tracking

Smart Grid
Smart House
Smart
Community

Presentation_ID M2M/IoTソリューションの水平統合への期待
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 6

スマートグリッドを構成する様々なシステム（米国）
電力取引市場
送配電制御
通信事業者

大型発電所

送電網
配電網
需要家
NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0, NIST, Jan 2010

スマートグリッドの通信システムの要求事項
 異なる伝送メディア・リンク技術の相互接続の必要性

スマートグリッド通信システムの要求事項

 リンク技術に依存しないアドレス体系
 リンク技術に依存しないメッセージ配送技術
 リンク技術に依存しないセキュリティ技術
 多様な伝送メディア・リンク技術の相互接続性
The role of standards in the Smart Grid: an IETF view, Fred Baker

IP技術の通信スタック構造
IP技術の通信スタック（概念図）

Web, E-Mail, Voice, Video, Management, …
 データリンク技術と完全に分離
HTTP, CoAP, SNMP, DHCP, DNS, …

TCP, UDP
各層に・・・
 アドレス体系
IP
 メッセージ配送機能
Ethernet, WiFi, BACnet/IP, PLC, …
 セキュリティ機能
UTPケーブル, 光ケーブル, 無線, 電力線, …
 選択可能な暗号技術



柔軟性と拡張性に優れたIP技術
222ヶ国, 54459 ASs
(May 2011, World Autonomous System Number Statistics)

約５０億台
AS
（Aug-2010, IMS Research）
AS

AS
AS

Internet World Map 2007
自律分散協調システム（概念図）
The ISC Domain Survey

実証されたIP技術の特性

 多様な伝送メディア・リンク技術が相互に接続。
 地球規模のスケールで実運用されている。
 自律分散システムであり障害に強い。

スマートグリッドの通信システムの要求事項と
IP技術の親和性
スマートグリッド通信システムの要求事項
実証されたIP技術の特性


 多様な伝送メディア・リンク技術が相互に接続。
 地球規模のスケールで実運用されている。
 自律分散システムであり障害に強い。

センサー網の多様性と非相互接続性
  Zigbee, Z-Wave, Xmesh, SmartMesh, MeshScape, …
 互換性のないプロトコル
 下位から上位層まで１つのスタック
 閉鎖的なアーキテクチャ
  GWの乱立
 開発・導入・メンテナンスコストの増大
 スケーラビリティの欠如
 一貫した経路制御が不可能
 本質的に複雑なアーキテクチャになり普及が困難
 センシング情報の共有化が困難

GW
GW
GW
GW
GW
GW
GW
GW
GW
GW
GW
GW
GW


センサー網の多様性と非相互接続性
  Zigbee, Z-Wave, Xmesh, SmartMesh, MeshScape, …
 互換性のないプロトコル
 下位から上位層まで１つのスタック
 閉鎖的なアーキテクチャ
  GWの乱立
 開発・導入・メンテナンスコストの増大
 スケーラビリティの欠如
 一貫した経路制御が不可能
 本質的に複雑なアーキテクチャになり普及が困難
 センシング情報の共有化が困難

TCP/IP

Presentation_ID M2M/IoT網の統合運用への期待
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 13

IP技術の策定過程と相互接続性
www.ietf.org
  ＩＥＴＦ
インターネット技術全般の標準化を行う組織。
策定した技術はRFCとして発行され、誰でも自由に参照できる。
会社や国の代表としてではなく原則として個人で参加する。
８エリア、１２４WG

  仕様は全てオープン
全ての議論や文書が公開されている。
誰でも自由に議論に参加でき文書を発行できる。

  動作実績のある仕様と相互接続性が最も重要
“We reject kings, presidents and voting. We believe in
rough consensus and running code”,
Dave Clark (1992)


センサー網におけるIP技術の主な4つの課題
  動作条件の厳しい通信機器の存在 Challenge Areas
省電力
物理的サイズ（5mm〜）新しいリンクに対
応する適合層の
低CPU性能（8 or 16-bit, 低クロック 8~16MHz）標準化
少ないメモリ（~128 KB）
スリープモード
耐障害性経路制御
これらの特徴を持つ機器をIETFでは “Smart Object” と呼んでいる
プロトコルの標準化
  通信条件の厳しいネットワークの存在
多数のノード（〜数千ノード） LLN向け汎用アプリ
ケーションプロトコル
低通信帯域（〜250kbps）
の標準化
高パケット損失性
技術者が直接メンテナンスできない環境
LLN向け機器の実
これらの特徴を持つネットワークをIETFでは
“LLN” （Low power and Lossy Network）装ガイド
低消費電力＆高パケット損失ネットワーク
と呼んでいる

LLNに関するIETFの動向
Smart Object Lifecycle Architecture
for Constrained Envinronments
LLN向け機器の実装 IETF85, Mar 2012
ガイド
Lightweight Impl.
lwig WG
IETF80, Mar 2011
Management of Constrained
Networks and Devices
Smart Objects Workshop IETF85, Nov 2012
IETF80, Mar 2011

Cross Layers Issues BoF Low power and
IETF82, Nov 2011
Lossy Networks Constrained
roll WG Envinronments
IETF71, Mar 2008
core WG
IPv6 over LoWPAN IETF76, Nov 2009
6lowpan WG Z-Wave
IETF61, Nov 2004
Low Power WiFi
Zigbee IP
PLC
LoWPAN
LLN向け汎用アプリ
耐障害性経路制の標準化
新しいリンクに対応す
御プロトコルの SmartGrid Bar-BoF,
る適合層の標準化
IoT Bar-BoF,
標準化
Autumn 2009
Spring 2010

Zigbee & WiFi
IEEE802.15.4-2003, EISA ACT, 2007
Zigbee/HomePlug, OpenSG/UCAlug,
Autumn 2008
Summer 2009
collaboration,
Autumn 2003
Sprint 2010

Agenda



What is 6lowpan WG?
  IPv6 over Low power Wireless Personal Challenge Areas
Area Networks
Co-chairs: 新しいリンクに対
Carsten Borman (Bremen Univ.) 応する適合層の
Geoff Mulligan (Consultant) 標準化

  Mission
802.15.4-basedネットワークに対する、IPv6 耐障害性経路制御
Adaptation Layerの策定とIPv6仕様の拡張プロトコルの標準化

  RFCs and Significant Documents
RFC 4919: Problem Statement, and Goals ケーションプロトコル
RFC 4944: Transmission of IPv6 Packets の標準化
RFC 6282: Compression Format
RFC 6568: Design and Application Spaces LLN向け機器の実
RFC 6775: 6lowpan Neighbor Discovery 装ガイド


What are 6lowpan protocols ?
  802.15.4ベースのL2リンクとTCP/IP技術のギャップを埋める。
当初は、802.15.4-2006が対象だった。
現在は、IEEE P1901.2や IEEE 802.15.4k等への応用も検討中。

IEEE802.15.4
IPv6
  What’s new ?  127B frame size.  40B Header (Min.)
 Data Rate: 20~250Kbps  1280B MTU.
IPv6 Header compression  Maximize battery life.
 ND in multicast.
スタック全体で冗長なフィールドを削除
ヘッダーチェーンChained header by a dispatch field.
リンクヘッダから取れる情報 e.g. EUI-61
ネットワークの設定から読み取れるもの e.g. prefix, version
Fragmentation and Reassembly 6LBR
ND Optimization
multicast packet の抑制 6LR
6LR
L2網の情報の伝達
6LR
6LR
border routerのアドレス
header comporessのための情報 6LN
6LN
6LN
6LN

6lowpan ND Message Exchange

6LN
6LR
6LBR
self-assigned LLA
RS: SLLAO

default route, RA: PIO+SLLAO+6CO+ABRO
prefix,
contexts,
NS: ARO+SLLAO
DAR (ARO+SLLAO)

DAC (ARO+SLLAO)
NA: ARO Response

Lifetime Expired
NS: ARO+SLLAO

  3つのIPv6 ND optionと、2つのICMPv6 typeを定義
  6LRから、6lowpan context (6CO), Authoritative Border Router (ABRO)を通知。
  6LRから、Address Registration (ARO)を使用した6LBRへの登録とDADの実施。
  DA Request/Confirmationを使用した、6LBRでのDADの実施。

What is roll WG?
  Routing Over Low power and Lossy networks
Co-chairs: Challenge Areas
JP Vasseur (Cisco)
Michael Richardson (Consultant) 新しいリンクに対
応する適合層の
  Mission 標準化
LLNとSmart Objects向けの経路制御に関する課題の解決
“Low power and Lossy networks (LLNs) are typically composed of many
embedded devices with limited power, memory, and processing resources
interconnected by a variety of links, such as IEEE 802.15.4, Low Power WiFi.” 耐障害性経路制御
RFC 5548, 5673, 5826, 5867: Requirement for Urban, IA, HA, BA
RFC 6206: Trickle Algorithm LLN向け汎用アプリ
RFC 6550: RPL Core Spec ケーションプロトコル
RFC 6551: Routing Metrics
の標準化
RFC 6552: Objective Function Zero
RFC 6553: IPv6 Hop-by-Hop Option for RPL LLN向け機器の実
RFC 6554: IPv6 Routing Header Option for RPL 装ガイド
P2P-RPL in IESG queue
RPL Multicast

Routing over low Power Lossy networks: ripple [rípl]
What is RPL ?
  多様なLLN向けアプリケーションの要求を元に設計
Urban, Industrial, Home Automation, Building Automation.
 MP2P, P2MP and P2P DODAG: Destination Oriented Directed Acyclic Graph

  物理的に同じリンク上に複数のツリーを構築可能
 異なるのアプリケーションの要求に応じた最適なパスを構築できる。
  DODAGを構築する複数のメトリックを指定可能。
メトリック: node state, energy, hop-count, throughput, link reliability
  LLN向けのパス構築機構
近隣状態に応じて制御情報の送出間隔を変化させる。
!Trickle Timer
メモリが少ないノードがパケットを転送できるモードがある。
!Non-Storing Mode!
2つのパス再構築機構
Global Repair : 全体を再構築する機構 e.g. DODAGのメトリックが変わった場合等
Local Repair : 部分的に自動修復する機構 e.g. リンクの状態が変化した場合等

Path Construction by RPL
MP2P P2MP P2P

Root

Router
Host

Traffic

Path

  ICMPv6 type (155): RPL Control Messages
DIS: DODAG Information Solicitation
DIS / DIO for MP2P DIO: DODAG Information Object
DAO / DAO-ACK for P2MP DAO: Destination Advertisement Object
DRO: Discovery Reply Object
DIO+RDO / DRO+RDO / DRO-ACK for P2P RDO: Route Discovery Option

  2 IPv6 Extensions
RPL SRH in Routing Header: transmission b/w RPL routers.
RPL Option for HbH Options Header: exchaning RPL information b/w RPL routers.

  ICMPv6 Destination Unreachable
Code (7) Error in Sourceand/or its affiliates. All rights reserved.
Routing Header
Presentation_ID © 2010 Cisco Cisco Confidential 23

roll WG meeting in IETF85
  Applicability Statement template.
  RPL applicability in industrial networks
  Industrial Deterministic Routing Extension for Low-Power
and Lossy Networks
TDMA(L2)の待ち時間をメトリックとして扱う提案。

B
20ms 40ms
A D
AB

AC
10ms 30ms

C
BD

CD t (ms)
10 20 30 40 50


roll WG meeting in IETF85
  Multicast Protocol for Low power and Lossy Networks
e.g. mDNS

  Loop Free DODAG Local Repair
non-storing modeのLoop self hearing.
DODAG Repair Query/Responseの追加提案

  RPL Routing Pathology In a Network With a Mix of Nodes
Operating in Storing and Non-Storing Modes
DAOにstoring mode bitを追加と
new mode追加の提案

src dst src dst
Storing Mode Non-Storing Mode

What is “core” WG ?
  Constrained RESTful Environment Challenge Areas
Co-chairs:
Carsten Borman (Bremen Univ) 新しいリンクに対
Andrew McGregor (Allied Telesis) 応する適合層の
標準化
  Mission
M2M向けのアプリケーションプロトコルの策定耐障害性経路制御
RFC 6690: CoRE Link Format
CoAP Specifications ケーションプロトコル
Core の標準化
Block
Observe LLN向け機器の実
HTTP Mapping and Proxy 装ガイド
Group communication framework

What is CoAP ?
  Specialized for M2M applications Protocol stack image
RESTful protocol of a LLN device

Simple small header < 10B Application
Stateless single message exchange
Asynchronous message exchange CoAP REST

Observation mode (a.k.a. publication/subscriber)
CoAP Transactions
Caching
UDP binding with reliability, and multicast UDP
Retransmission
Block-wise transfer

  Strictly specification of a HTTP proxy
Internet media type support.
HTTP compatible response code.
Transaction
Operations
method
operation
CON
receiver is requested to make a response
GET
to get a resource, no change.
ACK
response to CON
POST
to create a resource.
NON
receiver is not requested any action
PUT
to update a resource.
RST reset the receiver’s state, typically used in the
asynchronous mode.
DELETE
to delete a resource.

CoAP message exchange
  Confirmable message
Confirmable Request and Piggy-backed Response
CoAP
cf. HTTP

TCP 3-way handshake

CoAP CON GET temperature
HTTP GET /temperature
CoAP ACK 200 OK 25.3
HTTP 200 OK 25.3

TCP 2-way termination

  Non-confirmable message

CoAP NON PUT temperature


CoAP message exchange
  Asynchronous message
Confirmable Request and Seprate Response

Client
Server
MID: メッセージの対応を示す
Token: トランザクションを示す

GET Temperature
Header: GET T=CON Code=1 MID=0x7d38
Token: 0x53 1
Uri-Path: “temperature”
1
ACK
Header: T=ACK Code=0 MID=0x7d38
1
Header: 2.05 Content T=CON Code=69 MID=0x2d7b
22.5C
Token: 0x53 2
Payload: “22.5C”
2
ACK
Header: T=ACK Code=0 MID=0x2d7b
2


core WG meeting in IETF85
  ETSI plugtest @ Sophia-Antipolis (27-30 Nov, 2012)
CORE, LINK, OBSERV, BLOCK)
Proxy Caching, Security DTLS, Full set of options,
IPSO Applicaton Framework
  coap-12
option番号のrenumbering!!
option lengthの伸張, jump mechanism
ETSI plugtestの結果を受けてcoap-13を提出する。

  WGLC in progress: coap-13, block-10, observe-07
  The content parameter option
例. EXIは、送受信者同士がスキーマを共有していないと通信できない。
そして、スキーマにはバージョンがある。
 content-type以外に scheme version等を知らせる必要がある。
現状：content-format optionにacceptableなcontent-typeを列挙しなければならない。
提案：content parameter optionがあると、サポートしているバージョンを書けば良い。


core WG meeting in IETF85

  Group Communication
  HTTP-CoAP proxy
two open sources: squid base, evCoAP base

  Sleepy Devices
Sleeping End Point (SEP) の定義
CoAP Resource Directory(RD)への要求事項
SEP用属性の追加。

  DTLS based MSEC for LLNs (in tls WG)
DTLS自体はGCKSと張ってMIKEY的TEKを配る。
rekeyに課題がある。


What is lwig WG ?
  Lightweight Implementation Guidance Challenge Areas
Co-chairs:
Zhen Cao (China Mobile) 新しいリンクに対
Robert Cragie (consultant) 応する適合層の
標準化
  Mission
組込み機器向けのTCP/IPスタック実装ガイダンス耐障害性経路制御
の作成プロトコルの標準化

  Significant IDs
Lightweight Implementation Guidance
の標準化
Data Size (e.g. RAM)
Code Size (e.g. Flash)
Class 1
~ 10KB
~ 100KB
LLN向け機器の実
Class 2
~ 50KB
~ 250KB
装ガイド
リファレンスモデル

標準化動向のまとめ

6LoWPAN HC/ND CoAP: M2M通信に最適化した通信プロトコル
 IPv6/TCP/UDPヘッダの圧縮  メソッドの厳密な定義
 IIPv6近隣探索プロトコルの最適化  バイナリメッセージ化
 IPv6パケットの分割と再構成  非同期、ブロック転送、PUB/SUB
 主要技術は全てRFC化された  HTTPマッピングの定義

RPL: LLNに最適な経路制御プロトコル
 経路表を持てないノードでも動作可能
 電力使用状況をメトリックに使用可能
 自律分散的な経路再構築が可能
 核となる仕様はRFC化された
 P2P-RPLとRPL-MulticastはWGLC終了
 Applicabilityは作業中


Others in IETF85
  SOLACE (Smart Object Lifecycle Architecture for Constrained Environments)
Focusing to setup processes ("instilling its meaning in life") and
bootstrapping security of smart objects.
e.g. where do devices get keys ?
what do devices do in its lifecycle ?

  COMAN (Management of Constrained Networks and Devices)
Management for LLN. Manet management is in manet WG.
Gap analysis first, then starting a charter discussion.
1) Terminology.
2) Class of networks in focus.
3) Analysis the management feature.


モノへのIP技術普及推進活動 IPSO
  Alliance established in September, 2008
 59 members (Nov 2012)
Chairman: Geoff Mulligan (Proto6)
President: Pete St. Perre (Oracle)
Vice-President: Patrick Wetterwald (Cisco)
TAB Chair: Jari Akko (Ericsson)

  Mission
 Smart Object（モノ）へのIPの応用の推進活動
 技術普及・教育活動やユースケースの紹介
 IETF等の他標準化組織の活動サポート
 相互接続試験の主催

  Formal Liaison   On-Going Activities
ETSI o  Interoperability Testing
IPv6 Forum
o  Tutorials, Webinars
Zigbee Alliance
http://ipso-alliance.org/resource-library

IPSO Plugfest at IETF84
  Nivis (http://www.nivis.com/products/product.php?pID=11)
6lowpan,ipv6,rpl,coapスタックを1チップ化。
freescale RFモジュールにadd-onしている。
日本の技適取得は現在進行中。 10月にプレスリリース予定。

  Proto6 + colorado micro
10円玉ほどのデバイスとbeagleboneで作るネットワークのデモ
core + IPv6 + 6lowpan + L2メッシュ
10円玉デバイスは Colorado Microと言っていた。

  NOKIA
TI cc2540ベースの bluetooth heart beat sensor
coap + udp + ipv6 + 6lowpan + bluetooth
APにbluetooth USBドングルを挿してデータを受ける。
APにてbluetooth to ethernet変換してロンドンのDCへ転送する。
coap/httpはロンドンのDCにてやる。

  Sensinode (http://www.sensinode.com/)
coap関連スタック開発 link formatを使ったregistration&management GUIを見せていた。
plugfestにあるデバイスは、ここにregistrationしていて、GUIから制御できる。

  NXP / jennic (http://www.jennic.com/products/protocol_stacks/jennet-ip)


IPSO Demo:
Bits-N-Bites in IETF85
  L+G: FOCUS RXR-SD
  Nivis+Freescale
TWR-METRO-KIT-NA

  Sensinode
  Proto6


本日のまとめ
  M2M/IoTネットワークは垂直統合型で独自進化を遂げてきた。
  アプリケーションの多様化により、
 水平統合型のソリューションが期待されている。
 それらを統合運用する要求がある。
  そのためにTCP/IP技術の応用が検討・実施されている。
IETFにおいて、
  LLNに最適化したTCP/IP技術の標準化が進んでいる。
6lowpan-hc, 6lowpan-nd: IPv6 ヘッダ圧縮とNDの最適化
RPL: LLN向け経路制御及びパケット転送技術
CoAP: M2M向け通信技術
  標準化活動以外にも、M2M/IoTの相互接続性を向上させるための
活動が行われている。
実装ガイダンスの作成, Workshop, Interop,
SOLACE, COMAN, etc.

IETFにおけるM2M/IoTの動向

IETFにおけるM2M/IoTの動向

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IETFにおけるM2M/IoTの動向

Similar to IETFにおけるM2M/IoTの動向 (20)

More from Shoichi Sakane

More from Shoichi Sakane (12)

Recently uploaded

Recently uploaded (10)

IETFにおけるM2M/IoTの動向