draft-ietf-detnet-use-cases-05.txt   draft-ietf-detnet-use-cases-06.txt 
Internet Engineering Task Force E. Grossman, Ed. Internet Engineering Task Force E. Grossman, Ed.
Internet-Draft DOLBY Internet-Draft DOLBY
Intended status: Informational C. Gunther Intended status: Informational C. Gunther
Expires: August 26, 2016 HARMAN Expires: September 5, 2016 HARMAN
P. Thubert P. Thubert
P. Wetterwald P. Wetterwald
CISCO CISCO
J. Raymond J. Raymond
HYDRO-QUEBEC HYDRO-QUEBEC
J. Korhonen J. Korhonen
BROADCOM BROADCOM
Y. Kaneko Y. Kaneko
Toshiba Toshiba
S. Das S. Das
Applied Communication Sciences Applied Communication Sciences
Y. Zha Y. Zha
HUAWEI HUAWEI
B. Varga B. Varga
J. Farkas J. Farkas
Ericsson Ericsson
F. Goetz F. Goetz
J. Schmitt J. Schmitt
Siemens Siemens
February 23, 2016 March 4, 2016
Deterministic Networking Use Cases Deterministic Networking Use Cases
draft-ietf-detnet-use-cases-05 draft-ietf-detnet-use-cases-06
Abstract Abstract
This draft documents requirements in several diverse industries to This draft documents requirements in several diverse industries to
establish multi-hop paths for characterized flows with deterministic establish multi-hop paths for characterized flows with deterministic
properties. In this context deterministic implies that streams can properties. In this context deterministic implies that streams can
be established which provide guaranteed bandwidth and latency which be established which provide guaranteed bandwidth and latency which
can be established from either a Layer 2 or Layer 3 (IP) interface, can be established from either a Layer 2 or Layer 3 (IP) interface,
and which can co-exist on an IP network with best-effort traffic. and which can co-exist on an IP network with best-effort traffic.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2016. This Internet-Draft will expire on September 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2. Pro Audio Use Cases . . . . . . . . . . . . . . . . . . . . . 5
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6 2.2. Fundamental Stream Requirements . . . . . . . . . . . . . 6
2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 6 2.2.1. Guaranteed Bandwidth . . . . . . . . . . . . . . . . 7
2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7 2.2.2. Bounded and Consistent Latency . . . . . . . . . . . 7
2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8 2.2.2.1. Optimizations . . . . . . . . . . . . . . . . . . 8
2.3. Additional Stream Requirements . . . . . . . . . . . . . 9 2.3. Additional Stream Requirements . . . . . . . . . . . . . 9
2.3.1. Deterministic Time to Establish Streaming . . . . . . 9 2.3.1. Deterministic Time to Establish Streaming . . . . . . 9
2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9 2.3.2. Use of Unused Reservations by Best-Effort Traffic . . 9
2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10 2.3.3. Layer 3 Interconnecting Layer 2 Islands . . . . . . . 10
2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10 2.3.4. Secure Transmission . . . . . . . . . . . . . . . . . 10
2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10 2.3.5. Redundant Paths . . . . . . . . . . . . . . . . . . . 10
2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 10 2.3.6. Link Aggregation . . . . . . . . . . . . . . . . . . 11
2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11 2.3.7. Traffic Segregation . . . . . . . . . . . . . . . . . 11
2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11 2.3.7.1. Packet Forwarding Rules, VLANs and Subnets . . . 11
2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11 2.3.7.2. Multicast Addressing (IPv4 and IPv6) . . . . . . 11
2.4. Integration of Reserved Streams into IT Networks . . . . 12 2.4. Integration of Reserved Streams into IT Networks . . . . 12
2.5. Security Considerations . . . . . . . . . . . . . . . . . 12 2.5. Security Considerations . . . . . . . . . . . . . . . . . 12
2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12 2.5.1. Denial of Service . . . . . . . . . . . . . . . . . . 12
2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12 2.5.2. Control Protocols . . . . . . . . . . . . . . . . . . 12
2.6. A State-of-the-Art Broadcast Installation Hits Technology 2.6. A State-of-the-Art Broadcast Installation Hits Technology
Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13 Limits . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Utility Telecom Use Cases . . . . . . . . . . . . . . . . . . 13 3. Electrical Utilities . . . . . . . . . . . . . . . . . . . . 13
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Use Case Description . . . . . . . . . . . . . . . . . . 13
3.2. Telecommunications Trends and General telecommunications 3.1.1. Transmission Use Cases . . . . . . . . . . . . . . . 13
Requirements . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1.1. Protection . . . . . . . . . . . . . . . . . . . 13
3.2.1. General Telecommunications Requirements . . . . . . . 14 3.1.1.2. Intra-Substation Process Bus Communications . . . 19
3.2.1.1. Migration to Packet-Switched Network . . . . . . 15 3.1.1.3. Wide Area Monitoring and Control Systems . . . . 20
3.2.2. Applications, Use cases and traffic patterns . . . . 16 3.1.1.4. IEC 61850 WAN engineering guidelines requirement
3.2.2.1. Transmission use cases . . . . . . . . . . . . . 16 classification . . . . . . . . . . . . . . . . . 21
3.2.2.2. Distribution use case . . . . . . . . . . . . . . 26 3.1.2. Generation Use Case . . . . . . . . . . . . . . . . . 22
3.2.2.3. Generation use case . . . . . . . . . . . . . . . 29 3.1.3. Distribution use case . . . . . . . . . . . . . . . . 23
3.2.3. Specific Network topologies of Smart Grid 3.1.3.1. Fault Location Isolation and Service Restoration
Applications . . . . . . . . . . . . . . . . . . . . 30 (FLISR) . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Precision Time Protocol . . . . . . . . . . . . . . . 31 3.2. Electrical Utilities Today . . . . . . . . . . . . . . . 24
3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 3.2.1. Security Current Practices and Limitations . . . . . 24
3.4. Security Considerations . . . . . . . . . . . . . . . . . 32 3.3. Electrical Utilities Future . . . . . . . . . . . . . . . 26
3.4.1. Current Practices and Their Limitations . . . . . . . 32 3.3.1. Migration to Packet-Switched Network . . . . . . . . 26
3.4.2. Security Trends in Utility Networks . . . . . . . . . 34 3.3.2. Telecommunications Trends . . . . . . . . . . . . . . 27
4. Building Automation Systems . . . . . . . . . . . . . . . . . 35 3.3.2.1. General Telecommunications Requirements . . . . . 27
4.1. Use Case Description . . . . . . . . . . . . . . . . . . 35 3.3.2.2. Specific Network topologies of Smart Grid
4.2. Building Automation Systems Today . . . . . . . . . . . . 36 Applications . . . . . . . . . . . . . . . . . . 28
4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 36 3.3.2.3. Precision Time Protocol . . . . . . . . . . . . . 29
4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 37 3.3.3. Security Trends in Utility Networks . . . . . . . . . 30
4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 39 3.4. Electrical Utilities Asks . . . . . . . . . . . . . . . . 32
4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 39 4. Building Automation Systems . . . . . . . . . . . . . . . . . 32
4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 39 4.1. Use Case Description . . . . . . . . . . . . . . . . . . 32
4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 40 4.2. Building Automation Systems Today . . . . . . . . . . . . 32
4.2.4. Security Considerations . . . . . . . . . . . . . . . 40 4.2.1. BAS Architecture . . . . . . . . . . . . . . . . . . 33
4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 40 4.2.2. BAS Deployment Model . . . . . . . . . . . . . . . . 34
4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2.3. Use Cases for Field Networks . . . . . . . . . . . . 36
5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 41 4.2.3.1. Environmental Monitoring . . . . . . . . . . . . 36
5.1. Use Case Description . . . . . . . . . . . . . . . . . . 41 4.2.3.2. Fire Detection . . . . . . . . . . . . . . . . . 36
5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 42 4.2.3.3. Feedback Control . . . . . . . . . . . . . . . . 37
5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 42 4.2.4. Security Considerations . . . . . . . . . . . . . . . 37
5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 43 4.3. BAS Future . . . . . . . . . . . . . . . . . . . . . . . 37
5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 43 4.4. BAS Asks . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.1. Unified Wireless Network and Management . . . . . . . 43 5. Wireless for Industrial . . . . . . . . . . . . . . . . . . . 38
5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 45 5.1. Use Case Description . . . . . . . . . . . . . . . . . . 38
5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 46 5.1.1. Network Convergence using 6TiSCH . . . . . . . . . . 39
5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 46 5.1.2. Common Protocol Development for 6TiSCH . . . . . . . 39
5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 47
5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 47 5.2. Wireless Industrial Today . . . . . . . . . . . . . . . . 40
5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 48 5.3. Wireless Industrial Future . . . . . . . . . . . . . . . 40
6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 48 5.3.1. Unified Wireless Network and Management . . . . . . . 40
6.1. Use Case Description . . . . . . . . . . . . . . . . . . 48 5.3.1.1. PCE and 6TiSCH ARQ Retries . . . . . . . . . . . 42
6.1.1. Network Architecture . . . . . . . . . . . . . . . . 48 5.3.2. Schedule Management by a PCE . . . . . . . . . . . . 43
6.1.2. Time Synchronization Requirements . . . . . . . . . . 49 5.3.2.1. PCE Commands and 6TiSCH CoAP Requests . . . . . . 43
6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 51 5.3.2.2. 6TiSCH IP Interface . . . . . . . . . . . . . . . 44
6.1.4. Security Considerations . . . . . . . . . . . . . . . 51 5.3.3. 6TiSCH Security Considerations . . . . . . . . . . . 44
6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 52 5.4. Wireless Industrial Asks . . . . . . . . . . . . . . . . 45
6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 52 6. Cellular Radio Use Cases . . . . . . . . . . . . . . . . . . 45
6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 54 6.1. Use Case Description . . . . . . . . . . . . . . . . . . 45
7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 54 6.1.1. Network Architecture . . . . . . . . . . . . . . . . 45
7.1. Use Case Description . . . . . . . . . . . . . . . . . . 54 6.1.2. Time Synchronization Requirements . . . . . . . . . . 46
7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 55 6.1.3. Time-Sensitive Stream Requirements . . . . . . . . . 48
7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 56 6.1.4. Security Considerations . . . . . . . . . . . . . . . 48
7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 56 6.2. Cellular Radio Networks Today . . . . . . . . . . . . . . 49
7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 56 6.3. Cellular Radio Networks Future . . . . . . . . . . . . . 49
7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 56 6.4. Cellular Radio Networks Asks . . . . . . . . . . . . . . 51
7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 57 7. Cellular Coordinated Multipoint Processing (CoMP) . . . . . . 51
7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 57 7.1. Use Case Description . . . . . . . . . . . . . . . . . . 51
8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 58 7.1.1. CoMP Architecture . . . . . . . . . . . . . . . . . . 52
8.1. Use Case Description . . . . . . . . . . . . . . . . . . 58 7.1.2. Delay Sensitivity in CoMP . . . . . . . . . . . . . . 53
8.2. Industrial M2M Communication Today . . . . . . . . . . . 59 7.2. CoMP Today . . . . . . . . . . . . . . . . . . . . . . . 53
8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 59 7.3. CoMP Future . . . . . . . . . . . . . . . . . . . . . . . 53
8.2.2. Stream Creation and Destruction . . . . . . . . . . . 60 7.3.1. Mobile Industry Overall Goals . . . . . . . . . . . . 53
8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 60 7.3.2. CoMP Infrastructure Goals . . . . . . . . . . . . . . 54
8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 61 7.4. CoMP Asks . . . . . . . . . . . . . . . . . . . . . . . . 54
9. Internet-based Applications . . . . . . . . . . . . . . . . . 61 8. Industrial M2M . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Use Case Description . . . . . . . . . . . . . . . . . . 61 8.1. Use Case Description . . . . . . . . . . . . . . . . . . 55
9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 61 8.2. Industrial M2M Communication Today . . . . . . . . . . . 56
9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 61 8.2.1. Transport Parameters . . . . . . . . . . . . . . . . 56
9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 61 8.2.2. Stream Creation and Destruction . . . . . . . . . . . 57
9.2. Internet-Based Applications Today . . . . . . . . . . . . 62 8.3. Industrial M2M Future . . . . . . . . . . . . . . . . . . 57
9.3. Internet-Based Applications Future . . . . . . . . . . . 62 8.4. Industrial M2M Asks . . . . . . . . . . . . . . . . . . . 58
9.4. Internet-Based Applications Asks . . . . . . . . . . . . 62 9. Internet-based Applications . . . . . . . . . . . . . . . . . 58
10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 62 9.1. Use Case Description . . . . . . . . . . . . . . . . . . 58
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 9.1.1. Media Content Delivery . . . . . . . . . . . . . . . 58
11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 63 9.1.2. Online Gaming . . . . . . . . . . . . . . . . . . . . 58
11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 64 9.1.3. Virtual Reality . . . . . . . . . . . . . . . . . . . 58
11.3. Building Automation Systems . . . . . . . . . . . . . . 64 9.2. Internet-Based Applications Today . . . . . . . . . . . . 59
11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 64 9.3. Internet-Based Applications Future . . . . . . . . . . . 59
11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 64 9.4. Internet-Based Applications Asks . . . . . . . . . . . . 59
11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 64 10. Use Case Common Elements . . . . . . . . . . . . . . . . . . 59
11.7. Internet Applications and CoMP . . . . . . . . . . . . . 64 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
12. Informative References . . . . . . . . . . . . . . . . . . . 65 11.1. Pro Audio . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 11.2. Utility Telecom . . . . . . . . . . . . . . . . . . . . 61
11.3. Building Automation Systems . . . . . . . . . . . . . . 61
11.4. Wireless for Industrial . . . . . . . . . . . . . . . . 61
11.5. Cellular Radio . . . . . . . . . . . . . . . . . . . . . 61
11.6. Industrial M2M . . . . . . . . . . . . . . . . . . . . . 61
11.7. Internet Applications and CoMP . . . . . . . . . . . . . 61
12. Informative References . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
This draft presents use cases from diverse industries which have in This draft presents use cases from diverse industries which have in
common a need for deterministic streams, but which also differ common a need for deterministic streams, but which also differ
notably in their network topologies and specific desired behavior. notably in their network topologies and specific desired behavior.
Together, they provide broad industry context for DetNet and a Together, they provide broad industry context for DetNet and a
yardstick against which proposed DetNet designs can be measured (to yardstick against which proposed DetNet designs can be measured (to
what extent does a proposed design satisfy these various use cases?) what extent does a proposed design satisfy these various use cases?)
skipping to change at page 13, line 24 skipping to change at page 13, line 27
they possibly could with packet-based technology. They constructed they possibly could with packet-based technology. They constructed
seven individual studios using layer 2 LANS (using IEEE 802.1 AVB) seven individual studios using layer 2 LANS (using IEEE 802.1 AVB)
that were entirely effective at routing audio within the LANs, and that were entirely effective at routing audio within the LANs, and
they were very happy with the results, however to interconnect these they were very happy with the results, however to interconnect these
layer 2 LAN islands together they ended up using dedicated links layer 2 LAN islands together they ended up using dedicated links
because there is no standards-based routing solution available. because there is no standards-based routing solution available.
This is the kind of motivation we have to develop these standards This is the kind of motivation we have to develop these standards
because customers are ready and able to use them. because customers are ready and able to use them.
3. Utility Telecom Use Cases 3. Electrical Utilities
3.1. Overview
[I-D.finn-detnet-problem-statement] defines the characteristics of a
deterministic flow as a data communication flow with a bounded
latency, extraordinarily low frame loss, and a very narrow jitter.
This document intends to define the utility requirements for
deterministic networking.
Utility Telecom Networks
The business and technology trends that are sweeping the utility
industry will drastically transform the utility business from the way
it has been for many decades. At the core of many of these changes
is a drive to modernize the electrical grid with an integrated
telecommunications infrastructure. However, interoperability,
concerns, legacy networks, disparate tools, and stringent security
requirements all add complexity to the grid transformation. Given
the range and diversity of the requirements that should be addressed
by the next generation telecommunications infrastructure, utilities
need to adopt a holistic architectural approach to integrate the
electrical grid with digital telecommunications across the entire
power delivery chain.
Many utilities still rely on complex environments formed of multiple
application-specific, proprietary networks. Information is siloed
between operational areas. This prevents utility operations from
realizing the operational efficiency benefits, visibility, and
functional integration of operational information across grid
applications and data networks. The key to modernizing grid
telecommunications is to provide a common, adaptable, multi-service
network infrastructure for the entire utility organization. Such a
network serves as the platform for current capabilities while
enabling future expansion of the network to accommodate new
applications and services.
To meet this diverse set of requirements, both today and in the
future, the next generation utility telecommunnications network will
be based on open-standards-based IP architecture. An end-to-end IP
architecture takes advantage of nearly three decades of IP technology
development, facilitating interoperability across disparate networks
and devices, as it has been already demonstrated in many mission-
critical and highly secure networks.
IEC (International Electrotechnical Commission) and different
National Committees have mandated a specific adhoc group (AHG8) to
define the migration strategy to IPv6 for all the IEC TC57 power
automation standards. IPv6 is seen as the obvious future
telecommunications technology for the Smart Grid. The Adhoc Group
has disclosed, to the IEC coordination group, their conclusions at
the end of 2014.
It is imperative that utilities participate in standards development
bodies to influence the development of future solutions and to
benefit from shared experiences of other utilities and vendors.
3.2. Telecommunications Trends and General telecommunications
Requirements
These general telecommunications requirements are over and above the
specific requirements of the use cases that have been addressed so
far. These include both current and future telecommunications
related requirements that should be factored into the network
architecture and design.
3.2.1. General Telecommunications Requirements
o IP Connectivity everywhere
o Monitoring services everywhere and from different remote centers
o Move services to a virtual data center
o Unify access to applications / information from the corporate
network
o Unify services
o Unified Communications Solutions
o Mix of fiber and microwave technologies - obsolescence of SONET/
SDH or TDM
o Standardize grid telecommunications protocol to opened standard to
ensure interoperability
o Reliable Telecommunications for Transmission and Distribution
Substations
o IEEE 1588 time synchronization Client / Server Capabilities
o Integration of Multicast Design
o QoS Requirements Mapping
o Enable Future Network Expansion
o Substation Network Resilience
o Fast Convergence Design
o Scalable Headend Design
o Define Service Level Agreements (SLA) and Enable SLA Monitoring
o Integration of 3G/4G Technologies and future technologies
o Ethernet Connectivity for Station Bus Architecture
o Ethernet Connectivity for Process Bus Architecture
o Protection, teleprotection and PMU (Phaser Measurement Unit) on IP
3.2.1.1. Migration to Packet-Switched Network
Throughout the world, utilities are increasingly planning for a
future based on smart grid applications requiring advanced
telecommunications systems. Many of these applications utilize
packet connectivity for communicating information and control signals
across the utility's Wide Area Network (WAN), made possible by
technologies such as multiprotocol label switching (MPLS). The data
that traverses the utility WAN includes:
o Grid monitoring, control, and protection data
o Non-control grid data (e.g. asset data for condition-based
monitoring)
o Physical safety and security data (e.g. voice and video)
o Remote worker access to corporate applications (voice, maps,
schematics, etc.)
o Field area network backhaul for smart metering, and distribution
grid management
o Enterprise traffic (email, collaboration tools, business 3.1. Use Case Description
applications)
WANs support this wide variety of traffic to and from substations, Many systems that an electrical utility deploys today rely on high
the transmission and distribution grid, generation sites, between availability and deterministic behavior of the underlying networks.
control centers, and between work locations and data centers. To Here we present use cases in Transmission, Generation and
maintain this rapidly expanding set of applications, many utilities Distribution, including key timing and reliability metrics. We also
are taking steps to evolve present time-division multiplexing (TDM) discuss security issues and industry trends which affect the
based and frame relay infrastructures to packet systems. Packet- architecture of next generation utility networks
based networks are designed to provide greater functionalities and
higher levels of service for applications, while continuing to
deliver reliability and deterministic (real-time) traffic support.
3.2.2. Applications, Use cases and traffic patterns 3.1.1. Transmission Use Cases
Among the numerous applications and use cases that a utility deploys 3.1.1.1. Protection
today, many rely on high availability and deterministic behaviour of
the telecommunications networks. Protection use cases and generation
control are the most demanding and can't rely on a best effort
approach.
3.2.2.1. Transmission use cases Protection means not only the protection of human operators but also
the protection of the electrical equipment and the preservation of
the stability and frequency of the grid. If a fault occurs in the
transmission or distribution of electricity then severe damage can
occur to human operators, electrical equipment and the grid itself,
leading to blackouts.
Protection means not only the protection of the human operator but Communication links in conjunction with protection relays are used to
also the protection of the electric equipments and the preservation selectively isolate faults on high voltage lines, transformers,
of the stability and frequency of the grid. If a default occurs on reactors and other important electrical equipment. The role of the
the transmission or the distribution of the electricity, important teleprotection system is to selectively disconnect a faulty part by
damages could occured to the human operator but also to very costly transferring command signals within the shortest possible time.
electrical equipments and perturb the grid leading to blackouts. The
time and reliability requirements are very strong to avoid dramatic
impacts to the electrical infrastructure.
3.2.2.1.1. Tele Protection 3.1.1.1.1. Key Criteria
The key criteria for measuring Teleprotection performance are command The key criteria for measuring teleprotection performance are command
transmission time, dependability and security. These criteria are transmission time, dependability and security. These criteria are
defined by the IEC standard 60834 as follows: defined by the IEC standard 60834 as follows:
o Transmission time (Speed): The time between the moment where state o Transmission time (Speed): The time between the moment where state
changes at the transmitter input and the moment of the changes at the transmitter input and the moment of the
corresponding change at the receiver output, including propagation corresponding change at the receiver output, including propagation
delay. Overall operating time for a Teleprotection system delay. Overall operating time for a teleprotection system
includes the time for initiating the command at the transmitting includes the time for initiating the command at the transmitting
end, the propagation delay over the network (including equipments) end, the propagation delay over the network (including equipments)
and the selection and decision time at the receiving end, and the selection and decision time at the receiving end,
including any additional delay due to a noisy environment. including any additional delay due to a noisy environment.
o Dependability: The ability to issue and receive valid commands in o Dependability: The ability to issue and receive valid commands in
the presence of interference and/or noise, by minimizing the the presence of interference and/or noise, by minimizing the
probability of missing command (PMC). Dependability targets are probability of missing command (PMC). Dependability targets are
typically set for a specific bit error rate (BER) level. typically set for a specific bit error rate (BER) level.
o Security: The ability to prevent false tripping due to a noisy o Security: The ability to prevent false tripping due to a noisy
environment, by minimizing the probability of unwanted commands environment, by minimizing the probability of unwanted commands
(PUC). Security targets are also set for a specific bit error (PUC). Security targets are also set for a specific bit error
rate (BER) level. rate (BER) level.
Additional key elements that may impact Teleprotection performance Additional elements of the the teleprotection system that impact its
include bandwidth rate of the Teleprotection system and its performance include:
resiliency or failure recovery capacity. Transmission time,
bandwidth utilization and resiliency are directly linked to the
telecommunications equipments and the connections that are used to
transfer the commands between relays.
3.2.2.1.1.1. Latency Budget Consideration o Network bandwidth
o Failure recovery capacity (aka resiliency)
3.1.1.1.2. Fault Detection and Clearance Timing
Most power line equipment can tolerate short circuits or faults for
up to approximately five power cycles before sustaining irreversible
damage or affecting other segments in the network. This translates
to total fault clearance time of 100ms. As a safety precaution,
however, actual operation time of protection systems is limited to
70- 80 percent of this period, including fault recognition time,
command transmission time and line breaker switching time.
Delay requirements for utility networks may vary depending upon a
number of parameters, such as the specific protection equipments
used. Most power line equipment can tolerate short circuits or
faults for up to approximately five power cycles before sustaining
irreversible damage or affecting other segments in the network. This
translates to total fault clearance time of 100ms. As a safety
precaution, however, actual operation time of protection systems is
limited to 70- 80 percent of this period, including fault recognition
time, command transmission time and line breaker switching time.
Some system components, such as large electromechanical switches, Some system components, such as large electromechanical switches,
require particularly long time to operate and take up the majority of require particularly long time to operate and take up the majority of
the total clearance time, leaving only a 10ms window for the the total clearance time, leaving only a 10ms window for the
telecommunications part of the protection scheme, independent of the telecommunications part of the protection scheme, independent of the
distance to travel. Given the sensitivity of the issue, new networks distance to travel. Given the sensitivity of the issue, new networks
impose requirements that are even more stringent: IEC standard 61850 impose requirements that are even more stringent: IEC standard 61850
limits the transfer time for protection messages to 1/4 - 1/2 cycle limits the transfer time for protection messages to 1/4 - 1/2 cycle
or 4 - 8ms (for 60Hz lines) for the most critical messages. or 4 - 8ms (for 60Hz lines) for the most critical messages.
3.2.2.1.1.2. Asymetric delay 3.1.1.1.3. Symmetric Channel Delay
In addition to minimal transmission delay, a differential protection Teleprotection channels which are differential must be synchronous,
telecommunications channel must be synchronous, i.e., experiencing which means that any delays on the transmit and receive paths must
symmetrical channel delay in transmit and receive paths. This match each other. Teleprotection systems ideally support zero
requires special attention in jitter-prone packet networks. While asymmetric delay; typical legacy relays can tolerate delay
optimally Teleprotection systems should support zero asymmetric discrepancies of up to 750us.
delay, typical legacy relays can tolerate discrepancies of up to
750us.
The main tools available for lowering delay variation below this Some tools available for lowering delay variation below this
threshold are: threshold are:
o A jitter buffer at the multiplexers on each end of the line can be o For legacy systems using Time Division Multiplexing (TDM), jitter
used to offset delay variation by queuing sent and received buffers at the multiplexers on each end of the line can be used to
packets. The length of the queues must balance the need to offset delay variation by queuing sent and received packets. The
regulate the rate of transmission with the need to limit overall length of the queues must balance the need to regulate the rate of
delay, as larger buffers result in increased latency. This is the transmission with the need to limit overall delay, as larger
old TDM traditional way to fulfill this requirement. buffers result in increased latency.
o Traffic management tools ensure that the Teleprotection signals o For jitter-prone IP packet networks, traffic management tools can
receive the highest transmission priority and minimize the number ensure that the teleprotection signals receive the highest
of jitter addition during the path. This is one way to meet the transmission priority to minimize jitter.
requirement in IP networks.
o Standard Packet-Based synchronization technologies, such as o Standard packet-based synchronization technologies, such as
1588-2008 Precision Time Protocol (PTP) and Synchronous Ethernet 1588-2008 Precision Time Protocol (PTP) and Synchronous Ethernet
(Sync-E), can help maintain stable networks by keeping a highly (Sync-E), can help keep networks stable by maintaining a highly
accurate clock source on the different network devices involved. accurate clock source on the various network devices.
3.2.2.1.1.2.1. Other traffic characteristics
o Redundancy: The existence in a system of more than one means of
accomplishing a given function.
o Recovery time : The duration of time within which a business
process must be restored after any type of disruption in order to
avoid unacceptable consequences associated with a break in
business continuity.
o performance management : In networking, a management function
defined for controlling and analyzing different parameters/metrics
such as the throughput, error rate.
o packet loss : One or more packets of data travelling across
network fail to reach their destination.
3.2.2.1.1.2.2. Teleprotection network requirements 3.1.1.1.4. Teleprotection Network Requirements (IEC 61850)
The following table captures the main network requirements (this is The following table captures the main network metrics as based on the
based on IEC 61850 standard) IEC 61850 standard.
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| Teleprotection Requirement | Attribute | | Teleprotection Requirement | Attribute |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
| One way maximum delay | 4-10 ms | | One way maximum delay | 4-10 ms |
| Asymetric delay required | Yes | | Asymetric delay required | Yes |
| Maximum jitter | less than 250 us (750 us for legacy | | Maximum jitter | less than 250 us (750 us for legacy |
| | IED) | | | IED) |
| Topology | Point to point, point to Multi- | | Topology | Point to point, point to Multi- |
| | point | | | point |
skipping to change at page 19, line 30 skipping to change at page 16, line 25
| precise timing required | Yes | | precise timing required | Yes |
| Recovery time on node | less than 50ms - hitless | | Recovery time on node | less than 50ms - hitless |
| failure | | | failure | |
| performance management | Yes, Mandatory | | performance management | Yes, Mandatory |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 0.1% to 1% | | Packet loss | 0.1% to 1% |
+-----------------------------+-------------------------------------+ +-----------------------------+-------------------------------------+
Table 1: Teleprotection network requirements Table 1: Teleprotection network requirements
3.2.2.1.2. Inter-Trip Protection scheme 3.1.1.1.5. Inter-Trip Protection scheme
Inter-tripping is the controlled tripping of a circuit breaker to "Inter-tripping" is the signal-controlled tripping of a circuit
complete the isolation of a circuit or piece of apparatus in concert breaker to complete the isolation of a circuit or piece of apparatus
with the tripping of other circuit breakers. The main use of such in concert with the tripping of other circuit breakers.
schemes is to ensure that protection at both ends of a faulted
circuit will operate to isolate the equipment concerned. Inter-
tripping schemes use signaling to convey a trip command to remote
circuit breakers to isolate circuits.
+--------------------------------+----------------------------------+ +--------------------------------+----------------------------------+
| Inter-Trip protection | Attribute | | Inter-Trip protection | Attribute |
| Requirement | | | Requirement | |
+--------------------------------+----------------------------------+ +--------------------------------+----------------------------------+
| One way maximum delay | 5 ms | | One way maximum delay | 5 ms |
| Asymetric delay required | No | | Asymetric delay required | No |
| Maximum jitter | Not critical | | Maximum jitter | Not critical |
| Topology | Point to point, point to Multi- | | Topology | Point to point, point to Multi- |
| | point | | | point |
skipping to change at page 20, line 25 skipping to change at page 17, line 5
| Availability | 99.9999 | | Availability | 99.9999 |
| precise timing required | Yes | | precise timing required | Yes |
| Recovery time on node failure | less than 50ms - hitless | | Recovery time on node failure | less than 50ms - hitless |
| performance management | Yes, Mandatory | | performance management | Yes, Mandatory |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 0.1% | | Packet loss | 0.1% |
+--------------------------------+----------------------------------+ +--------------------------------+----------------------------------+
Table 2: Inter-Trip protection network requirements Table 2: Inter-Trip protection network requirements
3.2.2.1.3. Current Differential Protection Scheme 3.1.1.1.6. Current Differential Protection Scheme
Current differential protection is commonly used for line protection, Current differential protection is commonly used for line protection,
and is typical for protecting parallel circuits. A main advantage and is typical for protecting parallel circuits. At both end of the
for differential protection is that, compared to overcurrent lines the current is measured by the differential relays, and both
protection, it allows only the faulted circuit to be de-energized in relays will trip the circuit breaker if the current going into the
case of a fault. At both end of the lines, the current is measured line does not equal the current going out of the line. This type of
by the differential relays, and based on Kirchhoff's law, both relays protection scheme assumes some form of communications being present
will trip the circuit breaker if the current going into the line does between the relays at both end of the line, to allow both relays to
not equal the current going out of the line. This type of protection compare measured current values. Line differential protection
scheme assumes some form of communications being present between the schemes assume a very low telecommunications delay between both
relays at both end of the line, to allow both relays to compare relays, often as low as 5ms. Moreover, as those systems are often
measured current values. A fault in line 1 will cause overcurrent to not time-synchronized, they also assume symmetric telecommunications
be flowing in both lines, but because the current in line 2 is a paths with constant delay, which allows comparing current measurement
through following current, this current is measured equal at both values taken at the exact same time.
ends of the line, therefore the differential relays on line 2 will
not trip line 2. Line 1 will be tripped, as the relays will not
measure the same currents at both ends of the line. Line
differential protection schemes assume a very low telecommunications
delay between both relays, often as low as 5ms. Moreover, as those
systems are often not time-synchronized, they also assume symmetric
telecommunications paths with constant delay, which allows comparing
current measurement values taken at the exact same time.
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| Current Differential protection | Attribute | | Current Differential protection | Attribute |
| Requirement | | | Requirement | |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| One way maximum delay | 5 ms | | One way maximum delay | 5 ms |
| Asymetric delay Required | Yes | | Asymetric delay Required | Yes |
| Maximum jitter | less than 250 us (750us for | | Maximum jitter | less than 250 us (750us for |
| | legacy IED) | | | legacy IED) |
| Topology | Point to point, point to | | Topology | Point to point, point to |
| | Multi-point | | | Multi-point |
| Bandwidth | 64 Kbps | | Bandwidth | 64 Kbps |
| Availability | 99.9999 | | Availability | 99.9999 |
| precise timing required | Yes | | precise timing required | Yes |
| Recovery time on node failure | less than 50ms - hitless | | Recovery time on node failure | less than 50ms - hitless |
| performance management | Yes, Mandatory | | performance management | Yes, Mandatory |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 0.1% | | Packet loss | 0.1% |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
Table 3: Current Differential Protection requirements Table 3: Current Differential Protection metrics
3.2.2.1.4. Distance Protection Scheme 3.1.1.1.7. Distance Protection Scheme
Distance (Impedance Relay) protection scheme is based on voltage and Distance (Impedance Relay) protection scheme is based on voltage and
current measurements. A fault on a circuit will generally create a current measurements. The network metrics are similar (but not
sag in the voltage level. If the ratio of voltage to current identical to) Current Differential protection.
measured at the protection relay terminals, which equates to an
impedance element, falls within a set threshold the circuit breaker
will operate. The operating characteristics of this protection are
based on the line characteristics. This means that when a fault
appears on the line, the impedance setting in the relay is compared
to the apparent impedance of the line from the relay terminals to the
fault. If the relay setting is determined to be below the apparent
impedance it is determined that the fault is within the zone of
protection. When the transmission line length is under a minimum
length, distance protection becomes more difficult to coordinate. In
these instances the best choice of protection is current differential
protection.
+-------------------------------+-----------------------------------+ +-------------------------------+-----------------------------------+
| Distance protection | Attribute | | Distance protection | Attribute |
| Requirement | | | Requirement | |
+-------------------------------+-----------------------------------+ +-------------------------------+-----------------------------------+
| One way maximum delay | 5 ms | | One way maximum delay | 5 ms |
| Asymetric delay Required | No | | Asymetric delay Required | No |
| Maximum jitter | Not critical | | Maximum jitter | Not critical |
| Topology | Point to point, point to Multi- | | Topology | Point to point, point to Multi- |
| | point | | | point |
skipping to change at page 22, line 25 skipping to change at page 18, line 25
| Availability | 99.9999 | | Availability | 99.9999 |
| precise timing required | Yes | | precise timing required | Yes |
| Recovery time on node failure | less than 50ms - hitless | | Recovery time on node failure | less than 50ms - hitless |
| performance management | Yes, Mandatory | | performance management | Yes, Mandatory |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 0.1% | | Packet loss | 0.1% |
+-------------------------------+-----------------------------------+ +-------------------------------+-----------------------------------+
Table 4: Distance Protection requirements Table 4: Distance Protection requirements
3.2.2.1.5. Inter-Substation Protection Signaling 3.1.1.1.8. Inter-Substation Protection Signaling
This use case describes the exchange of Sampled Value and/or GOOSE This use case describes the exchange of Sampled Value and/or GOOSE
(Generic Object Oriented Substation Events) message between (Generic Object Oriented Substation Events) message between
Intelligent Electronic Devices (IED) in two substations for Intelligent Electronic Devices (IED) in two substations for
protection and tripping coordination. The two IEDs are in a master- protection and tripping coordination. The two IEDs are in a master-
slave mode. slave mode.
The Current Transformer or Voltage Transformer (CT/VT) in one The Current Transformer or Voltage Transformer (CT/VT) in one
substation sends the sampled analog voltage or current value to the substation sends the sampled analog voltage or current value to the
Merging Unit (MU) over hard wire. The merging unit sends the time- Merging Unit (MU) over hard wire. The MU sends the time-synchronized
synchronized 61850-9-2 sampled values to the slave IED. The slave 61850-9-2 sampled values to the slave IED. The slave IED forwards
IED forwards the information to the Master IED in the other the information to the Master IED in the other substation. The
substation. The master IED makes the determination (for example master IED makes the determination (for example based on sampled
based on sampled value differentials) to send a trip command to the value differentials) to send a trip command to the originating IED.
originating IED. Once the slave IED/Relay receives the GOOSE trip Once the slave IED/Relay receives the GOOSE trip for breaker
for breaker tripping, it opens the breaker. It then sends a tripping, it opens the breaker. It then sends a confirmation message
confirmation message back to the master. All data exchanges between back to the master. All data exchanges between IEDs are either
IEDs are either through Sampled Value and/or GOOSE messages. through Sampled Value and/or GOOSE messages.
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| Inter-Substation protection | Attribute | | Inter-Substation protection | Attribute |
| Requirement | | | Requirement | |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| One way maximum delay | 5 ms | | One way maximum delay | 5 ms |
| Asymetric delay Required | No | | Asymetric delay Required | No |
| Maximum jitter | Not critical | | Maximum jitter | Not critical |
| Topology | Point to point, point to | | Topology | Point to point, point to |
| | Multi-point | | | Multi-point |
skipping to change at page 23, line 25 skipping to change at page 19, line 25
| Availability | 99.9999 | | Availability | 99.9999 |
| precise timing required | Yes | | precise timing required | Yes |
| Recovery time on node failure | less than 50ms - hitless | | Recovery time on node failure | less than 50ms - hitless |
| performance management | Yes, Mandatory | | performance management | Yes, Mandatory |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 1% | | Packet loss | 1% |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
Table 5: Inter-Substation Protection requirements Table 5: Inter-Substation Protection requirements
3.2.2.1.6. Intra-Substation Process Bus Communications 3.1.1.2. Intra-Substation Process Bus Communications
This use case describes the data flow from the CT/VT to the IEDs in This use case describes the data flow from the CT/VT to the IEDs in
the substation via the merging unit (MU). The CT/VT in the the substation via the MU. The CT/VT in the substation send the
substation send the sampled value (analog voltage or current) to the sampled value (analog voltage or current) to the MU over hard wire.
Merging Unit (MU) over hard wire. The merging unit sends the time- The MU sends the time-synchronized 61850-9-2 sampled values to the
synchronized 61850-9-2 sampled values to the IEDs in the substation IEDs in the substation in GOOSE message format. The GPS Master Clock
in GOOSE message format. The GPS Master Clock can send 1PPS or can send 1PPS or IRIG-B format to the MU through a serial port or
IRIG-B format to MU through serial port, or IEEE 1588 protocol via IEEE 1588 protocol via a network. Process bus communication using
network. Process bus communication using 61850 simplifies 61850 simplifies connectivity within the substation and removes the
connectivity within the substation and removes the requirement for requirement for multiple serial connections and removes the slow
multiple serial connections and removes the slow serial bus serial bus architectures that are typically used. This also ensures
architectures that are typically used. This also ensures increased increased flexibility and increased speed with the use of multicast
flexibility and increased speed with the use of multicast messaging messaging between multiple devices.
between multiple devices.
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| Intra-Substation protection | Attribute | | Intra-Substation protection | Attribute |
| Requirement | | | Requirement | |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
| One way maximum delay | 5 ms | | One way maximum delay | 5 ms |
| Asymetric delay Required | No | | Asymetric delay Required | No |
| Maximum jitter | Not critical | | Maximum jitter | Not critical |
| Topology | Point to point, point to | | Topology | Point to point, point to |
| | Multi-point | | | Multi-point |
skipping to change at page 24, line 25 skipping to change at page 20, line 25
| Availability | 99.9999 | | Availability | 99.9999 |
| precise timing required | Yes | | precise timing required | Yes |
| Recovery time on Node failure | less than 50ms - hitless | | Recovery time on Node failure | less than 50ms - hitless |
| performance management | Yes, Mandatory | | performance management | Yes, Mandatory |
| Redundancy | Yes - No | | Redundancy | Yes - No |
| Packet loss | 0.1% | | Packet loss | 0.1% |
+----------------------------------+--------------------------------+ +----------------------------------+--------------------------------+
Table 6: Intra-Substation Protection requirements Table 6: Intra-Substation Protection requirements
3.2.2.1.7. Wide Area Monitoring and Control Systems 3.1.1.3. Wide Area Monitoring and Control Systems
The application of synchrophasor measurement data from Phasor The application of synchrophasor measurement data from Phasor
Measurement Units (PMU) to Wide Area Monitoring and Control Systems Measurement Units (PMU) to Wide Area Monitoring and Control Systems
promises to provide important new capabilities for improving system promises to provide important new capabilities for improving system
stability. Access to PMU data enables more timely situational stability. Access to PMU data enables more timely situational
awareness over larger portions of the grid than what has been awareness over larger portions of the grid than what has been
possible historically with normal SCADA (Supervisory Control and Data possible historically with normal SCADA (Supervisory Control and Data
Acquisition) data. Handling the volume and real-time nature of Acquisition) data. Handling the volume and real-time nature of
synchrophasor data presents unique challenges for existing synchrophasor data presents unique challenges for existing
application architectures. Wide Area management System (WAMS) makes application architectures. Wide Area management System (WAMS) makes
skipping to change at page 25, line 29 skipping to change at page 21, line 29
| Recovery time on | less than 50ms - hitless | | Recovery time on | less than 50ms - hitless |
| Node failure | | | Node failure | |
| performance | Yes, Mandatory | | performance | Yes, Mandatory |
| management | | | management | |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 1% | | Packet loss | 1% |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 7: WAMS Special Communication Requirements Table 7: WAMS Special Communication Requirements
3.2.2.1.8. IEC 61850 WAN engineering guidelines requirement 3.1.1.4. IEC 61850 WAN engineering guidelines requirement
classification classification
The IEC (International Electrotechnical Commission) has recently The IEC (International Electrotechnical Commission) has recently
published a Technical Report which offers guidelines on how to define published a Technical Report which offers guidelines on how to define
and deploy Wide Area Networks for the interconnections of electric and deploy Wide Area Networks for the interconnections of electric
substations, generation plants and SCADA operation centers. The IEC substations, generation plants and SCADA operation centers. The IEC
61850-90-12 is providing a classification of WAN communication 61850-90-12 is providing a classification of WAN communication
requirements into 4 classes. You will find herafter the table requirements into 4 classes. Table 8 summarizes these requirements:
summarizing these requirements:
+----------------+------------+------------+------------+-----------+ +----------------+------------+------------+------------+-----------+
| WAN | Class WA | Class WB | Class WC | Class WD | | WAN | Class WA | Class WB | Class WC | Class WD |
| Requirement | | | | | | Requirement | | | | |
+----------------+------------+------------+------------+-----------+ +----------------+------------+------------+------------+-----------+
| Application | EHV (Extra | HV (High | MV (Medium | General | | Application | EHV (Extra | HV (High | MV (Medium | General |
| field | High | Voltage) | Voltage) | purpose | | field | High | Voltage) | Voltage) | purpose |
| | Voltage) | | | | | | Voltage) | | | |
| Latency | 5 ms | 10 ms | 100 ms | > 100 ms | | Latency | 5 ms | 10 ms | 100 ms | > 100 ms |
| Jitter | 10 us | 100 us | 1 ms | 10 ms | | Jitter | 10 us | 100 us | 1 ms | 10 ms |
skipping to change at page 26, line 29 skipping to change at page 22, line 29
| | 10-6 | 10-4 | | | | | 10-6 | 10-4 | | |
| Unavailability | 10-7 to | 10-5 to | 10-3 | | | Unavailability | 10-7 to | 10-5 to | 10-3 | |
| | 10-6 | 10-4 | | | | | 10-6 | 10-4 | | |
| Recovery delay | Zero | 50 ms | 5 s | 50 s | | Recovery delay | Zero | 50 ms | 5 s | 50 s |
| Cyber security | extremely | High | Medium | Medium | | Cyber security | extremely | High | Medium | Medium |
| | high | | | | | | high | | | |
+----------------+------------+------------+------------+-----------+ +----------------+------------+------------+------------+-----------+
Table 8: 61850-90-12 Communication Requirements; Courtesy of IEC Table 8: 61850-90-12 Communication Requirements; Courtesy of IEC
3.2.2.2. Distribution use case 3.1.2. Generation Use Case
3.2.2.2.1. Fault Location Isolation and Service Restoration (FLISR)
As the name implies, Fault Location, Isolation, and Service
Restoration (FLISR) refers to the ability to automatically locate the
fault, isolate the fault, and restore service in the distribution
network. It is a self-healing feature whose purpose is to minimize
the impact of faults by serving portions of the loads on the affected
circuit by switching to other circuits. It reduces the number of
customers that experience a sustained power outage by reconfiguring
distribution circuits. This will likely be the first wide spread
application of distributed intelligence in the grid. Secondary
substations can be connected to multiple primary substations.
Normally, static power switch statuses (open/closed) in the network
dictate the power flow to secondary substations. Reconfiguring the
network in the event of a fault is typically done manually on site to
operate switchgear to energize/de-energize alternate paths.
Automating the operation of substation switchgear allows the utility
to have a more dynamic network where the flow of power can be altered
under fault conditions but also during times of peak load. It allows
the utility to shift peak loads around the network. Or, to be more
precise, alters the configuration of the network to move loads
between different primary substations. The FLISR capability can be
enabled in two modes:
o Managed centrally from DMS (Distribution Management System), or
o Executed locally through distributed control via intelligent
switches and fault sensors.
There are 3 distinct sub-functions that are performed:
1. Fault Location Identification
This sub-function is initiated by SCADA inputs, such as lockouts,
fault indications/location, and, also, by input from the Outage
Management System (OMS), and in the future by inputs from fault-
predicting devices. It determines the specific protective device,
which has cleared the sustained fault, identifies the de-energized
sections, and estimates the probable location of the actual or the
expected fault. It distinguishes faults cleared by controllable
protective devices from those cleared by fuses, and identifies
momentary outages and inrush/cold load pick-up currents. This step
is also referred to as Fault Detection Classification and Location
(FDCL). This step helps to expedite the restoration of faulted
sections through fast fault location identification and improved
diagnostic information available for crew dispatch. Also provides
visualization of fault information to design and implement a
switching plan to isolate the fault.
2. Fault Type Determination
I. Indicates faults cleared by controllable protective devices by
distinguishing between:
a. Faults cleared by fuses
b. Momentary outages The electrical power generation frequency should be maintained within
a very narrow band. Deviations from the acceptable frequency range
are detected and the required signals are sent to the power plants
for frequency regulation.
c. Inrush/cold load current Automatic generation control (AGC) is a system for adjusting the
power output of generators at different power plants, in response to
changes in the load.
II. Determines the faulted sections based on SCADA fault indications +---------------------------------------------------+---------------+
and protection lockout signals | FCAG (Frequency Control Automatic Generation) | Attribute |
| Requirement | |
+---------------------------------------------------+---------------+
| One way maximum delay | 500 ms |
| Asymetric delay Required | No |
| Maximum jitter | Not critical |
| Topology | Point to |
| | point |
| Bandwidth | 20 Kbps |
| Availability | 99.999 |
| precise timing required | Yes |
| Recovery time on Node failure | N/A |
| performance management | Yes, |
| | Mandatory |
| Redundancy | Yes |
| Packet loss | 1% |
+---------------------------------------------------+---------------+
III. Increases the accuracy of the fault location estimation based Table 9: FCAG Communication Requirements
on SCADA fault current measurements and real-time fault analysis
3. Fault Isolation and Service Restoration 3.1.3. Distribution use case
Once the location and type of the fault has been pinpointed, the
systems will attempt to isolate the fault and restore the non-faulted
section of the network. This can have three modes of operation:
I. Closed-loop mode : This is initiated by the Fault location sub- 3.1.3.1. Fault Location Isolation and Service Restoration (FLISR)
function. It generates a switching order (i.e., sequence of
switching) for the remotely controlled switching devices to isolate
the faulted section, and restore service to the non-faulted sections.
The switching order is automatically executed via SCADA.
II. Advisory mode : This is initiated by the Fault location sub- Fault Location, Isolation, and Service Restoration (FLISR) refers to
function. It generates a switching order for remotely and manually the ability to automatically locate the fault, isolate the fault, and
controlled switching devices to isolate the faulted section, and restore service in the distribution network. This will likely be the
restore service to the non-faulted sections. The switching order is first widespread application of distributed intelligence in the grid.
presented to operator for approval and execution.
III. Study mode : the operator initiates this function. It analyzes Static power switch status (open/closed) in the network dictates the
a saved case modified by the operator, and generates a switching power flow to secondary substations. Reconfiguring the network in
order under the operating conditions specified by the operator. the event of a fault is typically done manually on site to energize/
de-energize alternate paths. Automating the operation of substation
switchgear allows the flow of power to be altered automatically under
fault conditions.
With the increasing volume of data that are collected through fault FLISR can be managed centrally from a Distribution Management System
sensors, utilities will use Big Data query and analysis tools to (DMS) or executed locally through distributed control via intelligent
study outage information to anticipate and prevent outages by switches and fault sensors.
detecting failure patterns and their correlation with asset age,
type, load profiles, time of day, weather conditions, and other
conditions to discover conditions that lead to faults and take the
necessary preventive and corrective measures.
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| FLISR Requirement | Attribute | | FLISR Requirement | Attribute |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| One way maximum | 80 ms | | One way maximum | 80 ms |
| delay | | | delay | |
| Asymetric delay | No | | Asymetric delay | No |
| Required | | | Required | |
| Maximum jitter | 40 ms | | Maximum jitter | 40 ms |
| Topology | Point to point, point to Multi-point, | | Topology | Point to point, point to Multi-point, |
skipping to change at page 29, line 27 skipping to change at page 24, line 27
| precise timing | Yes | | precise timing | Yes |
| required | | | required | |
| Recovery time on | Depends on customer impact | | Recovery time on | Depends on customer impact |
| Node failure | | | Node failure | |
| performance | Yes, Mandatory | | performance | Yes, Mandatory |
| management | | | management | |
| Redundancy | Yes | | Redundancy | Yes |
| Packet loss | 0.1% | | Packet loss | 0.1% |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 9: FLISR Communication Requirements Table 10: FLISR Communication Requirements
3.2.2.3. Generation use case 3.2. Electrical Utilities Today
3.2.2.3.1. Frequency Control / Automatic Generation Control (AGC) Many utilities still rely on complex environments formed of multiple
application-specific proprietary networks, including TDM networks.
The system frequency should be maintained within a very narrow band. In this kind of environment there is no mixing of OT and IT
Deviations from the acceptable frequency range are detected and applications on the same network, and information is siloed between
forwarded to the Load Frequency Control (LFC) system so that required operational areas.
up or down generation increase / decrease pulses can be sent to the
power plants for frequency regulation. The trend in system frequency
is a measure of mismatch between demand and generation, and is a
necessary parameter for load control in interconnected systems.
Automatic generation control (AGC) is a system for adjusting the Specific calibration of the full chain is required, which is costly.
power output of generators at different power plants, in response to
changes in the load. Since a power grid requires that generation and
load closely balance moment by moment, frequent adjustments to the
output of generators are necessary. The balance can be judged by
measuring the system frequency; if it is increasing, more power is
being generated than used, and all machines in the system are
accelerating. If the system frequency is decreasing, more demand is
on the system than the instantaneous generation can provide, and all
generators are slowing down.
Where the grid has tie lines to adjacent control areas, automatic This kind of environment prevents utility operations from realizing
generation control helps maintain the power interchanges over the tie the operational efficiency benefits, visibility, and functional
lines at the scheduled levels. The AGC takes into account various integration of operational information across grid applications and
parameters including the most economical units to adjust, the data networks.
coordination of thermal, hydroelectric, and other generation types,
and even constraints related to the stability of the system and
capacity of interconnections to other power grids.
For the purpose of AGC we use static frequency measurements and In addition, there are many security-related issues as discussed in
averaging methods are used to get a more precise measure of system the following section.
frequency in steady-state conditions.
During disturbances, more real-time dynamic measurements of system 3.2.1. Security Current Practices and Limitations
frequency are taken using PMUs, especially when different areas of
the system exhibit different frequencies. But that is outside the
scope of this use case.
+---------------------------------------------------+---------------+ Grid monitoring and control devices are already targets for cyber
| FCAG (Frequency Control Automatic Generation) | Attribute | attacks, and legacy telecommunications protocols have many intrinsic
| Requirement | | network-related vulnerabilities. For example, DNP3, Modbus,
+---------------------------------------------------+---------------+ PROFIBUS/PROFINET, and other protocols are designed around a common
| One way maximum delay | 500 ms | paradigm of request and respond. Each protocol is designed for a
| Asymetric delay Required | No | master device such as an HMI (Human Machine Interface) system to send
| Maximum jitter | Not critical | commands to subordinate slave devices to retrieve data (reading
| Topology | Point to | inputs) or control (writing to outputs). Because many of these
| | point | protocols lack authentication, encryption, or other basic security
| Bandwidth | 20 Kbps | measures, they are prone to network-based attacks, allowing a
| Availability | 99.999 | malicious actor or attacker to utilize the request-and-respond system
| precise timing required | Yes | as a mechanism for command-and-control like functionality. Specific
| Recovery time on Node failure | N/A | security concerns common to most industrial control, including
| performance management | Yes, | utility telecommunication protocols include the following:
| | Mandatory |
| Redundancy | Yes |
| Packet loss | 1% |
+---------------------------------------------------+---------------+
Table 10: FCAG Communication Requirements o Network or transport errors (e.g. malformed packets or excessive
latency) can cause protocol failure.
3.2.3. Specific Network topologies of Smart Grid Applications o Protocol commands may be available that are capable of forcing
slave devices into inoperable states, including powering-off
devices, forcing them into a listen-only state, disabling
alarming.
o Protocol commands may be available that are capable of restarting
communications and otherwise interrupting processes.
o Protocol commands may be available that are capable of clearing,
erasing, or resetting diagnostic information such as counters and
diagnostic registers.
o Protocol commands may be available that are capable of requesting
sensitive information about the controllers, their configurations,
or other need-to-know information.
o Most protocols are application layer protocols transported over
TCP; therefore it is easy to transport commands over non-standard
ports or inject commands into authorized traffic flows.
o Protocol commands may be available that are capable of
broadcasting messages to many devices at once (i.e. a potential
DoS).
o Protocol commands may be available to query the device network to
obtain defined points and their values (i.e. a configuration
scan).
o Protocol commands may be available that will list all available
function codes (i.e. a function scan).
These inherent vulnerabilities, along with increasing connectivity
between IT an OT networks, make network-based attacks very feasible.
Simple injection of malicious protocol commands provides control over
the target process. Altering legitimate protocol traffic can also
alter information about a process and disrupt the legitimate controls
that are in place over that process. A man-in-the-middle attack
could provide both control over a process and misrepresentation of
data back to operator consoles.
3.3. Electrical Utilities Future
The business and technology trends that are sweeping the utility
industry will drastically transform the utility business from the way
it has been for many decades. At the core of many of these changes
is a drive to modernize the electrical grid with an integrated
telecommunications infrastructure. However, interoperability
concerns, legacy networks, disparate tools, and stringent security
requirements all add complexity to the grid transformation. Given
the range and diversity of the requirements that should be addressed
by the next generation telecommunications infrastructure, utilities
need to adopt a holistic architectural approach to integrate the
electrical grid with digital telecommunications across the entire
power delivery chain.
The key to modernizing grid telecommunications is to provide a
common, adaptable, multi-service network infrastructure for the
entire utility organization. Such a network serves as the platform
for current capabilities while enabling future expansion of the
network to accommodate new applications and services.
To meet this diverse set of requirements, both today and in the
future, the next generation utility telecommunnications network will
be based on open-standards-based IP architecture. An end-to-end IP
architecture takes advantage of nearly three decades of IP technology
development, facilitating interoperability across disparate networks
and devices, as it has been already demonstrated in many mission-
critical and highly secure networks.
IPv6 is seen as a future telecommunications technology for the Smart
Grid; the IEC (International Electrotechnical Commission) and
different National Committees have mandated a specific adhoc group
(AHG8) to define the migration strategy to IPv6 for all the IEC TC57
power automation standards.
3.3.1. Migration to Packet-Switched Network
Throughout the world, utilities are increasingly planning for a
future based on smart grid applications requiring advanced
telecommunications systems. Many of these applications utilize
packet connectivity for communicating information and control signals
across the utility's Wide Area Network (WAN), made possible by
technologies such as multiprotocol label switching (MPLS). The data
that traverses the utility WAN includes:
o Grid monitoring, control, and protection data
o Non-control grid data (e.g. asset data for condition-based
monitoring)
o Physical safety and security data (e.g. voice and video)
o Remote worker access to corporate applications (voice, maps,
schematics, etc.)
o Field area network backhaul for smart metering, and distribution
grid management
o Enterprise traffic (email, collaboration tools, business
applications)
WANs support this wide variety of traffic to and from substations,
the transmission and distribution grid, generation sites, between
control centers, and between work locations and data centers. To
maintain this rapidly expanding set of applications, many utilities
are taking steps to evolve present time-division multiplexing (TDM)
based and frame relay infrastructures to packet systems. Packet-
based networks are designed to provide greater functionalities and
higher levels of service for applications, while continuing to
deliver reliability and deterministic (real-time) traffic support.
3.3.2. Telecommunications Trends
These general telecommunications topics are in addition to the use
cases that have been addressed so far. These include both current
and future telecommunications related topics that should be factored
into the network architecture and design.
3.3.2.1. General Telecommunications Requirements
o IP Connectivity everywhere
o Monitoring services everywhere and from different remote centers
o Move services to a virtual data center
o Unify access to applications / information from the corporate
network
o Unify services
o Unified Communications Solutions
o Mix of fiber and microwave technologies - obsolescence of SONET/
SDH or TDM
o Standardize grid telecommunications protocol to opened standard to
ensure interoperability
o Reliable Telecommunications for Transmission and Distribution
Substations
o IEEE 1588 time synchronization Client / Server Capabilities
o Integration of Multicast Design
o QoS Requirements Mapping
o Enable Future Network Expansion
o Substation Network Resilience
o Fast Convergence Design
o Scalable Headend Design
o Define Service Level Agreements (SLA) and Enable SLA Monitoring
o Integration of 3G/4G Technologies and future technologies
o Ethernet Connectivity for Station Bus Architecture
o Ethernet Connectivity for Process Bus Architecture
o Protection, teleprotection and PMU (Phaser Measurement Unit) on IP
3.3.2.2. Specific Network topologies of Smart Grid Applications
Utilities often have very large private telecommunications networks. Utilities often have very large private telecommunications networks.
It covers an entire territory / country. The main purpose of the It covers an entire territory / country. The main purpose of the
network, until now, has been to support transmission network network, until now, has been to support transmission network
monitoring, control, and automation, remote control of generation monitoring, control, and automation, remote control of generation
sites, and providing FCAPS (Fault. Configuration. Accounting. sites, and providing FCAPS (Fault, Configuration, Accounting,
Performance. Security) services from centralized network operation Performance, Security) services from centralized network operation
centers. centers.
Going forward, one network will support operation and maintenance of Going forward, one network will support operation and maintenance of
electrical networks (generation, transmission, and distribution), electrical networks (generation, transmission, and distribution),
voice and data services for ten of thousands of employees and for voice and data services for ten of thousands of employees and for
exchange with neighboring interconnections, and administrative exchange with neighboring interconnections, and administrative
services. To meet those requirements, utility may deploy several services. To meet those requirements, utility may deploy several
physical networks leveraging different technologies across the physical networks leveraging different technologies across the
country: an optical network and a microwave network for instance. country: an optical network and a microwave network for instance.
Each protection and automatism system between two points has two Each protection and automatism system between two points has two
telecommunications circuits, one on each network. Path diversity telecommunications circuits, one on each network. Path diversity
between two substations is key. Regardless of the event type between two substations is key. Regardless of the event type
(hurricane, ice storm, etc.), one path shall stay available so the (hurricane, ice storm, etc.), one path shall stay available so the
SPS can still operate. system can still operate.
In the optical network, signals are transmitted over more than tens In the optical network, signals are transmitted over more than tens
of thousands of circuits using fiber optic links, microwave and of thousands of circuits using fiber optic links, microwave and
telephone cables. This network is the nervous system of the telephone cables. This network is the nervous system of the
utility's power transmission operations. The optical network utility's power transmission operations. The optical network
represents ten of thousands of km of cable deployed along the power represents ten of thousands of km of cable deployed along the power
lines. lines, with individual runs as long as 280 km.
Due to vast distances between transmission substations (for example
as far as 280km apart), the fiber signal can be amplified to reach a
distance of 280 km without attenuation.
3.2.4. Precision Time Protocol 3.3.2.3. Precision Time Protocol
Some utilities do not use GPS clocks in generation substations. One Some utilities do not use GPS clocks in generation substations. One
of the main reasons is that some of the generation plants are 30 to of the main reasons is that some of the generation plants are 30 to
50 meters deep under ground and the GPS signal can be weak and 50 meters deep under ground and the GPS signal can be weak and
unreliable. Instead, atomic clocks are used. Clocks are unreliable. Instead, atomic clocks are used. Clocks are
synchronized amongst each other. Rubidium clocks provide clock and synchronized amongst each other. Rubidium clocks provide clock and
1ms timestamps for IRIG-B. Some companies plan to transition to the 1ms timestamps for IRIG-B.
Precision Time Protocol (IEEE 1588), distributing the synchronization
signal over the IP/MPLS network.
The Precision Time Protocol (PTP) is defined in IEEE standard 1588. Some companies plan to transition to the Precision Time Protocol
PTP is applicable to distributed systems consisting of one or more (PTP, [IEEE1588]), distributing the synchronization signal over the
nodes, communicating over a network. Nodes are modeled as containing IP/MPLS network. PTP provides a mechanism for synchronizing the
a real-time clock that may be used by applications within the node clocks of participating nodes to a high degree of accuracy and
for various purposes such as generating time-stamps for data or precision.
ordering events managed by the node. The protocol provides a
mechanism for synchronizing the clocks of participating nodes to a
high degree of accuracy and precision.
PTP operates based on the following assumptions : PTP operates based on the following assumptions:
It is assumed that the network eliminates cyclic forwarding of PTP It is assumed that the network eliminates cyclic forwarding of PTP
messages within each communication path (e.g., by using a spanning messages within each communication path (e.g. by using a spanning
tree protocol). PTP eliminates cyclic forwarding of PTP messages tree protocol).
between communication paths.
PTP is tolerant of an occasional missed message, duplicated PTP is tolerant of an occasional missed message, duplicated
message, or message that arrived out of order. However, PTP message, or message that arrived out of order. However, PTP
assumes that such impairments are relatively rare. assumes that such impairments are relatively rare.
PTP was designed assuming a multicast communication model. PTP PTP was designed assuming a multicast communication model, however
also supports a unicast communication model as long as the PTP also supports a unicast communication model as long as the
behavior of the protocol is preserved. behavior of the protocol is preserved.
Like all message-based time transfer protocols, PTP time accuracy Like all message-based time transfer protocols, PTP time accuracy
is degraded by asymmetry in the paths taken by event messages. is degraded by delay asymmetry in the paths taken by event
Asymmetry is not detectable by PTP, however, if known, PTP messages. Asymmetry is not detectable by PTP, however, if such
corrects for asymmetry. delays are known a priori, PTP can correct for asymmetry.
A time-stamp event is generated at the time of transmission and
reception of any event message. The time-stamp event occurs when the
message's timestamp point crosses the boundary between the node and
the network.
IEC 61850 will recommend the use of the IEEE PTP 1588 Utility Profile IEC 61850 will recommend the use of the IEEE PTP 1588 Utility Profile
(as defined in IEC 62439-3 Annex B) which offers the support of (as defined in [IEC62439-3:2012] Annex B) which offers the support of
redundant attachment of clocks to Paralell Redundancy Protcol (PRP) redundant attachment of clocks to Parallel Redundancy Protcol (PRP)
and High-availability Seamless Redundancy (HSR) networks. and High-availability Seamless Redundancy (HSR) networks.
3.3. IANA Considerations 3.3.3. Security Trends in Utility Networks
This memo includes no request to IANA.
3.4. Security Considerations
3.4.1. Current Practices and Their Limitations
Grid monitoring and control devices are already targets for cyber
attacks and legacy telecommunications protocols have many intrinsic
network related vulnerabilities. DNP3, Modbus, PROFIBUS/PROFINET,
and other protocols are designed around a common paradigm of request
and respond. Each protocol is designed for a master device such as
an HMI (Human Machine Interface) system to send commands to
subordinate slave devices to retrieve data (reading inputs) or
control (writing to outputs). Because many of these protocols lack
authentication, encryption, or other basic security measures, they
are prone to network-based attacks, allowing a malicious actor or
attacker to utilize the request-and-respond system as a mechanism for
command-and-control like functionality. Specific security concerns
common to most industrial control, including utility
telecommunication protocols include the following:
o Network or transport errors (e.g. malformed packets or excessive
latency) can cause protocol failure.
o Protocol commands may be available that are capable of forcing
slave devices into inoperable states, including powering-off
devices, forcing them into a listen-only state, disabling
alarming.
o Protocol commands may be available that are capable of restarting
communications and otherwise interrupting processes.
o Protocol commands may be available that are capable of clearing,
erasing, or resetting diagnostic information such as counters and
diagnostic registers.
o Protocol commands may be available that are capable of requesting
sensitive information about the controllers, their configurations,
or other need-to-know information.
o Most protocols are application layer protocols transported over
TCP; therefore it is easy to transport commands over non-standard
ports or inject commands into authorized traffic flows.
o Protocol commands may be available that are capable of
broadcasting messages to many devices at once (i.e. a potential
DoS).
o Protocol commands may be available to query the device network to
obtain defined points and their values (i.e. a configuration
scan).
o Protocol commands may be available that will list all available
function codes (i.e. a function scan).
o Bump in the wire (BITW) solutions : A hardware device is added to
provide IPSec services between two routers that are not capable of
IPSec functions. This special IPsec device will intercept then
intercept outgoing datagrams, add IPSec protection to them, and
strip it off incoming datagrams. BITW can all IPSec to legacy
hosts and can retrofit non-IPSec routers to provide security
benefits. The disadvantages are complexity and cost.
These inherent vulnerabilities, along with increasing connectivity
between IT an OT networks, make network-based attacks very feasible.
Simple injection of malicious protocol commands provides control over
the target process. Altering legitimate protocol traffic can also
alter information about a process and disrupt the legitimate controls
that are in place over that process. A man- in-the-middle attack
could provide both control over a process and misrepresentation of
data back to operator consoles.
3.4.2. Security Trends in Utility Networks
Although advanced telecommunications networks can assist in Although advanced telecommunications networks can assist in
transforming the energy industry, playing a critical role in transforming the energy industry by playing a critical role in
maintaining high levels of reliability, performance, and maintaining high levels of reliability, performance, and
manageability, they also introduce the need for an integrated manageability, they also introduce the need for an integrated
security infrastructure. Many of the technologies being deployed to security infrastructure. Many of the technologies being deployed to
support smart grid projects such as smart meters and sensors can support smart grid projects such as smart meters and sensors can
increase the vulnerability of the grid to attack. Top security increase the vulnerability of the grid to attack. Top security
concerns for utilities migrating to an intelligent smart grid concerns for utilities migrating to an intelligent smart grid
telecommunications platform center on the following trends: telecommunications platform center on the following trends:
o Integration of distributed energy resources o Integration of distributed energy resources
skipping to change at page 34, line 39 skipping to change at page 30, line 47
smart metering smart metering
o Demand for new levels of customer service and energy management o Demand for new levels of customer service and energy management
This development of a diverse set of networks to support the This development of a diverse set of networks to support the
integration of microgrids, open-access energy competition, and the integration of microgrids, open-access energy competition, and the
use of network-controlled devices is driving the need for a converged use of network-controlled devices is driving the need for a converged
security infrastructure for all participants in the smart grid, security infrastructure for all participants in the smart grid,
including utilities, energy service providers, large commercial and including utilities, energy service providers, large commercial and
industrial, as well as residential customers. Securing the assets of industrial, as well as residential customers. Securing the assets of
electric power delivery systems, from the control center to the electric power delivery systems (from the control center to the
substation, to the feeders and down to customer meters, requires an substation, to the feeders and down to customer meters) requires an
end-to-end security infrastructure that protects the myriad of end-to-end security infrastructure that protects the myriad of
telecommunications assets used to operate, monitor, and control power telecommunications assets used to operate, monitor, and control power
flow and measurement. Cyber security refers to all the security flow and measurement.
issues in automation and telecommunications that affect any functions
related to the operation of the electric power systems. "Cyber security" refers to all the security issues in automation and
Specifically, it involves the concepts of: telecommunications that affect any functions related to the operation
of the electric power systems. Specifically, it involves the
concepts of:
o Integrity : data cannot be altered undetectably o Integrity : data cannot be altered undetectably
o Authenticity : the telecommunications parties involved must be o Authenticity : the telecommunications parties involved must be
validated as genuine validated as genuine
o Authorization : only requests and commands from the authorized o Authorization : only requests and commands from the authorized
users can be accepted by the system users can be accepted by the system
o Confidentiality : data must not be accessible to any o Confidentiality : data must not be accessible to any
unauthenticated users unauthenticated users
When designing and deploying new smart grid devices and When designing and deploying new smart grid devices and
telecommunications systems, it's imperative to understand the various telecommunications systems, it is imperative to understand the
impacts of these new components under a variety of attack situations various impacts of these new components under a variety of attack
on the power grid. Consequences of a cyber attack on the grid situations on the power grid. Consequences of a cyber attack on the
telecommunications network can be catastrophic. This is why security grid telecommunications network can be catastrophic. This is why
for smart grid is not just an ad hoc feature or product, it's a security for smart grid is not just an ad hoc feature or product,
complete framework integrating both physical and Cyber security it's a complete framework integrating both physical and Cyber
requirements and covering the entire smart grid networks from security requirements and covering the entire smart grid networks
generation to distribution. Security has therefore become one of the from generation to distribution. Security has therefore become one
main foundations of the utility telecom network architecture and must of the main foundations of the utility telecom network architecture
be considered at every layer with a defense-in-depth approach. and must be considered at every layer with a defense-in-depth
Migrating to IP based protocols is key to address these challenges approach. Migrating to IP based protocols is key to address these
for two reasons: challenges for two reasons:
1. IP enables a rich set of features and capabilities to enhance the o IP enables a rich set of features and capabilities to enhance the
security posture security posture
2. IP is based on open standards, which allows interoperability o IP is based on open standards, which allows interoperability
between different vendors and products, driving down the costs between different vendors and products, driving down the costs
associated with implementing security solutions in OT networks. associated with implementing security solutions in OT networks.
Securing OT (Operation technology) telecommunications over packet- Securing OT (Operation technology) telecommunications over packet-
switched IP networks follow the same principles that are foundational switched IP networks follow the same principles that are foundational
for securing the IT infrastructure, i.e., consideration must be given for securing the IT infrastructure, i.e., consideration must be given
to enforcing electronic access control for both person-to-machine and to enforcing electronic access control for both person-to-machine and
machine-to-machine communications, and providing the appropriate machine-to-machine communications, and providing the appropriate
levels of data privacy, device and platform integrity, and threat levels of data privacy, device and platform integrity, and threat
detection and mitigation. detection and mitigation.
3.4. Electrical Utilities Asks
o Mixed L2 and L3 topologies
o Deterministic behavior
o Bounded latency and jitter
o High availability, low recovery time
o Redundancy, low packet loss
o Precise timing
o Centralized computing of deterministic paths
o Distributed configuration may also be useful
4. Building Automation Systems 4. Building Automation Systems
4.1. Use Case Description 4.1. Use Case Description
A Building Automation System (BAS) manages equipment and sensors in a A Building Automation System (BAS) manages equipment and sensors in a
building for improving residents' comfort, reducing energy building for improving residents' comfort, reducing energy
consumption, and responding to failures and emergencies. For consumption, and responding to failures and emergencies. For
example, the BAS measures the temperature of a room using sensors and example, the BAS measures the temperature of a room using sensors and
then controls the HVAC (heating, ventilating, and air conditioning) then controls the HVAC (heating, ventilating, and air conditioning)
to maintain a set temperature and minimize energy consumption. to maintain a set temperature and minimize energy consumption.
skipping to change at page 60, line 44 skipping to change at page 57, line 44
created rather infrequently, on the order of ~10 times per day / week created rather infrequently, on the order of ~10 times per day / week
/ month. Most of these critical control/data streams get created at / month. Most of these critical control/data streams get created at
machine startup, however flexibility is also needed during runtime, machine startup, however flexibility is also needed during runtime,
for example when adding or removing a machine. Going forward as for example when adding or removing a machine. Going forward as
production systems become more flexible, we expect a significant production systems become more flexible, we expect a significant
increase in the rate at which streams are created, changed and increase in the rate at which streams are created, changed and
destroyed. destroyed.
8.3. Industrial M2M Future 8.3. Industrial M2M Future
We would like to see the various proprietary networks replaced with a We would like to see a converged IP-standards-based network with
converged IP-standards-based network with deterministic properties deterministic properties that can satisfy the timing, security and
that can satisfy the timing, security and reliability constraints reliability constraints described above. Today's proprietary
described above. networks could then be interfaced to such a network via gateways or,
in the case of new installations, devices could be connected directly
to the converged network.
8.4. Industrial M2M Asks 8.4. Industrial M2M Asks
o Converged IP-based network o Converged IP-based network
o Deterministic behavior (bounded latency and jitter ) o Deterministic behavior (bounded latency and jitter )
o High availability (presumably through redundancy) (99.999 %) o High availability (presumably through redundancy) (99.999 %)
o Low message delivery time (100us - 50ms) o Low message delivery time (100us - 50ms)
skipping to change at page 66, line 18 skipping to change at page 63, line 18
<http://www.ieee1904.org/3/meeting_archive/2015/02/ <http://www.ieee1904.org/3/meeting_archive/2015/02/
tf3_1502_che n_1a.pdf>. tf3_1502_che n_1a.pdf>.
[HART] www.hartcomm.org, "Highway Addressable remote Transducer, [HART] www.hartcomm.org, "Highway Addressable remote Transducer,
a group of specifications for industrial process and a group of specifications for industrial process and
control devices administered by the HART Foundation". control devices administered by the HART Foundation".
[I-D.finn-detnet-architecture] [I-D.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic Finn, N., Thubert, P., and M. Teener, "Deterministic
Networking Architecture", draft-finn-detnet- Networking Architecture", draft-finn-detnet-
architecture-02 (work in progress), November 2015. architecture-03 (work in progress), March 2016.
[I-D.finn-detnet-problem-statement] [I-D.finn-detnet-problem-statement]
Finn, N. and P. Thubert, "Deterministic Networking Problem Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", draft-finn-detnet-problem-statement-04 (work Statement", draft-finn-detnet-problem-statement-04 (work
in progress), October 2015. in progress), October 2015.
[I-D.ietf-6tisch-6top-interface] [I-D.ietf-6tisch-6top-interface]
Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer
(6top) Interface", draft-ietf-6tisch-6top-interface-04 (6top) Interface", draft-ietf-6tisch-6top-interface-04
(work in progress), July 2015. (work in progress), July 2015.
 End of changes. 85 change blocks. 
668 lines changed or deleted 521 lines changed or added

This html diff was produced by rfcdiff 1.43. The latest version is available from http://tools.ietf.org/tools/rfcdiff/