[Raw] RAW notes

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear all

Many thanks for all those who attended the side meeting last Thursday morning in Ste Catherine., and those who joined the ad-hoc webex. Sorry for the issues starting it, my mistake, not Webex. Also, special thanks to Rand, Lou and Ronald for coming and for their useful inputs.

Below are my RAW notes ; please come back to the list for anything I missed or that I might have misunderstood.

Summary:


  *   RAW extends DetNet to focus on issues that are mostly radio-specific and relate to less consistent transmissions, energy constraints and shared spectrum efficiency. As a technique to optimize forwarding, RAW naturally belongs to RTG Area.
  *   The group needs to write a problem statement that separates the routing time scale and the forwarding time scale, and focuses on forwarding time operations on a given routing construct.
  *   RAW should stay abstract to the radio layer (keep a layered approach). How the PHY is programmed, and whether the radio is single-hop or meshed, are unknown at the IP layer and not part of the RAW abstraction. E.g., programming TSCH slots is out of scope - it may be an item to either recharter 6TiSCH or form a new WG in INT Area.
  *   The RAW charter should present the work as generic (IP layer), the 4 technologies being not limitative but examples against which we assert our generic solution
  *   There may be overlaps with MANET (e.g., use of DLEP), and MANET is well-observed by radio vendors. On the other hand, as an approach towards deterministic networking, RAW is neither mobile not ad-hoc, pretty much the very opposite.


In more details:


  *   A prerequisite to the RAW work is that an end-to-end routing function computes a complex path (we can use the 6TISCH definition of a Track) with a high degree of redundancy and diversity (DetNet PREOF, end-to-end network coding, and possibly radio-specific abstracted techniques such as ARQ, overhearing, frequency diversity, time slotting, and possibly others). How the  routing operation computes the Track is out of scope for RAW. The scope of the RAW operation is one Track, and the goal of the RAW operation is to optimize the use of the Track at the forwarding timescale to maintain the expected service while optimizing the usage of constrained resources such as energy and spectrum.
  *   Another prerequisite is that an IP link can be established over the radio with some guarantees in terms of service reliability, e.g., it can be relied upon to transmit a packet within a bounded latency and provides a guaranteed BER/PDR outside rare but existing transient outage windows that can last from split seconds to minutes. The radio layer can be programmed with abstract parameters, and can return an abstract view of the state of the Link to help forwarding decision (think MANET's DLEP). In the layered approach, how the radio manages its PHY layer is out of control and out of scope. Whether it is single hop or meshed is also unknown and out of scope.
  *   The end-to-end routing can be centralized and can reside outside the network. Reaching to the routing computation can be slow in regards to the speed of events that affect the forwarding operation at the radio layer. Due to the cost and latency to perform a route computation, routing is not expected to be sensitive/reactive to transient changes. The abstraction of a link at the routing level is expected to use statistical operational metrics that aggregate the behavior of a link over long periods of time, and represent its availability as a shade of gray as opposed to either up or down. We distinguish the time scale at which routes are computed that we qualify as slow from the forwarding time scale where per-packet decisions are made. RAW operates at the forwarding time scale on one DetNet flow over one Track.
  *   RAW observes the whole Track in quasi real time. It will consider existing tools such as L2-triggers, DLEP, BFD and inband-OAM to observe the Track, and BIER-TE and SR to control the use of the Track on individual packets.
  *   RAW decisions may be made at the ingress and signaled in-band. Alternatively, they may be made at intermediate hops and depend on the current state of the next hop and local policies. In either case, a per-flow state is installed in all intermediate nodes to recognize the flow and determine the forwarding policy to be applied.


Next steps:


  *   Revise the proposed charter
  *   Send the charter to RTG, request formation a WG
  *   Publish a problem statement draft

All the best

Pascal