PAP01: Role of IP in the Smart Grid CLOSED



For interoperable networks it is important to study the suitability of Internet networking technologies for smart grid applications. This work area investigates the capabilities of protocols and technologies in the Internet Protocol Suite by working with key SDO committees to determine the characteristics of each protocol for smart grid application areas and types.

Status of PAP01: Role of IP in the Smart Grid CLOSED

Updated July 27, 2011

Overall PAP Status:

Date Updated By Latest PAP Status
2011-07-27 Vishant Shah The SGIP plenary both voted to include IETF RFC 6272 into the Catalog of Standards.

A# Current Activities and Accomplishments
A10 Governing Board recommended RFC be included in Catalog of Standards (Dec 2010)
A11 SSO publishes RFC 6272 (May 2011)
A12 Plenary voted IETF RFC 6272 be included in Catalog of Standards (July 2011)

S D# Deliverables
choice-yes D1 Requirements for different Smart Grid applications
choice-yes D2 Identify Core set of IP protocols

I# Issues, Concerns & Help Needed
I10 PAP closure process

S T# PMO PAP Milestones Due Actual Resp D#
choice-yes TPMO1 PAP Initiation 2009-09 2009-09 SGIP  
choice-yes TPMO2 SSO Identified 2009-11 2009-11 Open SG-net
D1, D2
choice-yes TPMO3 Requirements Handoff to SSO 2010-11 2010-11 IETF - Fred Baker D2
choice-yes TPMO4 Standards Handback to PAPWG from SSO 2010-11 2010-11 IETF - Fred Baker D2
choice-yes TPMO5 GB/SGIP Vote 2010-12 2010-12 Administrator D2
choice-yes TPMO6 SGIP Plenary Vote 2011-07 2011-07 Administrator D2
choice-yes TPMO7 Post to Catalog or IKB 2011-07 2011-07 PAP01WG D2
choice-yes TPMO8 Close PAP 2011-07 2011-07 PAP01WG D2

S T# PAP Work Tasks Due Actual Resp D#
choice-yes T1 Develop a set of requirements for different Smart Grid applications Dec 2009 Dec 2009 Open SG-net D1
choice-yes T2 Identify a core Protocol Suite for IP-based Smart Grid Apr 2011 May 2011 IETF D2
choice-yes T3 Develop application specific protocol requirements Jul 2010 Jul 2010 Open SG-net D1
choice-yes T4 Meet at OpenSG on July 22 to develop action plan Jul 2010 Jul 2010 PAP  

Status Schedule Deliverables Resources
January 2010 led-green led-green led-green
February 2010 led-green led-green led-green
March 2010 led-green led-green led-green
April 2010 led-yellow led-yellow led-green
May 2010 led-yellow led-yellow led-green
June 2010 led-yellow led-green led-green
July 2010 led-green led-green led-green
August 2010 led-green led-green led-green
Sep 2010 led-green led-green led-yellow
Oct 2010 led-green led-green led-green
Nov 2010 led-green led-green led-green
Dec 2010 led-green led-green led-green
Jan 2011 led-green led-green led-green
Feb 2011 led-green led-green led-green
Mar 2011 led-green led-green led-green
Apr 2011 led-green led-green led-green
May 2011 led-green led-green led-green
Jun 2011 led-green led-green led-green
Jul 2011 led-green led-green led-green
Aug 2011 led-green led-green led-green

Key: STATUS LEDs -- complete=choice-yes, on target=led-green, caution=led-yellow, late=led-red

Task Details:

Task Responsible Date Notes
Task 1: Develop a set of requirements for different Smart Grid applications Key domain expert groups:

Utility and user groups, SG community,

IEEE P2030, UCAiug Open SG, NEMA
End of 2009 Collecting application communication requirements is underway. This draft matrix captures the progress made to date app_matrix_pap.xls
Task 2: Identify a core Protocol Suite for IP-based Smart Grid IETF and all other interested parties End of 2009 Determine what protocols are of part of the IP “core” protocols.

Discuss usage in the context of the Smart Grid
–discussion of common pitfalls
–relevant issues to consider

