| Internet-Draft | Multi-domain DetNet framework | July 2022 |
| Bernardos & Mourad | Expires 11 January 2023 | [Page] |
This document addresses the multi-domain DetNet problem, analyzing what the technical gaps are and exploring some possible solutions. Application, control and data plane aspects are in scope. The goal is to help understanding what might be the next steps towards enabling DetNet in multi technology and/or administrative domains.¶
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 11 January 2023.¶
Copyright (c) 2022 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.¶
The Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability.¶
The DetNet architecture document [RFC8655] includes the concept of multi-domain in the DetNet Service reference model (Fig. 5 of [RFC8655], reproduced here in Figure 1 for convenience. However, the WG has not yet worked in detail on the necessary protocol operations to support multi-domain at control and data plane.¶
DetNet DetNet
End System End System
_ _
/ \ +----DetNet-UNI (U) / \
/App\ | /App\
/-----\ | /-----\
| NIC | v ________ | NIC |
+--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+
| / \__/ \ | |
| / +----+ +----+ \_____ | |
| / | | | | \_______ | |
+------U PE +----+ P +----+ \ _ v |
| | | | | | | ___/ \ |
| +--+-+ +----+ | +----+ | / \_ |
\ | | | | | / \ |
\ | +----+ +--+-+ +--+PE |------ U-----+
\ | | | | | | | | | \_ _/
\ +---+ P +----+ P +--+ +----+ | \____/
\___ | | | | /
\ +----+__ +----+ DetNet-1 DetNet-2
| \_____/ \___________/ |
| |
| | End-to-End Service | | | |
<------------------------------------------------------------->
| | DetNet Service | | | |
| <------------------------------------------------> |
| | | | | |
In adddition to the DetNet work, there is also wireless-focused efforts being explored at the Reliable and Available Wireless (RAW) WG. Wireless operates on a shared medium, and transmissions cannot be fully deterministic due to uncontrolled interferences, including self-induced multipath fading. RAW is an effort to provide Deterministic Networking on across a path that include a wireless interface. RAW provides for high reliability and availability for IP connectivity over a wireless medium. The wireless medium presents significant challenges to achieve deterministic properties such as low packet error rate, bounded consecutive losses, and bounded latency. RAW extends the DetNet Working Group concepts to provide for high reliability and availability for an IP network utilizing scheduled wireless segments and other media, e.g., frequency/time-sharing physical media resources with stochastic traffic: IEEE Std. 802.15.4 timeslotted channel hopping (TSCH), 3GPP 5G ultra-reliable low latency communications (URLLC), IEEE 802.11ax/be, and L-band Digital Aeronautical Communications System (LDACS), etc. Similar to DetNet, RAW technologies aim at staying abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability.¶
DetNet defines the Packet Replication, Elimination, and Ordering Functions (PREOF) as a way to provide service protection. PREOF involves 4 capabilities:¶
Packet (hybrid) ARQ, Replication, Elimination and Ordering (PAREO) is a superset of DetNet's PREOF, defined in RAW, that includes radio-specific techniques such as short range broadcast, MUMIMO, constructive interference and overhearing, which can be leveraged separately or combined to increase the reliability.¶
There multiple scenarios and use cases that might involve multiple technology and/or administrative domains in DetNet and RAW. For example, there are several use cases [I-D.ietf-raw-use-cases] where reliability and availability are key requirements for wireless heterogeneous networks. A couple of relevant examples are (i) the manufacturing sector, where a plethora of devices are interconnected and generate data that need to be reliably delivered to the control and monitoring agents; and (ii) the residential gaming, with eXtended Reality (XR).¶
Next sections explore what the main multi-domain aspects for the application, controller and network/data planes in DetNet and RAW are, to then identify some existing gaps that would require further work at the IETF.¶
As described in [RFC8655], the Application Plane incorporates the User Agent, a specialized application that interacts with the end user and operator and performs requests for DetNet services via an abstract Flow Management Entity (FME), which may or may not be collocated with (one of) the end systems. At the Application Plane, a management interface enables the negotiation of flows between end systems.¶
In a multi-domain deployment, the User Agent might be aware of the existance of multiple domains or it might be unaware. A multi-domain aware User Agent/application plane could take care of the negotiation of the flows at all involved domains, whereas a multi-domain unaware one will have to rely on the network to take care of it transparently.¶
We refer to the controller plane as the aggregation of the Control and Management planes. The term "Controller Plane Function (CPF)" refers to any device operating in that plane, whether it is a Path Computation Element (PCE) [RFC4655], a Network Management Entity (NME), or a distributed control protocol. The CPF is a core element of a controller, in charge of computing deterministic paths to be applied in the Network Plane. A (Northbound) Service Interface enables applications in the Application Plane to communicate with the entities in the Controller Plane.¶
In DetNet, one or more CPFs collaborate to implement the requests from the FME as per-flow, per-hop behaviors installed in the DetNet nodes for each individual flow. Adding multi-domain support might require some support at the CPF. For example, CPFs sitting at different domains need to discover themselves, authenticate and negotiate per-hop behaviors. Depending on the multi-domain support provided by the application plane, the controller plane might be relieved from some reponsibilities (e.g., if the application plane is taking care of splitting what needs to be provided by each domain).¶
Let's know take the case of RAW. As introduced in [I-D.ietf-raw-architecture], RAW separates the path computation time scale at which a complex path is recomputed from the path selection time scale at which the forwarding decision is taken for one or a few packets. RAW operates at the path selection time scale. The RAW problem is to decide, amongst the redundant solutions that are proposed by the Patch Computation Element (PCE), which one will be used for each packet to provide a Reliable and Available service while minimizing the waste of constrained resources. To that effect, RAW defines the Path Selection Engine (PSE) that is the counter-part of the PCE to perform rapid local adjustments of the forwarding tables within the diversity that the PCE has selected for the Track. The PSE enables to exploit the richer forwarding capabilities with Packet (hybrid) ARQ, Replication, Elimination and Ordering (PAREO), and scheduled transmissions at a faster time scale.¶
While there exist inter-PCE solutions today, allowing one domain's PCE to learn some inter-domain paths, this would not be sufficient, as the PSE of one domain would not have full visibility nor capability to act on the other domains (e.g., there are no multi-domain OAM solutions in place yet), limiting its capability to guarantee any given SLA. Therefore, there is a need to define inter-PSE coordination mechanisms across domains.¶
There exist today standardized solutions, such as the ones in the context of Path Computation Element (PCE), enabling computing multi-/inter-domain paths. As an example, the Hierarchical PCE (G-PCE) was defined in RFC 6805 [RFC6805] and is described hereafter. A parent PCE maintains a domain topology map that contains the child domains (seen as vertices in the topology) and their interconnections (links in the topology). The parent PCE has no information about the content of the child domains; that is, the parent PCE does not know about the resource availability within the child domains, nor does it know about the availability of connectivity across each domain because such knowledge would violate the confidentiality requirement and either would require flooding of full information to the parent (scaling issue) or would necessitate some form of aggregation. The parent PCE is used to compute a multi-domain path based on the domain connectivity information. A child PCE may be responsible for single or multiple domains and is used to compute the intra-domain path based on its own domain topology information.¶
Solutions like the above are not sufficient alone to solve the multi-domain RAW problem, as the PSEs need to have some additional information from the other involved domains to be sensitive/reactive to transient changes, in order to ensure a certain level of reliability and availability in a multi-domain wireless heterogeneous mesh network. [I-D.bernardos-raw-multidomain] explores in more detail the RAW-specific multi-domain problem and proposes some initial solutions.¶
The Network Plane represents the network devices and protocols as a whole, regardless of the layer at which the network devices operate. It includes the Data Plane and Operational Plane (e.g., OAM) aspects. A Southbound (Network) Interface enables the entities in the Controller Plane to communicate with devices in the Network Plane.¶
At the Network Plane, DetNet nodes may exchange information regarding the state of the paths, between adjacent DetNet nodes and possibly with the end systems. In a multi-domain environment, nodes belonging to different domains might need to exchange information. This might require protocol translations and/or abstractions, as the different domains might not offer the same capabilities nor use the same network protocols. Additionally, OAM protocols [I-D.ietf-detnet-oam-framework] might also need to be extended to support multi-domain operation.¶
Note as well, that performing PREOF or PAREO across multiple domains poses additional challenges, as knowledge of all the involved domains might not be available and/or the data planes at each domain could also be different.¶
TBD.¶
TBD.¶
This work has been partially supported by the Spanish Ministry of Economic Affairs and Digital Transformation and the European Union-NextGenerationEU through the UNICO 5G I+D 6G-DATADRIVEN-04.¶