wdiff rfc7774.original rfc7774.txt

roll
Internet Engineering Task Force (IETF) Y. Doi
Internet-Draft TOSHIBA
Request for Comments: 7774 Toshiba Corporation
Intended status:
Category: Standards Track M. Gillmore
Expires: May 5, 2016
ISSN: 2070-1721 Itron, Inc
November 2, 2015

MPL Inc.
February 2016

Multicast Protocol for Low-Power and Lossy Networks (MPL)
Parameter Configuration Option for DHCPv6
draft-ietf-roll-mpl-parameter-configuration-08

Abstract

This document defines a way to configure a parameter set for MPL
(Multicast Protocol for Low power Low-Power and Lossy Networks) via a DHCPv6
option. MPL has a set of parameters to control its behavior, and the
parameter set is often configured as a network-wide parameter because
the parameter set should be identical for each MPL forwarder Forwarder in an
MPL domain. Domain. Using the MPL Parameter Configuration Option defined in
this document, a network can easily be configured with a single set
of MPL parameters.

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 an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 May 5, 2016.
http://www.rfc-editor.org/info/rfc7774.

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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. MPL Parameter Configuration Option . . . . . . . . . . . . . 3
2.1. MPL Parameter Configuration Option Format . . . . . . . . 3
2.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5 6
2.3. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . 6
2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7
2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 7
2.6. Operational Considerations . . . . . . . . . . . . . . . 7 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Update History (TO EDITORS: this section is intended
to be removed before this document becomes an RFC) . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 10

1. Introduction

The Multicast Protocol for Low power Low-Power and Lossy Networks (MPL)
[I-D.ietf-roll-trickle-mcast]
[RFC7731] defines a protocol to make a multicast network among
low-power and lossy networks, e.g., wireless mesh networks. MPL has
a set of parameters to control an MPL domain. Domain. The parameters control
the trade-off between end-to-end delay and network utilization. In
most environments, the default parameters are acceptable. However,
in some environments, the parameter set must be configured carefully
in order to meet the requirements of each environment. According to the MPL document section 5.4,
Section 5.4 of [RFC7731], each parameter in the set should be the
same for all nodes within an MPL
domain, Domain, but the MPL document [RFC7731] does not
define a method to configure the MPL parameter set.

Some managed wireless mesh networks may have a DHCP server to
configure network parameters. MPL parameter sets shall be considered
as a part of network parameters (nodes in an MPL domain Domain should use an
identical parameter set). And a A parameter set is required to configure
an MPL domain. Domain.

This document defines the a way to distribute parameter sets for MPL
forwarders as
Forwarders via a new DHCPv6 [RFC3315] option. This document is
intended to follow [RFC7227] the guideline. guidelines provided in [RFC7227].

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].

2. MPL Parameter Configuration Option

As stated defined in Section 5.4 of [I-D.ietf-roll-trickle-mcast], [RFC7731], there are
the following 10 parameters per
MPL domain. Domain, as listed below. An MPL domain Domain is defined by an MPL domain address,
Domain Address, as described in Section 2 of
[I-D.ietf-roll-trickle-mcast]. [RFC7731].

o PROACTIVE_FORWARDING

o SEED_SET_ENTRY_LIFETIME

o DATA_MESSAGE_IMIN

o DATA_MESSAGE_IMAX

o DATA_MESSAGE_K

o DATA_MESSAGE_TIMER_EXPIRATIONS

o CONTROL_MESSAGE_IMIN

o CONTROL_MESSAGE_IMAX

o CONTROL_MESSAGE_K

o CONTROL_MESSAGE_TIMER_EXPIRATIONS

One network may have multiple MPL domains Domains with different
configurations. To configure more than one MPL domain Domain via DHCP,
there may be more than one MPL Parameter Configuration Option given
to DHCP clients by a DHCP server.

2.1. MPL Parameter Configuration Option Format

