DetNet Enhanced Data
PlaneHuawei156 Beiqing Rd.Beijing100095Chinagengxuesong@huawei.comHuawei156 Beiqing Rd.Beijing100095Chinazhoutianran@huawei.comHuawei156 Beiqing Rd.Beijing100095Chinazhangli344@huawei.comChina MobileNo.32 XuanWuMen West StreetBeijing100053Chinaduzongpeng@foxmail.comDetNetAiming at providing the bounded latency to DetNet services, DetNet
data plane is required to be enhanced. This document provides a method
to extend DetNet data plane by introducing the Bounded Latency
Information (BLI), which facilitates DetNet transit nodes to guarantee
the bounded latency transmission in data plane.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .DetNet provides the capability to carry
specified unicast or multicast data flows with extremely low data loss
rates and bounded end-to-end latency within a network domain. Three
primary goals of DetNet QoS are defined in section 3.1 of :Minimum and maximum end-to-end latency from source to
destination, timely delivery, and bounded jitter (packet delay
variation) derived from these constraints.Packet loss ratio under various assumptions as to the operational
states of the nodes and links.An upper bound on out-of-order packet delivery. It is worth
noting that some DetNet applications are unable to tolerate any
out-of-order delivery.To fulfill the goals of DetNet QoS, DetNet architecture defines a DetNet data plane protocol stack, which
includes DetNet forwarding and service sub-layers. Specifically, DetNet
data plane framework specifies two metadata of
flow identity and sequence number to be encoded in data plane. Flow-ID
is used for identification of the flow or aggregate flow to decide the
DetNet traffic treatment and PREOF in both sub-layers. At the same time,
sequence number is only used for PREOF in service sub-layer.For IP DetNet data plane, specifies a method
of using 6-tuple to identify DetNet flows. Management and control
information defined in DetNet YANG module is used to select the forwarding
outgoing interface and next hop. It is stated that the allocation of
system resources and provisioning of related parameters is used for
DetNet traffic treatment. However, doesn't
further specify the related parameters used in data plane.In , DetNet Control Word (d-CW), DetNet
service label (S-Label), and DetNet MPLS forwarding label(s) (F-Label)
are defined for the MPLS-based DetNet data plane encapsulation, where
the first two information is mainly used for the DetNet service
sub-layer functions, the last information is used for the DetNet
forwarding sub-layer functions. DetNet controller plane takes the
responsibility to provision both flow identification information and the
flow-specific resources needed to provide traffic treatment to meet each
flow's service requirements. There is no specification in MPLS DetNet
data plane to empower the packet treatment capabilities.There are also other specifications of DetNet data planes such as
, , , , and . These documents specifies the DetNet data planes and
interworking technologies of one type of network operating over another
sub-network in order to extend the DetNet service range. However, these
documents do not introduce new procedure or process, but to follow the
specifications defined in and .To meet the requirements for large-scale deterministic networks and
support the bounded latency objective specified in , DetNet data plane is
required to be enhanced in the following aspects:Explicit inclusion of the metadata used for traffic treatment,
especially for bounded latency and jitter, when considering the
support of DetNet flows scalability in large scale DetNet
networksCompatibility to different options of queuing, shaping, policing
or any other underlying network technologies, in order to provide
bounded latencyMinimize the end-to-end delay difference of multiple forwarding
paths that are used for packet replication and eliminationDetNet data plane processing of DetNet flow coexists with the
non-DetNet flowsThis documents provides a method to extend DetNet data plane by
introducing Bounded Latency Information (BLI), which facilitates DetNet
transit nodes to guarantee the bounded latency transmission in data
plane. The resources include the QoS mechanisms, scheduling mechanisms,
or any other mechanisms from underlying network layer so as to support
bounded latency. This document also proposes a format of bounded latency
information and its encapsulations on DetNet data planes.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only
when, they appear in all capitals, as shown here.The abbreviations used in this document are:BLI: Bounded Latency InformationPREOF: Packet Replication, Elimination, and Ordering FunctionsIn order to support the enhanced traffic treatment functions, such as
bounded latency, DetNet data plane is enhanced by carrying a new defined
metadata information in DetNet service packets: Bounded Latency
Information (BLI).DetNet uses either one or combination of QoS related and resource
allocation technologies to ensure the end-to-end bounded latency. introduces a set of
scheduling mechanisms can be used to assure the bounded latency. uses a single stack data structure to provide
a unified approach to forwarding and deadline based scheduling. Noted
that in most scheduling process, an ancillary information is required to
be transmitted between DetNet nodes to facilitate local scheduling. In
this document, this ancillary information is named bounded latency
information. Bounded latency information is transmitted across multiple
DetNet transit nodes and used by the DetNet forwarding sub-layer.To cope with a variety of scheduling mechanisms and transfer
different information in a uniform format in data plane, the bounded
latency information is abstracted and classified into two categories:
requirement and resource.Bounded latency information in the requirement category may include
the information like the end-to-end delay budget, local delay budget,
local deadline, delay variation budget, local delay variation budget
etc. For example, end-to-end delay budget describes the upper bounded
latency value of DetNet flow in network. Then DetNet node may use this
information to determine the packet priority or which queue can be
used to transmit this packet. Local delay budget is a variation of
end-to-end delay budget when multiple DetNet nodes may have same or
different delay budget time of each in DetNet network. Deadline is
straightforward to indicate how much time is left for this packet to
meet the upper bounded latency requirement. Similar practice in
6LoWPANs is given by . The usage of this
information is similar to the delay budget information when DetNet
node decides the priority or queue for the packet forwarding. Delay
variation is another
deterministic goal required by DetNet and should be considered in
scheduling process when it is required. Priority can also be a type of
requirement. DetNet application may assign its priority by different
meanings and formats, which may not be equivalently fulfilled by
existing QoS priority.Bounded latency information in the resource category includes the
information like cycle ID, queue ID, and time slot ID etc. Since
cycles, queues, or time slots are the real resources can be allocated
for DetNet flow, they are named as the time resource ID. For example,
time resource ID can represent a cycle ID when cyclic queuing
mechanism is used on DetNet node. Time resource ID can also represent
a queue ID when queue based scheduling mechanism is locally used on
DetNet node. Time resource ID can represent a time slot ID too, when a
time slot based mechanism like is used.This section introduces the data field of bounded latency information
in DetNet data plane. The format of the data field is shown as
follows.where:Bounded Latency Information Type: 8-bit identifier to represent
the type of bounded latency information. A new registry is expected
to be created and the value is assigned by IANA. Table 1 lists the
value of BLI Type and the corresponding Bounded Latency Information
defined so far,Format: 8-bit value to indicate the format of bounded latency
information. For example, the format could be 16-bit unsigned
integer, 32-bit unsigned integer, PTP or NTP timestamp, and other
pre-configured formats. Table 2 lists the value of Format and the
corresponding Format defined so far,Bounded Latency Information Type and Format are used together to
specify the type, length and format of the bounded latency
information.Reserved: Reserved for future usage.Time resource ID: the identifier to indicate the underlying
resources used for bounded latency. The format is 32-bit unsigned
integer.Priority: QoS priority of the DetNet service packet. As six bits
of the Differentiated Services Field are
used as a codepoint (DSCP), the format of priority is 8-bit unsigned
integer.End-to-end delay budget: the end-to-end delay requirement of
DetNet service packet. The format is 32-bit unsigned Integer.Local delay budget: the per hop delay requirement of DetNet
service packet on this network node. The format is 32-bit unsigned
Integer.End-to-end deadline: the time when the packet must arrive at the
final destination or exit the DetNet network. This time is usually
the birth time plus the end-to-end delay budget. The format is the
timestamp with proper length.Local deadline: the time when the packet must exit this network
node. The format is the timestamp with proper length.End-to-end delay variation budget: the end-to-end delay variation
requirement of DetNet service packet. The format is 16-bit unsigned
Integer.Local delay variation budget: the per hop delay variation
requirement of DetNet service packet on this network node. The
format is 16-bit unsigned Integer.Flags: 8 bits of flags. A new registry "Bounded Latency Flags" is
expected to be created. At the writing time, all flags are unused
and undefined.Reserved: Keeps zero when it is not specified.Bounded Latency Information: indicates the bounded latency
information used for local scheduling processing. Table 1 shows the
bounded latency information type and the corresponding values. The
bounded latency information is different depending on the type of
bounded latency information.BLI data field can be encapsulated in different DetNet data
planes.For IPv6 based DetNet data plane, the data field of bounded latency
information is recommended to be carried in IPv6 Extension Header
Options, called Bounded Latency Information Option, shown in the
following Figure.Option Type: 8-bit identifier of the type of option. Value TBD
by IANA; the highest-order 3 bits of this field is 001 to skip
over this option and continue processing the header if the
processing IPv6 node does not recognize the Option Type and to
permit the Option Data may change en route to the destination of
packet.Opt Data Len: 8-bit unsigned integer. Length of the Option Data
field of this option, in octets.For Bounded Latency Information data field, see section 4 for
details.Bounded latency information data field is encapsulated in
either IPv6 Hop-by-Hop Options header or IPv6 Destination Options
header depending on the processing happens at each hop or at the last
hop. More than one bounded latency information can appear in one
Bounded Latency Information Option. The Option Data Length and the
Format are used to locate every bounded latency information. The
encapsulation of Bounded Latency Information Option is shown in Figure
4 and Figure 5.An MPLS extension header is proposed in . An MPLS Extension Header
(EH) encapsulated with the format of bounded latency information is
called Bounded Latency Information Extension Header (BLIEH) and shown
in Figure 6.NH: 8-bit indicator for the Next Header. This field identifies
the type of the EH immediately following this EH.HLEN: 8-bit unsigned integer for the Extension Header Length in
4-octet units, not including the first 4 octets.EXT: 8-bit optional type extension.The encapsulation of bounded latency information in MPLS extension
headers with MPLS label stack is shown in the following figure. More
than one BLI can be carried in one Bounded Latency Information
Extension Header (BLIEH).This document describes a DetNet IP encapsulation that includes the
bounded latency information based on the DetNet MPLS over UDP/IP data
plane , i.e., leveraging the MPLS-over-UDP
technology. The bounded latency guarantee capable DetNet IP
encapsulation builds on encapsulating DetNet PW over an IP/UDP tunnel
[RFC7510]. It is noted that the format of MPLS Bounded Latency
Extension Header (BLIEH) after UDP header is the same with the format
of MPLS Bounded Latency Extension Header (BLIEH) defined in section
5.2, as well as without using any MPLS forwarding labels. The
encapsulation of bounded latency information in DetNet Data Plane of
MPLS over UDP/IP is shown in the following figure.IANA is requested to allocate a value of "Destination Options and
Hop-by-Hop Options" under "Internet Protocol Version 6 (IPv6)
Parameters" registry. The suggested value is:IANA is requested to allocate a 8-bit indicator for the Next Header
to the Bounded Latency Extension Header.IANA is requested to define a new subregistry of "Bounded Latency
Information Type" for the "Bounded Latency Information Option" under
"Internet Protocol Version 6 (IPv6) Parameters" registry.This new subregistry will include the following registries:TBDThe following examples are provided to give instructions on how
Bounded Latency Information is used when network node implements
different algorithms to guarantee the bounded latency transmission.When network node implements cycle based algorithms for example
,
cycles are the local resources used to guarantee the bounded latency
transmission. Cycle ID is expected to be carried in data plane. Thus,
the data field of BLI is suggested as follows:When network node implements time slot based algorithms, time slots
are the local resources used to guarantee the bounded latency
transmission. Time Slot ID is expected to be carried in data plane.
Thus, the data field of BLI is suggested as follows:When network node implements the budget based algorithms to provide
bounded latency transmission, end to end or per hop delay budget or
delay variation budget information is the requirement proposed from
the services and expected to be carried in data plane. The data fields
of BLI used with delay budget based algorithms are suggested as
follows:The data fields of BLI used with delay variation budget based
algorithms are suggested as follows:When network node implements deadline based algorithms like EDF,
Deadine forwarding to provide
bounded latency transmission, end to end or per hop packet deadline is
the requirement proposed from the services and expected to be carried
in data plane. The data fields of BLI used with deadline based
algorithms are suggested as follows:When network node implements priority based algorithms, priority is
the requirement proposed from the services. Priority ID is expected to
be carried in data plane. The data field of BLI is suggested as
follows: