Re: [Raw] RAW notes

[Janos Farkas <[e-mail]>]

Hi Pascal,

Thank you for the notes!

Frankly speaking, I understand that work needs to be done as we cannot yet claim having all the details of Layer 3 deterministic wireless networking addressed; however, the details of the work to be done are not clear for me at all. Based on the discussions so far, it is even less clear whether or not a new WG is needed. Actually, I think it would be better to conduct the work to address missing pieces in the relevant existing Working Groups.

I agree that a problem statement draft would be a great next step. It would be even better if gap analysis could be included.
Having the draft, it could be submitted to and discussed at the relevant WGs, so we could see what they say to the problem and the gaps, what they could do. In addition to DetNet, MANET, CCAMP, which were brought up at the session, further relevant WGs are listed on page 4 in https://datatracker.ietf.org/meeting/104/materials/slides-104-paw-03-detnet-overview-00.pdf.

My view on DetNet includes that DetNet is the WG of the IETF that is overall responsible for the architecture to provide Deterministic Networking on Layer 3 and specify corresponding details as necessary keeping in mind to leverage existing work as much as possible.

"RAW extends DetNet" reads to me that DetNet extensions necessary for wireless should be done in DetNet. For instance, if additional parameters would be needed for a DetNet flow supported by wireless segments, then that could be contributed to the DetNet flow information model draft. Actually, I'd be glad to see it contributed to DetNet what is missing and needed for wireless, and address those needs in DetNet.

As you captured in the notes, DLEP was brought up as potentially very useful. Furthermore, CCAMP was brought up multiple times as CCAMP has addressed various technologies that may have a lot of similarities, e.g., microwave recently.

I agree that radio layer details should remain abstract from Layer 3 perspective.

Actually, my layered view is:

.
.
.
----------------------
DetNet
-----------------------
optionally: TSN
-----------------------
Radio Technology
-----------------------


I do not see the need for a new WG in this layered view.


It is good that we discussed RAW details at the side meeting and did not spend time on the two information item I thought to share. I can share it now. It is just background information, but still may be somewhat relevant.

There are efforts happening at Layer 2 for deterministic wireless. For instance:

3GPP SA2 is working on 5G System support for integration with IEEE 802.1 TSN networks. The architectural extensions to support integration of IEEE 802..1 TSN networks are documented in 3GPP TS 23.501. For lack of better further reference, let me point to the one I have at hand; the liaison exchange on the subject:
https://1.ieee802.org/july-2019-plenary-meeting-in-vienna-austria-tsn-tg-agenda/#Monday_TSN

IEEE P802.11be (TGbe) and IEEE 802.1 TSN TG had a joint session to see where we are with WLAN - TSN integration and what could be done:
https://1.ieee802.org/july-2019-plenary-meeting-in-vienna-austria-tsn-tg-agenda/#Tuesday_80211_TGbe_8211_8021_TSN
 (An analogy to my view on DetNet responsibilities mentioned above: It is the IEEE 802.1 WG who is responsible for the overall IEEE 802 LAN/MAN architecture.)

The reason I added TSN as an option to the layer view is that in case of a wireless - TSN integrated subnet, DetNet may leverage such a subnet.


I'm looking forward to see the problem statement and gap analysis to see what is missing for Layer 3 deterministic wireless networking.

My 2 cents,
Best regards,
Janos


Ps:
I'm sorry for sending this mail from vacation; which may imply delayed response on my part. Nonetheless, I thought it may be better to share these thoughts earlier than later.




From: Raw <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, July 29, 2019 3:07 PM
To: [e-mail]
Cc: 'Lou Berger ([e-mail])' <[e-mail]>; Randal Atkinson <[e-mail]>
Subject: [Raw] RAW notes

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