This document defines the OPTION_MPL_PARAMETERS DHCPv6 option. This
new option provides a means to distribute a configuration of an MPL domain
Domain or a default value for all MPL domains (wildcard) under Domains (a wildcard) within the
network managed by the DHCP
server, this document defines a DHCPv6 server. This option format as follows. has the following
format:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MPL_PARAMETERS | option_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Z | TUNIT | SE_LIFETIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DM_K | DM_IMIN | DM_IMAX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DM_T_EXP | C_K | C_IMIN >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>(cont'ed) | C_IMAX | C_T_EXP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(if option_len = 32 ) 32)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPL Domain Address (128bits) (128 bits) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned). (104).

option_len: Length of the option, which is 16 of if no MPL domain
address Domain
Address is present, or 32 if there is an MPL domain address. Domain Address.

P (1 bit): A flag to indicate PROACTIVE_FORWARDING. The This flag is
set if PROACTIVE_FORWARDING is true. = TRUE.

Z (7 bits): Reserved for future use. Servers MUST set them to zero.
Clients SHOULD ignore the bits set.

TUNIT (unsigned 8-bit integer): Unit time of timer parameters
(SE_LIFETIME,
(SE_LIFETIME and *_IMIN) in this option. 0 and 0xff are reserved
and MUST NOT be used.

SE_LIFETIME (unsigned 16-bit integer): SEED_SET_ENTRY_LIFETIME/TUNIT
SEED_SET_ENTRY_LIFETIME/TUNIT, in milliseconds. 0 and 0xffff are
reserved and MUST NOT be used.

DM_K (unsigned 8-bit integer): DATA_MESSAGE_K.

DM_IMIN (unsigned 16-bit integer): DATA_MESSAGE_IMIN/TUNIT DATA_MESSAGE_IMIN/TUNIT,
in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.

DM_IMAX (unsigned 8-bit integer): DATA_MESSAGE_IMAX. The actual
maximum timeout is described as a number of doublings of
DATA_MESSAGE_IMIN, as described in [RFC6206] [RFC6206], Section 4.1.
0 and 0xff are reserved and MUST NOT be used.

DM_T_EXP (unsigned 16-bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS.
0 and 0xffff are reserved and MUST NOT be used.

C_K (unsigned 8-bit integer): CONTROL_MESSAGE_K.

C_IMIN (unsigned 16-bit integer): CONTROL_MESSAGE_IMIN/TUNIT CONTROL_MESSAGE_IMIN/TUNIT,
in milliseconds. 0 and 0xffff are reserved and MUST NOT be used.

C_IMAX (unsigned 8-bit integer): CONTROL_MESSAGE_IMAX. The actual
maximum timeout is described as a number of doublings of
CONTROL_MESSAGE_IMIN. 0 and 0xff are reserved and MUST NOT
be used.

C_T_EXP (unsigned 16-bit integer): CONTROL_MESSAGE_TIMER_EXPIRATIONS
.
CONTROL_MESSAGE_TIMER_EXPIRATIONS. 0 and 0xffff are reserved and
MUST NOT be used.

Note that the time values (SEED_SET_ENTRY_LIFETIME,
DATA_MESSAGE_IMIN, and CONTROL_MESSAGE_IMIN) in MPL are defined in to a
precision of TUNIT milliseconds precision in MPL Parameter Configuration
Options. For example, if TUNIT is 20 and the data message interval minimum Data Message
interval (DATA_MESSAGE_IMIN) is 1000ms, 1000 ms, then DM_IMIN shall be set
to 50.

For the maximum interval size (*_IMAX), [RFC6206] defines them as
follows:

The maximum interval size, Imax, is described as a number of
doublings of the minimum interval size (the base-2 log(max/min)).
For example, a protocol might define Imax as 16. If the minimum
interval is 100 ms, then the amount of time specified by Imax is
100 ms * 65,536, i.e., 6,553.6 seconds or approximately
109 minutes.

Because the minimum interval size in the MPL Parameter Configuration
Options is described as TUNIT millisecond in TUNIT-millisecond precision, the
corresponding maximum interval size is also in TUNIT TUNIT-millisecond
precision. For example, if TUNIT is 10 and C_IMIN is 50, the minimum
interval size of the
trickle Trickle timer for control messages Control Messages is 500ms. 500 ms.
In this case, the maximum interval size of the trickle Trickle timer is
32 seconds (500ms (500 ms * 2^6) if C_IMAX is 6.

2.2. DHCPv6 Client Behavior

Clients MAY request the MPL Parameter Configuration Option, Option as
described in [RFC3315], sections Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7.
22.7 of [RFC3315]. As a convenience to the reader, we mention here
that the client includes requested option codes in the Option Request
Option.

Clients MUST support multiple MPL Parameter Configuration Option, as
stated Options,
which are listed in section Section 2.

If a DHCPv6 client with an MPL forwarder Forwarder configured by the MPL
Parameter Configuration Option is unable to receive a valid response
from a server within T2 [RFC3315] of the last valid DHCPv6 message
sent from the server (if stateful) or twice the Information Refresh Time information refresh
time [RFC4242] (if stateless), it MUST suspend the MPL forwarders Forwarders of
the MPL domains Domains configured by the option. MPL forwarders Forwarders configured
by other methods
such as static (e.g., via a static configuration file file) MUST NOT be
suspended.

Clients MUST ignore all MPL Parameter Configuration Options if the
options in a DHCPv6 message contains contain any invalid value values (e.g., it uses
reserved all-0 or all-1 values are used in parameters). In this
case, in the context of MPL the message is considered not received in MPL context received,
and the condition described in the previous paragraph applies.

2.3. MPL Forwarder Behavior

If a DHCPv6 client requests and receives the MPL Parameter
Configuration Option, the node SHOULD join the MPL domain Domain given by
the option and act as an MPL forwarder. Forwarder. Note that there may be cases
in which a node may fail to join a domain (or domains) due to local
resource constraints. Each joining node SHOULD configure its MPL
forwarder
Forwarder with the given parameter set for the MPL domain. Domain. Each MPL
domain
Domain is defined by an MPL Domain Address given by an MPL Parameter
Configuration Option. As defined in Section 2 of
[I-D.ietf-roll-trickle-mcast], [RFC7731], an MPL
Domain Address is an IPv6 multicast address associated to a set of
MPL network interfaces in an MPL Domain.

The priority of MPL Parameter Configurations parameter configurations applied to an MPL Domain
is as follows (high to low):

o Specific MPL Parameter Configuration to parameter configuration for the MPL Domain
(option_len=32)
(option_len = 32).

o Wildcard MPL Parameter Configuration (option_len=16) parameter configuration (option_len = 16).

o Default configuration given as described in the MPL specification.

Priority [RFC7731].

Priorities of other configurations configurations, such as manual configuration given
on of a node is
node, are not defined in the this document.

There MUST be no more than one MPL Parameter Configuration Option for
an MPL domain Domain or the wildcard. Thus, the order of DHCPv6 options in
the packet has no effect on precedence.

A node MUST leave an MPL domain Domain if it receives an updated and all-
valid all-valid
MPL Parameter Configuration Options without a configuration for the
MPL domain, Domain, unless it has an overriding manual configuration on for the
MPL domain. Domain. In other words, if a node is configured to work as a an
MPL Forwarder for a an MPL domain Domain regardless of DHCPv6 Options, options, the
node MAY stay on in the MPL domain Domain even if it receives an MPL Parameter
Configuration Option without a configuration for the MPL domain. Domain.

MPL parameters may be updated occasionally. With stateful DHCPv6,
updates can be done when the renewal timer expires. Information
Refresh Time Option The information
refresh time option [RFC4242] shall be used to keep each forwarder
updated.

To reduce periodic update traffic, a node may try to use a very long
interval between updates. In this case, reconfigure Reconfigure messages may be
used to keep forwarder parameter sets synchronized.

2.4. DHCPv6 Server Behavior

Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
regards
regard to option assignment. As a convenience to the reader, we
mention here that the server will send the MPL Parameter
Configuration Option only if it was configured with specific values
for the MPL Parameter Configuration Option and the client
requested it.

Servers MUST ignore an incoming MPL Parameter Configuration Option.
Servers MUST support multiple MPL Parameter Configuration Option, as
stated Options,
which are listed in section Section 2.

2.5. DHCPv6 Relay Behavior

It's

It is never appropriate for a relay agent to add options to a message
heading toward the client, and relay agents don't do not actually construct
Relay-Reply messages anyway. There are no additional requirements
for relays.

2.6. Operational Considerations

This draft document introduces the dynamic update updating of MPL parameters.
Because the update process is not synchronized, nodes may have
inconsistent parameter sets.

[RFC6206] section

[RFC6206], Section 6 describe describes various problems that happens occur if the
trickle
Trickle timers do not match between communicating nodes. To keep the
timers synchronized, it is RECOMMENDED not to not update the parameters
of an MPL domain Domain too often. A reasonable update rate would be once
per expected information refresh time interval, such as T1 in [RFC3315]
or Information Refresh Time information refresh time as defined in [RFC4242].

Inconsistent parameter sets may reduce performance. On the other
hand, this situation will work as long as both new and old parameter
sets are reasonable parameter sets for a given communication load.
As the
Because motivations for parameter update updates include update updates of the
environment, node density, or communication load, operators of MPL
networks shall need to be aware of unupdated nodes that are not updated and make sure
that old and new parameter sets are reasonable for the expected
refresh intervals.

3. IANA Considerations

IANA is requested to assign one has assigned an option code for to OPTION_MPL_PARAMETERS (104) from
the "DHCP Option "Option Codes" table of the Dynamic "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) Registry (DHCPv6)" registry (http://www.iana.org/assignments/
dhcpv6-parameters).

4. Security Considerations

There are detailed discussion on security threats on DHCPv6 in

Section 23 of RFC3315 [RFC3315], Section 23 of RFC7227 [RFC7227], and Section 13 12 of [I-D.ietf-roll-trickle-mcast].

In addition,
[RFC7731] provide detailed discussions regarding security threats for
DHCPv6.

Note also that a forged MPL parameter configuration may cause
excessive
layer-2 Layer 2 broadcasting. Implementations should set
reasonable bounds for each parameter. For parameter -- for example, not setting
DM/C_K too high DM/C_K, high, not setting DM/C_IMIN too low DM
/C_IMIN, etc. low. These bounds may be
implementation dependent or may be derived from MAC/PHY
specifications. DHCPv6 server and client implementations need to
take care in setting reasonable bounds for each parameter in order to
avoid overloading the network.

The DHCP server or the network itself should be trusted by some means
means, such as DHCPv6 authentications authentication as described in Section 21 of RFC3315
[RFC3315]. However, ROLL environment Routing Over Low-Power and Lossy (ROLL) network
environments may expect less fewer computing
resource, resources, and DHCPv6
authentication may not be available. In such cases, other methods to
protect integrity between DHCPv6 servers and clients should be
applied to a ROLL network. Some ROLL specification specifications, such as
ZigBee IP [ZigBeeIP] expects RFC5191 [RFC5191] and [RFC5191], expect to authenticate joining
nodes and so that all nodes in the network can be trusted. To protect
against attacks from outside of the network, DHCPv6 packets SHOULD be
filtered on the border router between the ROLL network and the
Internet, except for the packets between the ROLL network and a remote
DHCPv6 server or DHCPv6 relays configured to manage the network.

5. References

5.1. Normative References

[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-12 (work in progress), June 2015.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003.
2003, <http://www.rfc-editor.org/info/rfc3315>.

[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 2005.
2005, <http://www.rfc-editor.org/info/rfc4242>.

[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014. 2014,
<http://www.rfc-editor.org/info/rfc7227>.

[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>.

5.2. Informative References

[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008. 2008, <http://www.rfc-editor.org/info/rfc5191>.

[ZigBeeIP]
ZigBee Alliance, "ZigBee IP Specification", Mar 2014.

Appendix A. Update History (TO EDITORS: this section is intended to be
removed before this document becomes an RFC)

Updates on draft-ietf-roll-mpl-configuration-07 to draft-ietf-roll-
mpl-configuration-08:

o clarified when to leave (SHOULD->MUST)

o moved Trickle parameter considerations on appendix to operational
considerations

o even clarified some texts

Updates on draft-ietf-roll-mpl-configuration-06 to draft-ietf-roll-
mpl-configuration-07:

o clearly stated multiple option support is mandatory (#171)

o operational consideration now refers RFC6206 and some texts are
moved to section 2.2 (#171)

o added more per-section reference to I-D.ietf-roll-trickle-mcast
(#171)

o field 'Z' clarified (#171, #172)

o fixed other nits (#171)

o clarified use of TUNIT, *_IMIN, and *_IMAX with reference to
RFC6206 (#172)

Updates on draft-ietf-roll-mpl-configuration-05 to draft-ietf-roll-
mpl-configuration-06:

o added description on manual (external) configurations

Updates on draft-ietf-roll-mpl-configuration-04 to draft-ietf-roll-
mpl-configuration-05:

o fixed *_IMAX definition as RFC6206 defines

o fixed *_EXP definition as draft-ietf-roll-trickle-mcast defines

o added references to RFC3315 and RFC7227 in security considerations
section
o added a paragraph on security consideration according to secdir
review

o fixed some nits and updated references

Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll-
mpl-configuration-04:

o References updated (Non-normative -> Informative)

o IANA section is updated to make clear request of option ID

o Reserved numbers are clearly denoted

Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll-
mpl-configuration-03:

o References updated

o Removed reference for DHCPv6 stateless reconfiguration as it has
expired

Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll-
mpl-configuration-02:

o Short unsigned floating point is dropped (#159)

o Packed value is removed and now every value has its own byte(s)
(#159)

Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll-
mpl-configuration-01:

o Operational considerations (normative) and appendix considerations
(non-normative) are added (Issue #157)

o More control on nodes / allow constrained nodes to ignore the
configuration: "the node s/SHOULD/MAY/ join the MPL domain given
by the option" (Issue #158)

Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll-
mpl-configuration-00:

o I-D renamed. 2015,
<http://www.zigbee.org/>.

Authors' Addresses

Yusuke Doi
TOSHIBA
Toshiba Corporation
Komukai Toshiba Cho 1
Saiwai-Ku
Kawasaki, Kanagawa 2128582
JAPAN
Japan

Phone: +81-45-342-7230
Email: yusuke.doi@toshiba.co.jp

Matthew Gillmore
Itron, Inc Inc.
2111 N N. Molter Rd.
Liberty Lake, WA 99019
USA
United States

Email: matthew.gillmore@itron.com