| Internet-Draft | Abbreviated-Title | March 2023 |
| Geng | Expires 14 September 2023 | [Page] |
has introduced the evaluation items for different mechanism and provide guidance for judging whether a cerntain mechasnim could satisfy DetNet Enhancement requirement in order to deploy in layer 3 network.¶
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 RFC 2119 [RFC2119].¶
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 14 September 2023.¶
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.¶
[I-D.ietf-detnet-scaling-requirements] has introduced the evaluation items for different mechanism and provide guidance for judging whether a cerntain mechasnim could satisfy DetNet Enhancement requirement in order to deploy in layer 3 network. This document introduces the Gap Analysis and Solution for DetNet Enhancement Data Plane Encapsulation.¶
DetNet data plane enhancement includes 2 parts: Queuing, Shaping, Scheduling, Preemption and encapsulation.¶
As defined in [RFC8655] , queuing and transmission-selection algorithms allow DetNet mechanisms to compute the latency contribution of each DetNet node to the end-to-end latency, to compute the amount of buffer space required in each DetNet node for each incremental DetNet flow. So it provides the base of bounded latency.¶
IEEE also provide mechansim that could be reused in DetNet Data Plane Enhancment:¶
New mechanisms based on the hardware capability of existing network device are also considered.¶
Different queuing, shaping, scheduling mechanisms request different encapsulation in layer 3.¶
Some of the queuing mechanism, e.g., QoS, L4S, preemption, DetNet traffic is handled differently based on the priority for bounded latency. The existing encapsulation, such as DSCP or ECN in IP header, could be used to differenciate the prioriy.¶
Some of the queuing mechanism, e.g., Qbv, VPN+, DetNet traffic is handled differently based on the flow identification or flow aggregation identification(network slice)for bounded latency. The existing encapsulation, such as DetNet Stream Label in MPLS or 5 tupes in IP , could be used to differenciate the flow or flow aggregation.¶
Some of the queuing mechanism, e.g., Qbv, VPN+, DetNet traffic is handled differently based on the flow identification or flow aggregation identification(network slice)for bounded latency. The existing encapsulation, such as DetNet Stream Label in MPLS or 5 tupes in IP , could be used to differenciate the flow or flow aggregation.¶
This section defined DetNet Data Plane Enhanement Encapsultion based on the analysis result of section 2.¶
New DSCP value or new DSCP meaning could be defined for presenting time information, such as¶
New EXP value of MPLS Lable could be introduced to convey time information.¶
The following option could be defined in IPv6 extension header to convey time information:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Context Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Time Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Option Type: 8-bit identifier of the type of option. The type of VTN option is to be assigned by IANA.¶
Opt Data Len: 8-bit unsigned integer indicates the length of the option Data field of this option, in octets.¶
Flags: 8-bit flags field.¶
Time Information: time slot ID, cycel ID, timestamp, ect.¶
Time Aware SID could be introduced to convey time information, such as[I-D.chen-detnet-sr-based-bounded-latency] and [I-D.geng-srv6-based-bounded-latency].¶
This document makes no request of IANA.¶
Note to RFC Editor: this section may be removed on publication as an RFC.¶
This document does not introduce any new security considerations.¶