A Framework for Traffic Engineering in Enhanced DetNet

Introduction As defined in , 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 , 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 , 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. 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. 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 , 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 , 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.

Requirements Language 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.

Terminology This document uses terminology as defined in . It also makes use of the following abbreviations. DD-TE: Differentiated DetNet-aware Traffic Engineering DT: Deterministic Class-Type TRC: Time-based Resources Container

Traffic Engineering for Differentiated DetNet QoS As per , 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 , 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 , 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 , deterministic routes can be established along the constraint-based paths within a Flex-Algorithm topology. As per , deterministic paths can be computed by PCE or a controller with the deterministic latency constraints. As defined in , the BGP flowspec can be used to apply the DetNet flows mapping policy. 2. Path Steering As per , 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 , 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 , 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 . DD-TE can be applied in the TE data plane such as IPv6 , MPLS and SRv6 . 3. Resource Management As per , resource management should support time-based resource-aware control and forwarding including resource reservations and allocations. Time-based resources, as described in , 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.

Layers Model of DD-TE 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 DetNet domain shown is comprised of multiple DetNet nodes (shown as A, B, and C in Figure 1).
The deterministic links are designed to resolve resource competition among different traffic classes and provide deterministic forwarding capabilities at multiple levels.
The deterministic paths are designed to resolve resource competition among different paths within the same traffic class.
The deterministic services are designed to resolve resource competition among different flows on the same path.

Deterministic Links The deterministic links, as defined in , provide one-dimensional deterministic metric to guarantee the deterministic forwarding capabilities at different levels with types indicated by Deterministic Class-Type (DT). 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:

Link ID: an identifier that uniquely identifies a deterministic link within the DetNet domain.
DT type: indicates the class-type level of the deterministic link.
MaxReservedBandwidth: the maximum bandwidth of the deterministic link.
TRC Parameters: carry the TRC ID and the capacity of the time-based resources which are reserved for the link.

Deterministic Paths 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:

Path ID: an identifier that uniquely identifies a deterministic path within the DetNet domain.
DT type: indicates the class-type level of deterministic link.
Source and Destination Nodes: indicate the head and tail address the requested service.
Path Parameters: used to describe the path including the selected deterministic links and other information guiding deterministic forwarding behavior for each hop such as mapping function.
TRC Parameters: carry the TRC ID and the time-based resources which are planned for the path.

Deterministic Services The deterministic services may be configured to map the DetNet flows to the corresponding paths. The deterministic service has the following attributes:

Service ID: an identifier that uniquely identifies a deterministic services within the DetNet domain.
Service Level or Aggregated-class: the indicator of pre-defined service level or aggregated-class based on the service requirement.
Path ID: a selected deterministic path to deliver this service flow.
Policy: indicates the corresponding admission control and traffic policy for this service with the service level on the path.
TRC Parameters: carry the TRC ID and the time-based resources which are allocated for this service level or class.

Considerations for Control Plane of DD-TE 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 , 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 .

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 . 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 .

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 .

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 and the PCEP solution in .

As defined in , 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 , 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 Security considerations for DetNet are covered in the DetNet Architecture and DetNet security considerations . The security considerations specified in are also applicable to the TE extensions described in this document.

IANA Considerations This document makes no requests for IANA action.

Acknowledgements The authors would like to acknowledge Adrian Farrel, Aihua Liu and Bin Tan for their thorough review and very helpful comments.