| Internet-Draft | A Framework for Traffic Engineering in E | July 2024 |
| Xiong, et al. | Expires 3 January 2025 | [Page] |
Deterministic Networking (DetNet) operates at the IP layer and delivers services which provide extremely low data loss rates and bounded latency within a network domain. DetNet can be seen as a specialized branch of Traffic Engineering. There is a requirement to use DetNet to provide Quality of Service (QoS) in large-scale networks. TE can be a valuable tool to help scale DetNet.¶
This document provides a framework for traffic engineering to achieve DetNet QoS in enhanced DetNet. It provides references to DetNet control plane and data plane enhancements that can be used to deliver DetNet traffic engineering.¶
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 3 January 2025.¶
Copyright (c) 2024 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.¶
As defined in [RFC9522], Traffic Engineering (TE) is mainly focused on the control and optimization of routing and forwarding functions to steer traffic through the network. TE can deal with issues with performance evaluation and performance optimization of operational IP networks and addresses the traffic oriented performance requirements including delay, delay variation, packet loss, and throughput while utilizing network resources. 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 Quality of Service (QoS) includes the bounded latency indicating the minimum and maximum end-to-end latency from source to destination, and bounded jitter (packet delay variation). Three techniques are used by DetNet to provide these qualities of service: service protection, explicit routes, and resource allocation.¶
As per [RFC9522], DetNet can also be seen as a specialized branch of TE. The DetNet forwarding sub-layer provides resource allocations and explicit routes to guarantee bounded latency, using existing TE mechanisms such as SR-TE, MPLS-TE and so on. But the enhancements to DetNet are required to provide the packet treatment for the data plane to achieve DetNet QoS in large-scale networks. [I-D.ietf-detnet-scaling-requirements] has described the technical requirements for a DetNet enhanced data plane including the deterministic latency guarantees. Many variations and extensions of queuing mechanisms have been proposed to resolve the scalability issues in DetNet. [I-D.ietf-detnet-dataplane-taxonomy] has discussed the data plane enhancement solutions in DetNet, and also described the classification criteria and the suitability of the solutions for various services.¶
The existing TE mechanisms for resource allocations and explicit routes are not sufficient for enhanced DetNet. For example, the explicit routes should consider queuing-based information when selecting and distributing the explicit paths. And the resource management should be provisioned including the time-based resource reservations and allocations. The TE mechanisms should consider the queuing-based and time-based resources.¶
Moreover, as per [RFC9522], DetNet is required to maintain per-flow state information and provide resource reservation for individual flows. It should deal with large number of dynamic deterministic flows and large scale network topology in enhanced DetNet. This may be challenging for network operations in large-scale networks even if flow aggregation is supported. In scaling networks, as per [I-D.ietf-detnet-scaling-requirements], an enhanced DetNet should support different levels of co-existed applications with different SLAs requirements. It may require the TE control at traffic-aggregate level than the per-flow or flow-aggregate level. The TE mechanisms in enhanced DetNet should support differentiated DetNet QoS of multiple services while utilizing network resources.¶
There is a requirement to use DetNet to provide QoS guarantees in large-scale networks. TE can be a valuable tool to help scale DetNet. This document provides a framework for traffic engineering to achieve DetNet QoS in enhanced DetNet. It provides references to DetNet control plane and data plane enhancements that can be used to deliver DetNet traffic engineering.¶
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.¶
This document uses terminology as defined in [RFC8655]. It also makes use of the following abbreviations.¶
DD-TE: Differentiated DetNet-aware Traffic Engineering¶
DT: Deterministic Class-Type¶
TRC: Time-based Resources Container¶
As per [RFC9522], DetNet can be viewed as a TE mechanism to achieve DetNet QoS. DetNet performs the per-flow or per-flow-aggregate scheduling in the service sub-layer and uses resource allocations and explicit route mechanisms in the forwarding sub-layer. And DetNet can be applied using existing TE data plane mechanisms such as IP, MPLS-TE and SR-TE.¶
As enhanced DetNet should support different levels of co-existed applications with different SLAs requirements as per [I-D.ietf-detnet-scaling-requirements], this document describes a set of extensions for traffic engineering to achieve differentiated DetNet QoS called Differentiated DetNet-aware Traffic Engineering (DD-TE). DD-TE can be used to achieve multiple classes of deterministic services and optimize the resources utilization in large-scale networks.¶
The key elements required in the DD-TE solution are as follows:¶
1. Policy¶
As per [RFC9522], policy allows for the selection of paths (including next hops) based on information beyond basic reachability. The routing policy, including bounded latency constraint-based routing, can be considered when selecting and distributing the candidate paths. As per [I-D.peng-lsr-flex-algo-deterministic-routing], deterministic routes can be established along the constraint-based paths within a Flex-Algorithm topology. As per [I-D.xiong-pce-detnet-bounded-latency], deterministic paths can be computed by PCE or a controller with the deterministic latency constraints. As defined in [I-D.xiong-idr-detnet-flow-mapping], the BGP flowspec can be used to apply the DetNet flows mapping policy.¶
2. Path Steering¶
As per [RFC9522], path steering is the ability to forward packets using more information than just knowledge of the next hop. Per-flow or per-flow-aggregate scheduling is not applicable since it requires a large amount of control signaling to establish and maintain DetNet flows when there are very many dynamic deterministic flows and a large-scale network topology. As discussed in [I-D.xiong-detnet-flow-aggregation], the individual flows may be aggregated for treatment based on shared service specification with the same aggregated-class levels. So the DD-TE mechanism should use the service level or class-based information to forward packets at traffic-aggregate level instead of the per-flow or per-flow-aggregate level.¶
As per [I-D.ietf-detnet-scaling-requirements], in scaling networks with an enhanced DetNet data plane, the enhancement requirements should be supported to guarantee the bounded latency such as the queuing-based mechanisms and metadata. For example, the deterministic latency information may be provided to forward packets for path steering, such as the DetNet-specific metadata as per [I-D.xiong-detnet-data-fields-edp]. DD-TE can be applied in the TE data plane such as IPv6 [I-D.xiong-detnet-6man-queuing-option], MPLS [I-D.sxg-mpls-mna-deterministic-latency] and SRv6 [I-D.xiong-detnet-spring-srh-extensions].¶
3. Resource Management¶
As per [I-D.xiong-detnet-large-scale-enhancements], resource management should support time-based resource-aware control and forwarding including resource reservations and allocations. Time-based resources, as described in [I-D.xiong-lsr-time-resource], should cover the queuing and scheduling mechanisms based on the capability of end-to-end delay, jitter and packet loss. To guarantee the time-based resources, the DD-TE layers model described in Section 4 may be provided to control resources and avoid conflict between DetNet flows to achieve differentiated DetNet QoS and high resources utilization.¶
The resource control of DD-TE is important to regulate traffic, deliver different levels of services, and alleviate congestion issues to guarantee bounded latency. It needs to resolve competition for network resources between traffic flows belonging to the same service class (intra-class contention resolution) and traffic flows belonging to different classes (inter-class contention resolution).¶
This document describes the layers model for an enhanced DetNet control plane to configure deterministic services to achieve differentiated DetNet QoS. The DetNet TE domains in the control plane can be divided into three layers: deterministic links, deterministic paths, and deterministic services as shown in Figure 1.¶
Deterministic Services:|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
Deterministic Paths: +.............................................>+
+.............................................>+
Deterministic Links: O---------------->O O--------------->O
O---------------->O O--------------->O
O---------------->O O--------------->O
+-----+ +-----+ +-----+
DetNet Domain: | A |--------------| B |--------------| C |
+--+--+ +--+--+ +--+--+
The Layers Model of DD-TE has the following characteristics:¶
The deterministic links, as defined in [I-D.xiong-lsr-deterministic-link], provide one-dimensional deterministic metric to guarantee the deterministic forwarding capabilities at different levels with types indicated by Deterministic Class-Type (DT). [I-D.xiong-lsr-time-resource] has proposed the Time-based Resources Container (TRC) to achieve the time-based resources control for the guarantee of deterministic capabilities.¶
The deterministic link has the following attributes:¶
When DetNet services with different SLA requirements are requested to transmit, one or more deterministic paths may be calculated based on the deterministic links. The deterministic paths may co-existed within the same DT, and the time-based resources should be planned when each path is established.¶
The deterministic path has the following attributes:¶
The deterministic services may be configured to map the DetNet flows to the corresponding paths.¶
The deterministic service has the following attributes:¶
[I-D.ietf-detnet-controller-plane-framework] provides a framework for the DetNet controller plane. This document also describes the considerations for control plane of DD-TE. As shown in Figure 2, the metrics, such as the time-based resources and deterministic links with the DD-TE model will be advertised through IGP across the DetNet domain, and the controller may collect the resources and topology information by BGP-LS. When receiving the service request from users or northbound interface, the controller may perform the deterministic paths planning based on the service requirements and then distribute the results to the DetNet domain by PCEP or NETCONF. The DetNet nodes will establish the deterministic path and related time-based resource allocation based on the configuration from the controller.¶
+----------+
3-Service Request-->|Controller|-->4-Deterministic Path Planning
+---+--+---+
| ^ 2-Topology Information Collection
| |
| |
| |
5-Path Distribution V |
.......................................................
. .
. 1-Resource and Deterministic Links Advertisements .
. .
Flow . +---+ +---+ +---+ .
+---> . | A |------------| B |------------| C | .
| . +---+ +---+ +---+ .
| . DetNet Domain .
| . .
| . 6-Path Establishment and Resource Allocation .
| . .
| .......................................................
|
|-->7-Admision Control and Traffic Policy of Deterministic Service
As described in [I-D.ietf-detnet-scaling-requirements], support for the configuration of multiple queuing mechanisms is required. Different queuing mechanisms may be supported for different levels of latency, jitter, and other guarantees. Enhancements for the control plane should be provided, such as a configuration information model as defined in [I-D.guo-detnet-vpfc-planning].¶
When the type of queuing mechanism and the related queuing-based metadata are configured, the time-based resources which is a combination of bandwidth, buffer and regulators/shapers, queues, and schedulers should be advertised across the DetNet domain as per IGP extension [I-D.xiong-lsr-time-resource]. It also should support time-based resource-aware control and forwarding including resource reservations and allocations. For example, the deterministic links with time-based resources could be distributed by IGP protocol as per [I-D.xiong-lsr-deterministic-link].¶
The deterministic routes may be loose routes in distributed scenarios. Distributed deterministic routes need to be supported as established by distributed protocols such as IGP as defined in [I-D.peng-lsr-flex-algo-deterministic-routing].¶
In scaling deterministic networks, that may across multiple network domains, it is required to support inter-domain deterministic routes to achieve end-to-end latency and bounded jitter requirements. And the deadline of latency and jitter of each domain and segment should be determined and controlled. The inter-domain mechanism must be considered at the boundary nodes such as through BGP configurations as defined in [I-D.peng-idr-bgp-metric-credit] and the PCEP solution in [I-D.bernardos-detnet-multidomain].¶
As defined in [I-D.xiong-pce-detnet-bounded-latency], the deterministic latency constraints can be carried in PCEP extensions and the end-to-end deterministic path computation should be achieved for DetNet service.¶
As defined in [I-D.xiong-idr-detnet-flow-mapping], the BGP flowspec can be used for filtering of the packets that match the DetNet networks and the mapping between Time-Sensitive Networking (TSN) streams and DetNet flows in the control plane.¶
Security considerations for DetNet are covered in the DetNet Architecture [RFC8655] and DetNet security considerations [RFC9055]. The security considerations specified in [RFC9522] are also applicable to the TE extensions described in this document.¶
This document makes no requests for IANA action.¶
The authors would like to acknowledge Adrian Farrel, Aihua Liu and Bin Tan for their thorough review and very helpful comments.¶