10
Network Interop March 8 th 2011 Herbst

Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Embed Size (px)

Citation preview

Page 1: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Network Interop

March 8th 2011Herbst

Page 2: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Ft Lauderdale

• Review of Herbst/Sturek document submitted to IETF– http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00

• Suggestions for moving forward– AMI Interfaces

Page 3: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Since Fort Lauderdale

• Started Weekly Calls• 9am-10am PST Fridays

Page 4: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Work items identified

• IPv4/IPv6 transition– Interworking– Potentially DA focused

• Transition to NIST approved HAN technology• AMI-HAN requirements

Page 5: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

IPv4/IPv6

• Dual stack routing– No Interworking, “Ships in the night”

• NAT 64• Higher level application gateway• Perhaps Distribution Automation

Page 6: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Legacy HAN -> NIST HAN Transition

• SEP1.x -> SEP2.0 gateway• NIST efforts

Page 7: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

HAN impact on AMI Network

• Messaging• Bandwidth/latency• Security• Documents– Started with OpenHAN SRS v2– Next steps• SAE Documents• Zigbee

Page 8: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Example of OpenHAN items

• Page 13 AMI Definition• Page 14 Control & Pricing Signals• Page 16 Registration & Enrollment – perhaps commissioning • Page 21 High level Security requirements• Page27 – High level coms requirement• Page 28 item 5 – AMI must be able to tag public vs private message• Page 29 item 6 – ami provides backhaul for gas & water, etc DER, PEV• Page 30 top paragraph, DER generation data for GridOps• Page 30 midpage “innovative applications”• Page 32 line 23 – high level ESI requirements• Page 33 question on AMI inventory of the HAN device• Page 35 high level security – HAN device threat vector• Page 35 multiple connections to the home• Unique events via multiple paths• Might be from different service providers• Different Service provider vs network provider identification• Page 38 & page 39 – examples of enrolled devices getting load control messages• Page 43 - high level control signals• Page 43 – Processing Section – various price, control signal and other data needed to process • Page 44 – more detail on commissioning, registration, enrollment• Page 44 – dynamic ACL’s• Page 45 line 45 Over the air upgrade• Page 46 – more price and load control• Page 46 – Billing information• Page 47 – high level security requirements• Page 48 – two way load shed (message/confirm) + Cancel events

Page 9: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –

Logistics of Moving Forward

• Non-workable approach– Reading/writing long documents in conference

calls or meetings• Calls should be group reviews– What is appropriate frequency of calls?

• Co-Chair• Independent or small group (2-3 people)

submissions

Page 10: Network Interop March 8 th 2011 Herbst. Ft Lauderdale Review of Herbst/Sturek document submitted to IETF –