Internet DRAFT - draft-saldana-tsvwg-simplemux-blast
draft-saldana-tsvwg-simplemux-blast
TSVWG J. Saldana
Internet-Draft CIRCE Technology Center
Intended status: Standards Track 3 January 2024
Expires: 6 July 2024
Simplemux Blast flavor
draft-saldana-tsvwg-simplemux-blast-00
Abstract
Many utilities are nowadays connected via dedicated networks, but the
trend toward a fully IP network is gaining more traction in some
sectors (e.g. electric power). In some use cases, although it would
be desirable to avoid the use of IP networks, this may prove
unavoidable. Consequently, equipment is linked to extensive
communication networks, the performance of which cannot be fully
controlled or known.
Some utilities that are not connected to a dedicated network may use
public wireless networks, which present certain degree of variability
of some parameters (delay, jitter, packet loss, and bandwidth
limits). Considering the importance of receiving packets with a low
delay, this document presents a solution for using tunnels to send
frames or packets between remote facilities, with a certain degree of
redundance. This can be useful in some use cases as e.g. the sending
of event-driven field commands between eletric substations. In some
cases, these messages can be very critical, and their loss or delay
can make the difference between a blackout and a simple outage.
Considering the high redundancy of the protocol, its use must be
restricted to traffic flows which require very low delay to control
critical equipment.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-saldana-tsvwg-simplemux-
blast/.
Discussion of this document takes place on the Transport Area Working
Group (tsvwg) Working Group mailing list (mailto:tsvwg@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/tsvwg/.
Subscribe at https://www.ietf.org/mailman/listinfo/tsvwg/.
Saldana Expires 6 July 2024 [Page 1]
Internet-Draft Simplemux January 2024
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description of the protocol . . . . . . . . . . . . . . . . . 4
3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Definition of the protocol fields . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
Saldana Expires 6 July 2024 [Page 2]
Internet-Draft Simplemux January 2024
1. Introduction
Many utilities are nowadays connected via dedicated networks, but the
trend toward a fully IP network is gaining more traction in some
sectors (e.g. electric power). In some use cases, although it would
be desirable to avoid the use of public IP networks, this may prove
unavoidable. Consequently, equipment is linked to extensive
communication networks, the performance of which cannot be fully
controlled or known.
For example, some use cases defined in IEC 61850-90-5
[IEC_61850-90-5] (IEC stands for International Electrotechnical
Commission), state that IP networks can be used to communicate with
receivers outside a substation if the added delays are acceptable for
the application. The sending of Ethernet frames over other
technologies is defined in IEC/TR 61850-90-1 ([IEC_61850-90-1]).
Some utilities that are not connected to a dedicated network may use
public wireless networks, which present certain degree of variability
of some parameters (delay, jitter, packet loss, and bandwidth
limits). Considering the importance of receiving packets with a low
delay, this document presents a solution for using tunnels to send
frames or packets between remote facilities, with a certain degree of
redundance. This can be useful in some use cases as e.g. the sending
of event-driven field commands between eletric substations. In some
cases, these messages can be very critical, and their loss or delay
can make the difference between a blackout and a simple outage.
The solution is called Simplemux blast flavor, and its headers are
defined as a new flavor of [I-D.saldana-tsvwg-simplemux]. It is
based on sending redundant frames. It periodically sends the same
packet a number of times to grant the delivery of every single frame.
It minimizes the delay caused by packet loss, thus keeping actuation
times within acceptable limits.
Its protocol stack is presented in Figure 1
+--------------------------------+
| Tunneled packet/frame | Tunneled protocol
+--------------------------------+
| Simplemux header/separator | Multiplexing protocol
+--------------------------------+
| Tunneling header | Tunneling protocol
+--------------------------------+
Figure 1
Saldana Expires 6 July 2024 [Page 3]
Internet-Draft Simplemux January 2024
In contrast to the other Simplemux flavors, only a multiplexed
packet/frame is included inside each tunneling packet. In addition,
application-level ACKs (Acknowledgements) and heartbeats are used.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Description of the protocol
The elements of the system are presented in Figure 2. A period is
defined: each frame sent by the source is stored in the sender router
and sent periodically via the tunnel. An identifier (i.e. an
increasing field) is included on each tunneled packet. This
identifier is the same for each packet sent by the source, which
means that the packets that are sent periodically are exactly the
same.
The destination router decapsulates the received frame, forwards it
to the destination node and sends an ACK to the sender router. The
periodical sending of a frame is interrupted as soon as the first ACK
arrives.
+------+ +------+ public IP +------+ +-----------+
|source| |sender| network |destin| |destination|
| | |router| |router| | |
+------+ +------+ +------+ +-----------+
| | | |
|--frame/->| | |
| packet | | |
| | | |
| |--- tunneled --->| |
| | frame/packet | |
| | | |
| | |--frame/->|
| | | packet |
| |<------- ACK ------| |
| | | |
| |<--- heartbeat ----| |
| | | |
| |---- heartbeat --->| |
Figure 2
Saldana Expires 6 July 2024 [Page 4]
Internet-Draft Simplemux January 2024
The fact of periodically sending the same frame increases the
throughput, but it guarantees that every single frame will arrive on
the other side. As the mechanism works between a pair of
intermediate machines, it is totally transparent for the end nodes,
which only receive a single copy of the original frame. This is
quite different from TCP: the proposed method does not wait for the
ACK; it periodically sends a copy of the same frame to the other
side.
In networks with high RTT, this can significantly reduce the incurred
delay: instead of waiting for the whole RTT, a copy of any lost frame
will soon be available.
A new Simplemux (see [I-D.saldana-tsvwg-simplemux]) flavor named
"blast" has been defined. It includes an identifier field and
another field that specifies whether the packet is an ACK or not.
The redundancy can potentially lead to traffic congestion if not
managed appropriately. Besides maintaining the period at an optimal
value, another strategy to keep redundancy at acceptable levels
involves transmitting only the most critical flows via Simplemux
blast, while the rest are sent without confirmation. VLAN tags or
other methods can be effectively utilized to categorize the packets.
The value of the period will therefore be limited by the redundancy
allowed by the available bandwidth.
Some tests exploring the trade-off between the redundancy and the
resulting delay of Simplemux blast flavor, in the electrical domain,
were published in [Saldana].
Some examples are next presented to describe the protocol.
3.1. Example 1
As shown in Figure 3, a period is defined: each frame sent by the
source is stored in the sender router and sent periodically via the
tunnel until the first ACK arrives. The destination router
decapsulates the received frame, forwards it to the destination node
and sends an ACK to the sender router.
In the example, frame 1 is sent three times by the source router. It
is sent periodically until the first ACK arrives. This means that,
in this case, the RTT is between 2 and 3 times the sending period.
Saldana Expires 6 July 2024 [Page 5]
Internet-Draft Simplemux January 2024
When the second copy of frame 1 arrives to the destination router, it
is dropped because it has already been delivered to the destination.
A new ACK is sent. Considering that ACKs can also be lost in the
public IP network, every packet arrived to the destination router
MUST be acknowledged.
+------+ +------+ public IP +------+ +-----------+
|source| |sender| network |destin| |destination|
| | |router| |router| | |
+------+ +------+ +------+ +-----------+
| | | |
|----1---->|--1--> | |
| ^ | --> | |
| | | --> | |
| period | --> | |
| | | --> | |
| V |--1--> --> | |
| ^ | --> --->|----1---->| 1 arrived
| | | --> <-ACK1-|send ACK1 | ^
| period | <-> | | |
| | | <-- --> | | period
| V |--1--><- --> | | |
| | <- -> --->|drop 1,2 | V
| ACK1|<--- --> <-ACK1-|send ACK1 |
| | -><-- | |
| | <- -> | |
...
Note: "--1--> " represents the tunneled version of packet/frame 1.
"<-ACK1-" represents an ACK corresponding to packet/frame 1.
Figure 3
3.2. Example 2
In the example presented in Figure 4, the first copy of the packet 1
is lost in the network. Considering that a second copy has been sent
after a period, the new copy arrives at the destination. If the
period is smaller than the RTT, some delay will be avoided, at the
cost of a level of redundancy.
Saldana Expires 6 July 2024 [Page 6]
Internet-Draft Simplemux January 2024
+------+ +------+ public IP +------+ +-----------+
|source| |sender| network |destin| |destination|
| | |router| |router| | |
+------+ +------+ +------+ +-----------+
| | | |
|----1---->|--1--> | |
| ^ | --> | |
| | | -->X LOST | |
| period | | |
| | | | |
| V |--1--> | |
| ^ | --> | | ^
| | | --> | | |
| period | --> | | period
| | | --> | | |
| V |--1--> --> | | V
| ^ | --> --->|----1---->| 1 arrived
| | | --> <-ACK1-|send ACK1 |
| period | -><- | |
| | | <-- --> | |
| V |--1--><-- --> | |
| | <-- --->|drop 1,3 |
| ACK1|<--- --> <-ACK1-|send ACK1 |
| | --><-- | |
...
Note: "--1--> " represents the tunneled version of packet/frame 1.
"<-ACK1-" represents an ACK corresponding to packet/frame 1.
Figure 4
4. Definition of the protocol fields
The structure of a Simplemux separator in blast flavor is shown in
Figure 5. The size is always 6 bytes.
+-----------------+--------+----------------+--------+
| Length |Protocol| Identifier | ACK/HB |
+-----------------+--------+----------------+--------+
16 bits 8 bits 16 bits 8 bits
Figure 5
These are the details of the fields:
Saldana Expires 6 July 2024 [Page 7]
Internet-Draft Simplemux January 2024
* Length (LEN, 16 bits). The length of the multiplexed packet/
frame.
* Protocol (8 bits). Defined according to IANA "Assigned Internet
Protocol Numbers."
* Identifier (16 bits). It uniquely identifies each packet of a
flow (packets in different directions MAY have the same
identifier).
* ACK/Heartbeat (8 bits). It may have three values:
- 0: this is a packet that requires an ACK.
- 1: the packet is an ACK.
- 2: the packet is a heartbeat.
The structure of an ACK is the same, but the Length and Protocol
fields MUST be 0.
Both communication ends exchange heartbeat packets periodically. The
Length and Protocol fields MUST be 0.
Examples of the structure of Simplemux packets can be found in
[I-D.saldana-tsvwg-simplemux]
As the Identifier field has 16 bits, the same identifiers will be
repeated periodically. It will be necessary to define a timeout for
stopping the periodical sending of a frame.
5. IANA Considerations
The same protocol number used for [I-D.saldana-tsvwg-simplemux] can
be employed.
6. Security Considerations
Security protocols can be employed to protect the traffic that
traverses a public IP network. There is no need to define any new
security protocol for this use case.
7. References
7.1. Normative References
Saldana Expires 6 July 2024 [Page 8]
Internet-Draft Simplemux January 2024
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[IEC_61850-90-5]
IEC, "Communication networks and systems for power utility
automation-Use of IEC 61850 to transmit syn-chrophasor
information according to IEEE C37.118 Technical Report
Edition 1.0.", IEC 61850 90-5, 2012.
[IEC_61850-90-1]
IEC, "Communication networks and systems for power utility
automation-Use of IEC 61850 for the communication between
substations Technical Report Edition 1.0", IEC 61850 90-1,
2010.
7.2. Informative References
[Saldana] Saldana, J., Prada Hurtado, A., Martinez-Carrasco, E.,
Galve, Y., and J. Torres, "Fast and Reliable Sending of
Generic Object Oriented Substation Event Frames between
Remote Locations over Loss-Prone Networks", MDPI
Sensors 2023, 23(21), 8879, 2023.
[I-D.saldana-tsvwg-simplemux]
Saldana, J., "Simplemux. A generic multiplexing protocol",
December 2023, <https://datatracker.ietf.org/doc/draft-
saldana-tsvwg-simplemux/>.
Author's Address
Jose Saldana
CIRCE Technology Center
Spain
Email: jmsaldana@fcirce.es
Saldana Expires 6 July 2024 [Page 9]
