* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Birds of a Feather Meetings (IETF Pre-WG Efforts)

This page provides one common place that lists "possible IETF pre-WG efforts", known as Birds of a Feather ("BoF") meetings. Anybody who proposes a BoF is strongly encouraged to register the BoF effort here at such time as appropriate; e.g., during steps 1 and 2 in RFC 5434. Also see https://www.ietf.org/wg/bof-procedures.html.

The IAB will also attempt to provide BoF Shepherds as described in their document on the subject only on request from the IESG. If you feel that your BoF would benefit from an IAB BoF Shepherd, please discuss this with your Area Director.

To allow the Secretariat to schedule a BoF slot if it is approved, each entry MUST include the following items:

  • Long name and abbreviation
  • Description, including whether the BoF is intended to form a WG or not
  • The responsible Area Director (AD)
  • BoF Chairs (or the ADs as placeholders)
  • Number of people expected to attend
  • Length of session (1, 1.5, 2, or 2.5 hours)
  • Conflicts to avoid (whole Areas and/or WGs)
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Template for BOF Entry - Please do not edit the BoF Example Page directly.

Timeframe IETF 106 (Singapore)

The current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 23:59 UTC Friday, 2019-10-04. The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconference, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before 2019-10-11.

Applications and Real-Time






Operations and Management




  • Name: Reliable and Available Wireless (RAW)
  • Description:
    • IP networks become more deterministic when the effects of statistical multiplexing (jitter and collision loss) are eliminated. This requires a tight control of the physical resources to maintain the amount of traffic within the physical capabilities of the underlying technology, e.g., by the use of time-shared resources (bandwidth and buffers) per circuit, and/or by shaping and/or scheduling the packets at every hop.
    • Wireless networks operate on a shared medium, and thus transmissions cannot be fully deterministic due to uncontrolled interferences, including the self-induced multipath fading. However, scheduling of transmissions can alleviate those effects by leveraging diversity in the spatial, time and frequency domains, providing a more predictable and available service.
    • The wireless and wired media are fundamentally different at the physical level, and while the generic Problem Statement for DetNet applies to the wired as well as the wireless medium, the methods to achieve RAW will differ from those used to support time-sensitive networking over wires, and a RAW solution will need to address less consistent transmissions, energy conservation and shared spectrum efficiency.
    • The development of RAW technologies has been lagging behind deterministic efforts for wired systems both at the IEEE and the IETF. But recent efforts at the IEEE and 3GPP indicate that wireless is finally catching up at the lower layer and that it is now possible for the IETF to extend DetNet for wireless segments that are capable of scheduled wireless transmissions.
    • The establishment of the path is out of scope, and may inherit from a centralized Architecture as described for DetNet and 6TiSCH, with a primary focus on scheduled wireless operations. As opposed to wire, the action of setting up a path on a wireless network may be slow compared to the speed at which the transmission conditions vary, and the extra medium used for redundancy may be expensive. So in wireless, it makes sense for a centralized router to provide multiple forwarding solutions and leave it to the data plane to select which of those solutions are used fir a given packet based on the current conditions.
    • The scope of the RAW WG will be protocol elements such as OAM to improve the forwarding decision along a path where intermediate nodes are capable of transmission redundancy, e.g., using packet replication and elimination, Hybrid ARQ and coding, but is constrained so as not to overuse this methods, eg., because energy and spectrum are limited.
    • 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.
  • Status: WG Forming
  • Responsible AD: TBD
  • BoF proponents: Pascal Thubert <pthubert@cisco.com>, Ethan Grossman <eagros@dolby.com>, Corinna Schmitt <corinna.schmitt@unibw.de>
  • BoF chairs: Pascal Thubert, Ethan Grossman
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): 6TiSCH, DetNet, LPWAN





IAB Sessions


Previous meeting BOFs

Timeframe IETF 106 (Singapore)?

Timeframe IETF 105 (Montreal)

Timeframe IETF 104 (Prague)

Timeframe IETF 103 (Bangkok)

Timeframe IETF 102 (Montreal)

Timeframe IETF 101 (London)

Timeframe IETF 100 (Singapore)

Timeframe IETF 99 (Prague)

Timeframe IETF 98 (Chicago)

Timeframe IETF 97 (Seoul)

Timeframe IETF 96 (Berlin)

Timeframe IETF 95 (Buenos Aires)

Timeframe IETF 94 (Yokohama)

Timeframe IETF 93 (Prague)

Timeframe IETF 92 (Dallas)

Timeframe IETF 91 (Honolulu)

Timeframe IETF 90 (Toronto)

Timeframe IETF 89 (London)

Timeframe IETF 88 (Vancouver)

Timeframe IETF 87 (Berlin)

Timeframe IETF 86 (Orlando)

Timeframe IETF 85 (Atlanta)

Timeframe IETF 84 (Vancouver)

Timeframe IETF 83 (Paris)

Timeframe IETF 82 (Taipei)

Timeframe IETF 81 (Quebec City)

Timeframe IETF 80 (Prague)

Timeframe IETF 79 (Beijing)

Timeframe IETF 78 (Maastricht)

Timeframe IETF 77 (Anaheim)

Timeframe IETF 76 (Hiroshima)

Timeframe IETF 75 (Stockholm)

Timeframe IETF 74 (San Francisco)

Timeframe IETF 73 (Minneapolis)

Timeframe IETF 72 (Dublin)

Timeframe IETF 71 (Philadelphia)

Timeframe IETF 70 (Vancouver)

Timeframe IETF 69 (Chicago)

Timeframe IETF 68 (Prague)

Timeframe IETF 67 (San Diego)

Timeframe IETF 66 (Montreal)

Timeframe IETF 65 (Dallas)