Hello, You may know that there's PANA-related discussion going on over 6tisch mailing list. As part of that discussion, Yoshi gave us the following update on Japan smart grid deployment.
Thank you Yoshi, and FYI…. Alper Begin forwarded message: > From: <yoshihiro.o...@toshiba.co.jp> > Subject: Re: [6tisch] PANA clarifications (was Re: Directions on the join > process) > Date: November 13, 2015 3:00:07 AM GMT+02:00 > To: <padu...@cisco.com>, <robert.cra...@gridmerge.com> > Cc: 6ti...@ietf.org > > There are significant field deployment efforts ongoing for smart meters in > Japan. > > In Japan, there is an operational guideline for smart meters supporting so > called “B-Route” which is a communication interface between smart meter and > HEMS (Home Energy Management System) controller. B-route is a part of HAN > (Home Area Network). > > The operational guideline is available at: > http://www.meti.go.jp/committee/kenkyukai/shoujo/smart_house/pdf/006_s03_00.pdf > (the document is written in Japanese) > > In the guideline, smart meters and HEMS controllers need to obtain three > types of certification: B-route media certification, ECHONET-Lite > certification and SMA certification. B-route media certifications for 920MHz > band is based on “Wi-SUN profile for ECHONET-Lite” which mandates PANA for > network access authentication over 6LoWPAN over IEEE 802.15.4e/g (see the > protocol stack diagram in page 36 of the guideline). BTW,“Wi-SUN profile for > ECHONET-Lite” defines not only B-route interface but also the entire ECHONET > HAN interface for 920MHz band. > > All Japanese electric power companies follow the guideline and have chosen > Wi-SUN as their primary communication interface for B-route as indicated in > page 8 of the guideline. > > There is also data on how many smart meters are planned for deployment in > Japan. See the table in page 6 of the following document: > http://www.meti.go.jp/committee/summary/0004668/pdf/015_03_00.pdf > (the document is written in Japanese) > > The table shows number of smart meters to be deployed in each year by each > regional electric power company in Japan (unit: 10K). According to the > table, more than 80 million of smart meters will be deployed by Y2024 (and > all of them will use PANA for B-route primary interface). As of today, > there are more than 50 Wi-SUN-certified products in Wi-SUN B-Route category. > > Regards, > Yoshihiro Ohba > > > From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Paul Duffy > Sent: Thursday, November 12, 2015 6:35 AM > To: robert.cra...@gridmerge.com > Cc: 6ti...@ietf.org > Subject: Re: [6tisch] PANA clarifications (was Re: Directions on the join > process) > > On 11/7/2015 10:40 AM, Robert Cragie wrote: > Paul, > > Whatever the state of ZigBee IP, it doesn't alter the fact that it > successfully completed after an extensive specification, implementation and > test program, demonstrating interoperability across 7 independent platforms, > > > Agreed. > > > so the solution is certainly proven. > > > There is no way I would designate a solution as proven w/o a significant > field deployment. > > > Robert > > On 5 Nov 2015 16:23, "Paul Duffy" <padu...@cisco.com> wrote: > Re: PANA traction in the market. > > AFAIK Zigbee IP has no deployed footprint and none are pending. > > Wi-SUN consists of several profiles. EchoNet and Field Area Network being > prominent. FAN is using 802.1X / EAP-TLS. > > > On 11/3/2015 2:52 AM, Alper Yegin wrote: > Hi Malisa, > > On Oct 31, 2015, at 11:10 PM, Malisa Vucinic wrote: > > Thanks for the clarification. We are trying to maximize code reuse > Then please note that PANA is RFC, has multiple implementations, adopted by > other standards (Zigbee and Wi-Sun), and already getting deployed (Wi-Sun). > > > and minimize number of exchanges. In Q17 I see that Client Initiation message > is omitted if network can detect on its own the presence of JN, which is not > the case in 6tisch. > OK. > Note that, though, any solution you'd have would need to have the equivalent > of that one message where the client says "hello, let's start auth". > > > I suppose that we are then left with EAP overhead plus an extra discovery > message. > > I see the EAP overhead is being debated already. > But like I said above, discovery message needs to be supported by any other > solution as well, hence I don't think it's extra for "EAP/PANA" > > Alper > > > > > Regards, > Mališa > > > On 31 Oct 2015, at 22:43, Alper Yegin <alper.ye...@yegin.org> wrote: > > Hello, > > I've read the thread. I see there are some PANA-related questions. Let me > clarify them. > > Like Rafa said, PANA is already adopted and fully defined by Zigbee IP. Hence > I'd expect it's ready to be used for 6tisch as well. Are there anything > special here in 6tisch that'd make a difference with respect to network > access authentication and key management? > > > PANA assumes the JN has an IP address. That IP address can be a link-local IP > address. > (Not sure if this work really needs a solution that operates before *any* IP > address is configured on the JN. But if it does, then here's an expired work > on that front: > https://tools.ietf.org/html/draft-yegin-pana-unspecified-addr-06) > > - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+ > messages for EAP-TLS ] + 1 packet to provision K2 > Not sure where that "4 messages" come from. It can be "0". See Q16 and Q17 in > http://www.panasec.org/docs/PANA-FAQ.txt. > Also that last 1 packet is not needed either. The last packet sent from the > authenticator can deliver that payload. > > I don't think a separate KMP is needed when we use PANA. > Because: > - EAP/PANA authentication generates PANA SA between the JCE and JN. Which can > used for further key derivation. Given the PANA is extensible thru AVPs, > additional parameters can be delivered between the end-points if necessary. > - RFC 6786 defines how PANA can carry encrypted payloads, which can be used > for delivering keys. > > I hope these help. > > Alper > > > > > _______________________________________________ > 6tisch mailing list > 6ti...@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > _______________________________________________ > 6tisch mailing list > 6ti...@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > _______________________________________________ > 6tisch mailing list > 6ti...@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > . > > > _______________________________________________ > 6tisch mailing list > 6ti...@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > 6tisch mailing list > 6ti...@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ Pana mailing list Pana@ietf.org https://www.ietf.org/mailman/listinfo/pana
