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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . Author's Address Jose Saldana CIRCE Technology Center Spain Email: jmsaldana@fcirce.es Saldana Expires 6 July 2024 [Page 9]