Task 3: Develop application specific protocol requirements

Identify additional protocols or protocol enhancements beyond the core suite required by a specific class of applications

Develop guidelines for IP-based Smart Grid deployment
IETF and all other interested parties Mid 2010 Refine the core suite developed in Task 2 by developing a modular suite of IP protocols in support of different application categories

Develop guidelines for usage including implementation, deployment choices and trade-offs.

Task 4: Meet in July 2010 to develop additional task items OpenSG Jul 2010 Minutes & action items in meeting call below
Task 5: Mapping of RFCs to satisfy requirements developed by CSCTG (NISTIR 7628) and guidelines for implementations IETF and all other interested parties Dec 2010 Need coordination with CSCTG
Task 6:Develop a profile of IPv6 protocols for Smart Grid NIST and all other interested parties Dec 2010 Uses USG IPv6 Profile as a base
Task 7: Develop an architecture document for Smart Grid IP networks IETF Nov 2010  
Task 8: Perform gap analysis

Identify new protocol or protocol enhancement standardization activities required to fully support Smart Grid in the future

IETF and all other interested parties Aug 2010 Map the application requirements developed in Task 1 against the specifications developed in Task 3 to determine any missing pieces or gaps.

Start standard development activities to close the gaps identified


The Internet technologies consist of a set of protocols to network and transport data messages using IP packets, as well as a set of protocols to manage and control the network, such as routing, mapping of IP addresses, device management, etc. This protocol suite enables distributed applications to run over a set of interconnected networks. It also includes session- and transaction-oriented security mechanisms to provide security services.


  • Review the communications networks and domains identified in the Smart Grid conceptual model and determine whether they are discussed in fine enough granularity to discuss the application of the Internet protocol suite
  • Define the approach for fully defining the network and systems management requirements for Smart Grid networking infrastructures
  • Define a set of standards profiles required for Smart Grid networks
  • Identify key networking profiles issues including issues surrounding IPv4 vs. IPv6
  • Determine the key remaining issues surrounding adoption of standardized networking profiles
  • Determine appropriate Smart Grid network architectures and technologies appropriate for basic transport and security requirements (e.g., shared IP networks, virtual private networks, MPLS switching, traffic engineering and resource control mechanisms)
  • Determine which transport layer security protocol(s) (e.g., TLS, DTLS, SCTP, and IPsec) are most appropriate for securing Smart Grid applications.
  • Identify higher layer security mechanisms (e.g., XML, S/MIME) to secure transactions.
  • Develop an action plan for development of necessary usage guides, profiles and remaining work.


The Smart Grid will need a comprehensive mapping of smart grid application requirements to the capabilities of protocols and technologies in a well define set of Internet Protocol Suite(s) or Profiles. This should be defined by experts well versed in the applications and protocols including management and security. A set of well-defined networking profiles can be tested for consistency and interoperability to help ensure systems integration as appropriate across the Smart Grid. A set of consistent and testable protocol profiles is also necessary to ensure that the combination of technologies can meet not only today’s requirements but meet future application needs as well. The networking profiles defined by this work will define a significant portion of the interfaces to Smart Grid equipment and systems. Most notably the interfaces that integrate systems over Wide Area Networks and large geographical areas will need to be defined in part by these profiles. The networking profiles will define networking functions such as addressing and the integration of concepts such as multihoming and other key functions necessary for the Smart Grid.


The Smart Grid will use a variety of different networking environments across smart grid domains and sub-domains as identified in the smart grid applications and conceptual models. The suitability of the proposed protocol suites or profiles in specific application contexts should be analyzed against the requirements emerging for Smart Grid applications and the proposed scale and scope of Smart Grid networks. The analysis should identify which protocols are clearly applicable in specific application contexts (e.g. use of TCP/IP, UDP, TLS/SSL, IPsec , IPV4/IPV6, MPLS) and protocols for network control, management and security, in addition to identifying any existing gaps.


