RAW multidomain extensions
Universidad Carlos III de Madrid
Av. Universidad, 30Leganes, Madrid28911Spain+34 91624 6236cjbc@it.uc3m.eshttp://www.it.uc3m.es/cjbc/
InterDigital Europe
Alain.Mourad@InterDigital.comhttp://www.InterDigital.com/
Routing
DetNet
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.
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 includes the concept
of multi-domain in the DetNet Service reference model (Fig. 5 of , reproduced here in 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.
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:
Sequencing information, by adding a sequence number or time stamp as part of
DetNet. This is typically done once, at or near the source.
Replicating packets into multiple DetNet member flows, and typically sending
them along multiple different paths to the destination(s).
Eliminating duplicate packets of a DetNet flow based on the sequencing
information and a history of received packets.
Reordering DetNet flow's packets that are received out of order.
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 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 , 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)
, 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 , 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 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. 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 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.
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.