| Internet-Draft | Data Fields for DetNet Enhanced Data Pla | July 2023 |
| Xiong, et al. | Expires 11 January 2024 | [Page] |
This document discusses the specific metadata which should be carried in Enhanced Data plane (EDP), proposes the DetNet data fields and option types for EDP such as Deterministic Latency Action Option. DetNet Data-Fields for EDP can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 January 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
According to [RFC8655], Deterministic Networking (DetNet) operates at the IP layer and delivers service which provides extremely low data loss rates and bounded latency within a network domain. DetNet data planes has been specified in [RFC8938]. The existing deterministic technologies are facing large-scale number of nodes and long-distance transmission, traffic scheduling, dynamic flows, and other controversial issues in large-scale networks. The DetNet Enhanced Data plane (EDP) is required to support a data plane method of flow identification and packet treatment. [I-D.ietf-detnet-scaling-requirements]has described the enhancement requirements for DetNet enhanced data plane, such as aggregated flow identification, redundancy, explicit path selection and deterministic latency guarantees. [I-D.xiong-detnet-large-scale-enhancements] has proposed the overall framework of DetNet enhancements for large-scale deterministic networks. The packet treatment should schedule the resources and indicate the behaviour to ensure the deterministic latency. Moreover, new functions and related metadata should be supported in enhanced DetNet.¶
This document discusses the specific metadata which should be carried in Enhanced Data plane (EDP), proposes the DetNet data fields and option types for EDP such as Deterministic Latency Action Option. DetNet Data-Fields for EDP can be encapsulated into a variety of protocols such as MPLS, IPv6 and SRv6 networks.¶
The terminology is defined as [RFC8655], [RFC8938] and [I-D.ietf-detnet-scaling-requirements].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Abbreviations and definitions used in this document:¶
As per [I-D.xiong-detnet-large-scale-enhancements], the queuing-based mechanisms is an important type of resource to ensure the deterministic latency. As described in [RFC9320], the end-to-end bounded latency depends on the value of queuing delay bound along with the queuing mechanisms. Multiple queuing mechanisms can be used to guarantee the bounded latency in DetNet.¶
And many types of queuing mechanisms have been proposed to provide diversified deterministic service for various applications. For example, time-scheduling queuing mechanisms includes the TAS (Time Aware Shaping) [IIEEE802.1Qbv] and priority-scheduling includes the CBS (Credit-Based Shaper)[IEEE802.1Q-2014] with ATS (Asynchronous Traffic Shaping)[IEEE802.1Qcr]. The cyclic-scheduling queuing mechanism has been proposed such as CQF (Cyclic Queuing and Forwarding) in [IEEE802.1Qch] and improved as per multi-CQF [I-D.dang-queuing-with-multiple-cyclic-buffers], T-CQF [I-D.eckert-detnet-tcqf] and CSQF [I-D.chen-detnet-sr-based-bounded-latency]. The deadline-scheduling queuing mechanism has been proposed in [I-D.stein-srtsn] and improved as per Deadline [I-D.peng-detnet-deadline-based-forwarding]. The per-flow queuing mechanism includes Guaranteed-Service Integrated service (IntServ) [RFC2212]. The asynchronous queuing mechanism includes the Asynchronous Deterministic Networking (ADN) as per [I-D.joung-detnet-asynch-detnet-framework] and [I-D.joung-detnet-stateless-fair-queuing]. The Packet Timeslot Mechanism is also proposed as per TQF [I-D.peng-detnet-packet-timeslot-mechanism]. The functions such as the queuing mechanisms should be provided for enhanced DetNet to ensure the deterministic latency.¶
And when queuing mechanisms used in large-scale networks, some queuing parameters should be carried for coordination between nodes so as to make appropriate packet forwarding and scheduling decisions to meet the time bounds. The DetNet forwarding nodes along the path can apply the function and the deterministic latency related information should be carried as metadata in the packet to achieve the end-to-end bounded latency.¶
As per [I-D.xiong-detnet-large-scale-enhancements], DetNet service sub-layer may provide traffic scheduling for multiple DetNet flows to achieve the end-to-end bounded latency with differentiated DetNet QoS. The enhanced DetNet data plane may also encode the traffic class metadata in packets.¶
The DetNet Traffic Class (DC) has been defined to indicate the DetNet traffic class as per [I-D.xiong-detnet-teas-te-extensions], The traffic class information can also reuse the IP DSCP or MPLS TC field.¶
The enhanced functions and related metadata for DetNet EDP should be confirmed before the encapsulations. While more than one metadata should be carried in EDP, the common DetNet header for EDP should be considered to cover all option-types and data.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetNet-Type | DetNet-Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ DetNet Option and Data Space ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DetNet-Type: 8-bit unsigned integer, defining the DetNet Option-type for EDP. This document defines an Option:¶
Deterministic Latency Action Option as defined in section 4.2.¶
DetNet-Length: 8-bit unsigned integer, defined the Length of the DetNet Header for EDP in 4-octet units.¶
The DetNet Deterministic Latency Action (DLA) Option carries data that is added by the DetNet encapsulating node and interpreted by the decapsulating node. The DetNet transit nodes MAY process the data by forwarding the option data determined by option type and may modify it. The DetNet DLA Option consist of a fixed-size "DetNet DLA Option Header" and a variable-size "DetNet DLA Option Data". The Header and Data may be encapsulated continuously or separately. A Data or more than one Data in lists can be carried in packets.¶
DetNet Deterministic Latency Action (DLA) Option header:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLA Type | Data Len | Ancillary Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DLA(Deterministic Latency Action) Type(16 bits): indicates the type of deterministic latency actions for DetNet metadata.¶
The DLA Type can be divided into two parts including behaviour action type and function/queuing type. The format is 16 bits such as 0xFFFF.¶
The DLA Type field is designed as follow:¶
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLA B-type | DLA Q-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DLA B-type(8 bits): indicates the behaviour action type of packet treatment ensuring the deterministic latency as following shown. This type can also indicate the traffic class.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Behaviour Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0000 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0100 | Bandwidth guarantee |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0200 | Jitter guarantee |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0300 | Delay guarantee |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0400 | Low delay and jitter guarantee |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0500 |Ultra-low delay and jitter guarantee |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DLA Q-type(8 bits): indicates the type of queuing-based mechanisms or functions ensuring the deterministic latency and related metadata. For example, the functions such as a particular queuing mechanism may be indicated and related parameters should be provided as section 3.1.2 shown.¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-type| Queuing/Function Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0000 | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0001 | Cycle Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0002 | Deadline Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0003 | Local Deadline Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0004 | Time Slot Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Len: 8-bit unsigned integer. Length of DLA option data, in octets.¶
Ancillary Len: 8-bit unsigned integer. Length of DLA ancillary data, in octets.¶
The types of Deterministic Latency functions should cover all the mechanisms ensuring the Deterministic Latency such as the existing queuing and scheduling mechanisms and other mechanisms which may be proposed in the future.¶
DetNet Deterministic Latency Action option data MUST be aligned by 4 octets:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLA option data field determined by DLA Q-Type (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLA ancillary data field determined by DLA Type (variable)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DLA option data: Variable-length field. It provides function-based or queuing-based information for a node to forward a DetNet flow. The data of which is determined by the DLA Q-type. The examples of different types of queuing-based data is as following sections shown.¶
DLA ancillary data: Variable-length field. It provides additional information for a node to forward a DetNet flow. The data of which is determined by the DLA type.¶
The DetNet option data and Ancillary data can be provided one time or in list.¶
When the Sub-type is set to 0x0001, indicates the Multiple Cyclic Queuing mechanism as defined in [I-D.dang-queuing-with-multiple-cyclic-buffers] and [I-D.chen-detnet-sr-based-bounded-latency]. The Cycle Queuing Data may be carried and designed as following shown:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cycle Profile ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cycle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cycle Profile ID (32bits): indicates the profile ID which the cyclic queue applied at a node.¶
Cycle ID (32bits): indicates the Cycle ID for a node to forward a DetNet flow.¶
When the Sub-type is set to 0x0002, indicates the deadline mechanisms as defined in [I-D.peng-detnet-deadline-based-forwarding]. The Deadline Queuing Data may be carried and designed as follow:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |M|D| Planned Deadline |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accumulated Planned Deadline / Accumulated Deadline Deviation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accumulated Actual Residence Time / Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Planned and deadline Deviation has been provided as defined in [I-D.peng-6man-deadline-option].¶
When the Sub-type is set to 0x0003, indicates the local deadline mechanisms as defined in [I-D.stein-srtsn]. The Local Deadline Queuing Data may be carried and designed as follow:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Deadline |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Deadline: indicates the local deadline as defined in [I-D.stein-srtsn].¶
When the Sub-type is set to 0x0004, indicates the local deadline mechanisms as defined in [I-D.peng-detnet-packet-timeslot-mechanism]. The time-slot information may be carried and designed as follow:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeslot ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Timeslot ID: indicates the identifier of the timeslot as defined in [I-D.peng-detnet-packet-timeslot-mechanism].¶
The packet treatment should indicate the behaviour action ensuring the deterministic latency at DetNet nodes such as queuing-based mechanisms. The deterministic latency action type and related parameters such as queuing-based information should be carried as metadta in data plane. And the definitions may follow these polices.¶
The data plane enhancement must be generic and the format must be applied to all functions and queuing mechanisms. The metadata and definitions should be common among different candidate queuing solutions.¶
Information and metadata MUST be simplified and limited to be carried in DetNet packets for provided deterministic latency related scheduling along the forwarding path. For example, the queuing-based information should be carried in metadata for coordination between nodes.¶
The requirement of the flow or service may be not suitable to be carried explicitly in DetNet data plane. The packet treatment should schedule the resources and indicate the behaviour to ensure the deterministic latency in forwarding sub-layer. So the queuing mechanisms could be viewed as a type of deterministic resources. The resources type and queuing type should be explicitly indicated.¶
Reusing the DSCP or existing field is reasonable and simple to define and easy to standardize. For example, in IPv4 and traditional MPLS networks, it is not suitable to carry new metadata and it is suggested to reuse the original bits such as DSCP [I-D.eckert-detnet-tcqf]. The mapping from DSCP and the metadata such as queuing information MUST be provided in the controller plane.¶
DSCP value may be not sufficient and hard to distinguish between the original DiffServ service and the deterministic service. The DetNet-specific metadata can also be encoded as a common data fields and the definition of data fields is independent from the encapsulating protocols. The data fields could be encapsulated into a variety of protocols, such as MPLS 2.0 [I-D.sx-detnet-mpls-queue], IPv6 [I-D.xiong-detnet-6man-queuing-option], SRv6 [I-D.xiong-detnet-spring-srh-extensions] and so on.¶
TBA¶
TBA¶