This task will require the development of a combination of networking standards into well defined sets known as profiles. Working from existing and proposed Smart Grid applications and use cases the approach will require the distillation of Smart Grid applications and requirements into sets of networking profiles. These profiles will need to be developed into designs and implementations that can then be tested against the requirements. The communities that need to be involved include those within the Internet Engineering Task Force as well as other research communities that are working on networking technology.


Project Team
NIST Lead: David Su; Nada Golmie
EnerNex Technical Champion Leads: Vishant Shah; Joe Hughes
CSWG Liaison: Isaac Ghansah
SGAC Liaison: Fred Baker

Conference Call to Resolve Remaining Issues for Deliverable 2:
October 28, 2010 - 1:00pm - 2:30pm Eastern

Face-2-Face Meeting at SGIP Plenary in St. Louis:
September 15, 2010 - 9:00am - 11:30am Central Time (-6 UTC/GMT)

The following document are draft minutes from St. Louis PAP 1 meeting.

PAP 1 session at OpenSG Detroit, July 22, 2010:

PAP 1 met at the OpenSG meeting in Detroit on Thursday, July 22, 2010.

Major action items from the meeting include:

  • To develop a document describing how to achieve security with IP suite of protocols based on SG requirements - Lead: Ted Fisher
  • To develop an IP architecture document - Lead: Fred Baker
  • To provide a list of gaps and issues found in HAN for work in the IETF - Lead: OpenSG

Additional details can be found in the meeting minutes below.

Registration information and logistics details: here.

Meeting documents:

PAP 1 & PAP 2 session at Grid-Interop Denver, November 18, 2009:

A combined session of PAP 1 & PAP 2 took place at Grid Interop in Denver on November 18, 2009. Session information and details are available here.

Both IP and wireless communications priority action plans include as a first task the development of network requirements for Smart Grid applications. Identifying these requirements is key in order to develop guidelines for the use of IP and wireless communications in the context of the Smart Grid. Following a quick overview and a status update on these two PAP activities to date, this session will be dedicated to discussing and completing the draft application communications requirements matrix being developed under Task 1. Presentations discussed during the meeting:

Audio for the session is also available here

Call for Input to Task 1:

Task 1 calls for the collection of application communication requirements. A template matrix capturing different Smart Grid applications (rows) and their communication characteristics (columns) was developed. Table entries are intended to provide quantitative communication requirements for different Smart Grid applications and hence drive the development of guidelines for the use of different communication technologies. We appreciate any feedback on the template developed app_matrix_pap.xls to date and seek input for completing it.

Preliminary input received:

Requirements developed by Open SG SG-NET to date:

Contributions to Task 2:

Task 2 calls for identifying a core set of IP protocol specifications that can be used for Smart Grid. To this end the following contributions were submitted for consideration:

Comments and feedback are welcome.

Please Enter Any Comments Here

Could you please let me know when and where is this group meeitng? RubenSalazar 2009-07-22 - 16:05
Some of the selected standards use short stacks that run on Ethernet only. An example is the profile for 61850 GOOSE and Sampled Value. StanKlein 2009-07-24 - 10:32
This PAP reads like a research activity and not a standards activity. Work that may come from research in something such as Task 8 (identify places where IP may not function well), may uncover solutions that can contribute to specific standards efforts. The premise in Section 1.4, “The Smart Grid will need a comprehensive mapping of smart grid application requirements to the capabilities of protocols and technologies in a well defined set of IP suites or profiles.” sounds so broad as to be unwieldy. It says that these should be defined by “experts”, but this begs the question, “Who will be nominated as experts?” The real experts are those who work on the projects that implement the protocols and technology successfully and learn the lessons of that experience. Please consider recasting the PAP as a research issue with tasks and deliverables that may serve to define a future standards activity. Side note: If there are to be requirements for IETF standardization, then consideration should be given to the broad requirements of all process control and financial transaction industries while trying to avoid something special to electric power. SteveWidergren 2009-09-03 - 10:02
The tasks have been re-organized in order to better achieve the stated objectives and identify long-term standard development requirements. NadaGolmie 2009-10-22
The long-term SmartGrid connectivity requirements will mandate uniquely addressing tens of million devices if it is to be even nominally successful. Such a requirement not only exceeds currently available IPv4 address space, but is also larger than reserved address space for private internets (RFC 1918). The PAP team needs to either develop an IPv4 addressing plan which resolves this issue (including the numerous NAT, overlap, and conflict issues), or it needs to specify IPv6 as the network layer protocol for SmartGrid project. JohnCurran 2009-10-14 - 05:48
I would like to offer the opinion that IPv4/IPv6 not really a smart grid issue. As the smart grid evolves, it will interface with many other systems. In some cases these other systems will use IPv4, in some cases IPv6, and in some cases proprietary (or at least non-IP) addressing schemes. Regardless of whether we prefer IPv4 or IPv6, the interface points will drive the addressing schemes and force translations where necessary. As the Internet increasingly migrates towards IPv6, so will the smart grid. AndrewWright 2009-10-20 - 11:16
While I am an Internet advocate and specifically a promoter of IPv6, I notice the statement at the top of this page is suitably skeptical " study the suitability of Internet networking technologies for smart grid applications." It should not be a forgone conclusion that IP is the solution for smart grid, first examine the use cases. IP (and specifically IPv6) is probably the only sensible solution for widely distributed and individually addressable sensors and "control points" like dimmers, thermostats, etc. but may be inappropriate for the creation of a control plane for critical infrastructure. A closed network using some other standard, perhaps a new protocol, might be the right answer there. Consider opening up the discussion, and taking it back to an architectural level before committing to solutions. EdJankiewicz 2009-10-27 - 16:53
Is the comment period still open for the two documents posted above? JoeDiAdamo 2009-11-27 - 17:04
What's happening with the PAP 1? JoeDiAdamo 2010-01-29 - 15:45
Regarding the comment about IPv6 and internet protocols, I would say, nor should it be a forgone conclusion that significant use of the "Internet" is not possible or advisable. I like the suggestion of taking it 'back to the architectural level'. In fact I would wind back before that to look at cost and other factors that would tend to drive the architecture. I have started to draft PAPS to suggest work in these areas. The are currently posted with a few bits of information and are: InternetIntegration, PAPDataModeIing , and PAPRequirementsAndScope. They are not complete, but all have at least an abstract with the basic idea. JonSaperia 2010-01-30 - 09:22
PAPDataModeling had a typo this link should work. JonSaperia 2010-01-30 - 09:27

What is the consensus-based process underlying the recently-made changes? Was there a meeting? If so, where was the meeting announcement? Where are the minutes? Why were these changes made? EdwardBeroset 2010-06-21 - 10:53


