Skip to main content

Deterministic Networking
charter-ietf-detnet-02-01

The information below is for a proposed recharter. The current approved charter is version 02
Document Proposed charter Deterministic Networking WG (detnet)
Title Deterministic Networking
Last updated 2022-04-06
State Draft Charter Rechartering
WG State Active
IESG Responsible AD John Scudder
Charter edit AD John Scudder
Telechat date (None)
Send notices to (None)

charter-ietf-detnet-02-01
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 Working Group addresses Layer 3 aspects in
support of applications requiring deterministic networking. The Working Group
collaborates with IEEE802.1 Time-Sensitive Networking (TSN), which is
responsible for Layer 2 operations, to define a common architecture for both
Layer 2 and Layer 3. Example applications for deterministic networks include
professional and home audio/video, multimedia in transportation, engine control
systems, and other general industrial and vehicular applications being
considered by the IEEE 802.1 TSN Task Group.

The Working Group will initially focus on solutions for networks that are under
a single administrative control or within a closed group of administrative
control; these include not only campus-wide networks but also can include
private WANs. The DetNet WG will not spend energy on solutions for large groups
of domains such as the Internet.

The Working Group is responsible for the overall DetNet architecture and
DetNet-specific specifications that encompasses the data plane, OAM
(Operations, Administration, and Maintenance), time synchronization,
management, control, and security aspects which are required to enable a
multi-hop path, and forwarding along the path, with the deterministic
properties of controlled latency, low packet loss, low packet delay variation,
and high reliability. The work applies to point-to-point (unicast) and
point-to-multipoint (multicast) flows which can be characterized in a manner
that allows the network to 1) reserve the appropriate resources for the flows
in advance, and 2) release/reuse the resources when they are no longer
required. The work covers the characterization of flows, the encapsulation of
frames, the required forwarding behaviors, as well as the state that may need
to be established in intermediate nodes. Layer 3 data plane technologies that
can be used include: IP and MPLS, and Layer 2 encapsulations that run over IP
and/or MPLS, such as pseudowires and GRE.

The Working Group will document which deployment environments and types of
topologies are within (or outside) the scope of the DetNet architecture. This
work focuses on the data plane aspects and is independent from any path setup
protocol or mechanism. The Working Group will also document DetNet Controller
Plane approaches that reuse existing IETF solutions, such as Path Computation
Element (PCE), and identify the Working Group responsible for any extensions
needed to support DetNet. Documents produced by the Working Group will be
compatible with the work done in IEEE802.1 TSN and other IETF Working Groups. 
The Working Group's scope explicitly excludes modifications of transport
protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss
requirements for such modifications and the work will be done in the Working
Group responsible for the technology.

DetNet is chartered to work in the following areas:

Overall architecture: This work encompasses the data plane, OAM, time
synchronization, management, control, and security aspects.

Data plane: This work will document how to use IP and/or MPLS, and related OAM,
to support a data plane method of flow identification, and packet treatment
(including, for example, forwarding, service protection, and queuing) over
Layer 3. Other IETF defined data plane technologies may also be used.

Controller Plane: The DetNet Controller Plane is defined in RFC 8655 as
"the aggregation of the Control and Management Planes". This work
will document how to use IETF control plane solutions to support DetNet,
including the identification of any gaps in existing solutions. Any
modification to Controller Plane protocols to address identified gaps should be
carried out in their associated Working Groups, but may be done in DetNet if
agreed to by the relevant Working Group chairs and responsible Area Directors.

Data flow information model: This work will identify the information needed for
flow establishment and control and be used by reservation protocols and YANG
data models. The work will be independent from the protocol(s) used to control
the flows (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).

YANG models: This work will document device and link capabilities (feature
support) and resources (e.g. buffers, bandwidth) for use in device
configuration and status reporting. Such information may also be used when
advertising the deterministic network elements to a control plane. Control
plane related information will be independent from the protocol(s) which may be
used to advertise this information (e.g. IS-IS or GMPLS extensions). Any new
YANG models will be coordinated with the Working Groups that define any base
models that are to be augmented.

As needed, vertical requirements: This effort will detail the requirements for
deterministic networks in various industries that have previously not been
documented and cannot be supported using defined DetNet solutions.

To investigate whether existing data plane encryption mechanisms can be
applied, possibly opportunistically, to improve security and privacy.

The Working Group coordinates with other relevant IETF Working Groups,
including CCAMP, IPPM, LSR, PCE, PALS, TEAS, TSVWG, RAW, and 6TiSCH. As the
work progresses, requirements may be provided to the responsible Working Group,
e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to maintain the
consistency of the overall architecture and related solutions. The WG will
liaise with appropriate groups in IEEE and other Standards Development
Organizations (SDOs).

Proposed milestones

No milestones for charter found.