Topic attachments
I Attachment Action Size Date Who Comment
docdoc CSWG_Comments_on_PAP01_2010-10-27.doc manage 68.0 K 2010-10-28 - 14:52 VishantShah CSWG comments on draft IETF informational RFC
pdfpdf ISOC_IPv6_SmartGrid_July2010.pdf manage 1444.0 K 2010-07-22 - 20:11 NadaGolmie Presentation by Phil Roberts
elsepptx Internet_Stack.pptx manage 610.7 K 2010-07-22 - 20:14 NadaGolmie Presentation by Fred Baker
elsedocx Issues_for_PAP01_5-20-10.docx manage 15.2 K 2010-07-01 - 18:35 VishantShah  
xlsxls Latency_BW.xls manage 43.5 K 2009-12-17 - 11:33 NadaGolmie Sensus Communication Requirements
docdoc Minutes_of_July_22_Detroit_PAP01_Meeting.doc manage 47.0 K 2010-08-02 - 15:10 DavidSu PAP01 July F2F meeting minutes
docdoc NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009.doc manage 737.0 K 2009-11-06 - 18:54 NadaGolmie Role of IP in AMI Networks
pdfpdf NMIssuesPaper.pdf manage 120.0 K 2010-09-23 - 09:44 JonSaperia Short white paper describing issues and need for integrated Network Management work.
docdoc Notes_St_Louis_PAP_1doc_Hughes.doc manage 58.0 K 2010-10-07 - 18:46 JoeHughes Meeting Notes from St Louis PAP 1
pptppt PAP01CallAgenda10282010.ppt manage 206.0 K 2010-10-27 - 18:11 VishantShah Oct 28 Agenda
pptppt PAP01CallAgenda10282010Rev1.ppt manage 272.0 K 2010-10-28 - 12:08 VishantShah Updated Call Agenda
pdfpdf PAP01IntegratedNMPres.pdf manage 31.4 K 2010-09-23 - 09:27 JonSaperia  
elsepptx PAP01_Agenda_09152010.pptx manage 67.4 K 2010-09-14 - 22:06 DavidSu Agenda for PAP01 F2F meeting, September 15
pptppt PAP01_F2F_Meeting_Agenda_July_22_2010.ppt manage 28.5 K 2010-07-20 - 11:40 DavidSu PAP01 F2F meeting agenda, OpenSG,
xlsxls PAP01_SecurityRFCs_v1.0_07-13-10.xls manage 37.0 K 2010-07-13 - 11:47 TedFischer PAP01 Task 2 RFC List for CSWG Requirements
pptppt PAP12November09.ppt manage 213.5 K 2009-11-19 - 13:47 NadaGolmie Priority Action Plans for IP and Wireless
wavwav PAP1and2.wav manage 58073.1 K 2009-11-19 - 12:17 CarrieParks Audio recording of PAP 1 and 2 meetings 11.19.09
elsepptx SG-NET_status_update_V2.pptx manage 658.2 K 2009-11-18 - 16:22 ErichGunther Gilmore Presentation at GridInterop
txttxt SGIP-PAP01WG_LOGs.txt manage 9160.3 K 2012-01-25 - 14:43 AaronSnyder SGIP-PAP01WG listserv list archive file
xlsxls SG_Communications_funct-reqs_v1-draft.xls manage 70.0 K 2009-12-17 - 11:32 NadaGolmie OpenSG Draft Application Communication Requirements
htmlhtm draft-baker-ietf-core-05.htm manage 131.8 K 2010-07-20 - 11:55 DavidSu Internet Protocols for the Smart Grid, Fred Baker
txttxt draft-baker-ietf-core-05.txt manage 90.7 K 2010-07-20 - 11:52 DavidSu Internet Protocols for the Smart Grid, Fred Baker
Topic revision: r104 - 2012-01-25 - 14:47:43 - AaronSnyder
Login TWiki Registration
All persons wanting to add/change content to the NIST TWiki website are required to register.
TWiki Help TWiki Help
Members Catalog of Standards
Blog Post SGIP Archive Index

SGIP 2.0 site ready to visit

In January 2013, the Smart Grid Interoperability Panel, established by NIST, fully transitioned to a private/public partnership funded by industry stakeholders in cooperation with the federal government. NIST continues an active role in the SGIP. Current news and member information now resides at


PLEASE NOTE: This wiki is a collaborative website. NIST does not necessarily endorse the views expressed, or concur with the facts presented on these sites. Further, NIST does not endorse any commercial products that may be mentioned on these sites. All the material on this website is in the public domain, including any text, diagrams, or images, unless indicated explicitly. Don't share anything on this site that you do not want to be public. Do not pass any proprietary documents or put any on the TWiki with implied public disclosure. If you do, it shall be deemed to have been disclosed on a non-confidential basis, without any restrictions on use by anyone, except that no valid copyright or patent right shall be deemed to have been waived by such disclosure. Certain commercial equipment, instruments, materials, systems, software, and trade names may be identified throughout this site in order to specify or identify technologies adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the systems or products identified are necessarily the best available for the purpose. Any data provided on this site is for illustrative purposes only, and does not imply a validation of results by NIST. By selecting externals links, you will be leaving NIST webspace. Links to other websites are provided because they may have information that would be of interest to you. No inferences should be drawn on account of other sites being referenced, or not, from this page. There may be other websites that are more appropriate for your purpose.
Ideas, requests, problems regarding TWiki? Send feedback