| Internet-Draft | PCEP Extension for DetNet Bounded Latenc | February 2022 |
| Xiong & Liu | Expires 25 August 2022 | [Page] |
In certain networks, such as Deterministic Networking (DetNet), it is required to consider the bounded latency for path selection. This document describes the extensions to PCEP to carry bounded latency constraints and distribute deterministic paths for end-to-end path computation in DetNet service.¶
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 25 August 2022.¶
Copyright (c) 2022 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.¶
[RFC5440] describes the Path Computation Element Protocol (PCEP) which is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted in [RFC4655], a PCE MUST be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request. The constraint parameters are provided such as metric, bandwidth, delay, affinity, etc. However these parameters can't meet the DetNet requirements.¶
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. The bounded latency indicates the minimum and maximum end-to-end latency from source to destination and bounded jitter (packet delay variation). The computing method of end-to-end delay bounds is defined in [draft-ietf-detnet-bounded-latency]. It is the sum of the 6 delays in DetNet bounded latency model. And these delays should be measured and ccollected, but the related mechanisms are out of this document. The end-to-end delay bounds can also be computed as the sum of non queuing delay bound and queuing delay bound along the path. The upper bounds of non queuing delay are constant and depend on the specific network and the value of queuing delay bound depends on the queuing mechanisms deployed along the path.¶
As per [draft-ietf-detnet-controller-plane-framework], explicit path should be calculated and established in control plane to guarantee the deterministic transimission. When the PCE is deployed, the path computation should be applicable for DetNet networks. It is required that bounded latency including minimum and maximum end-to-end latency and bounded delay variation are considered during the deterministic path selection for PCE. The bounded latency constriants should be extended for PCEP. Moreover, the information along the deterministic path should be provided to the PCC after the path conputation such as queuing parameters.¶
This document describes the extensions to PCEP to carry bounded latency constraints and distribute deterministic paths for end-to-end path computation in DetNet service.¶
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].¶
The METRIC object is defined in Section 7.8 of [RFC5440], comprising metric-value and metric-type (T field), and a flags field, comprising a number of bit flags (B bit and C bit). This document defines two types for the METRIC object.¶
[RFC8233] has proposed the Path Delay metric type of the METRIC object to represent the sum of the Link Delay metric of all links along a P2P path. This document proposes the End-to-End Bounded Latency metric in PCEP to represent the sum of Output delay, Link delay, Frame preemption delay, Processing delay, Regulation delay and Queuing delay as defined in [draft-ietf-detnet-bounded-latency] along a deterministic path. Or the End-to-End Bounded Latency metric can be encoded as the sum of non queuing delay bound and queuing delay bound along the deterministic path. The extensions for End-to-End Bounded Latency Metric are as following shown:¶
A PCC MAY use the End-to-End Bounded Latency metric in a Path Computation Request (PCReq) message to request a deterministic path meeting the end-to-end latency requirement. A PCE MAY use the End-to-End Bounded Latency metric in a Path Computation Reply (PCRep) message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end bounded latency to the PCC.¶
RFC8233 has proposed the Path Delay Variation metric type of the METRIC object to represent the sum of the Link Delay Variation metric of all links along the path. This document proposes the End-to-end Bounded Jitter metric in PCEP to represent the difference between the end-to-end upper bounded latecny and the end-to-end lower bounded latecny along a deterministic path. The extensions for End-to-End Bounded Jitter Metric are as following shown:¶
A PCC MAY use the End-to-End Bounded Jitter metric in a PCReq message to request a deterministic path meeting the end-to-end delay variation requirement. A PCE MAY use the End-to-End Bounded Jitter metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end bounded Jitter to the PCC.¶
The LSP Object is defined in Section 7.3 of [RFC8231]. This document defiend a new flag (D-flag) to present the deterministic path for the LSP-EXTENDED-FLAG TLV carried in LSP Object as defined in [draft-ietf-pce-lsp-extended-flags].¶
D (Request for Deterministic Path) : If the bit is set to 1, it indicates that the PCC requests PCE to compute the deterministic path. A PCE would also set this bit to 1 to indicate that the deterministic path is included by PCE and encoded in the PCRep, PCUpd or PCInitiate message.¶
The Explicit Route Object (ERO) is defined in RFC5440 to encode the path of a TE LSP through the network. SR-ERO subobject is used for SR-TE path which consists of one or more SIDs as defined in [RFC8664]. SRV6-ERO subobject is used for SRv6 path as defined in [draft-ietf-pce-segment-routing-ipv6]. This document defines deterministic path information for ERO, SR-ERO and SRv6-ERO subobjects.¶
As defined in [draft-ietf-detnet-bounded-latency], the end-to-end delay bounds can be presented as the sum of non queuing delay bound and queuing delay bound along the path. The upper bounds of non queuing delay are constant and depend on the specific network, but the value of queuing delay bound depends on the queuing mechanisms deployed along the deterministic path. So to meet the requirements of the end-to-end delay, the PCE should select a queuing mechanism and configure the related parameters to the PCC. This document proposes the Queuing Information Structure carried in ERO or SR-ERO as shown in Figure 2.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Queuing Identifier | Queuing Algorithm Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Queuing Parameters Sub-TLV (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Queuing Identifier (16bits): indicates the unique identifier of a queue for the node forwarding a DetNet flow.¶
Queuing Algorithm Type (16bits): indicates the type of queuing algorithm and each type represents the corresponding queuing mechanisms. The type can be defined refer to the queuing mechanisms which have been discussed such as [draft-ietf-detnet-bounded-latency]. More types can be defined due to the new queuing mechanisms.¶
Queuing Algorithm Type = 1: indicates the Time Aware Shaping [IIEEE802.1Qbv].¶
Queuing Algorithm Type = 2: indicates the Credit-Based Shaper[IEEE802.1Q-2014] with Asynchronous Traffic Shaping[IEEE802.1Qcr].¶
Queuing Algorithm Type = 3: indicates the Guaranteed-Service IntServ [RFC2212].¶
Queuing Algorithm Type = 4: indicates the Cyclic Queuing and Forwarding [IEEE802.1Qch].¶
Queuing Algorithm Type = 5: indicates the Deadline Based Forwarding [draft-peng-detnet-deadline-based-forwarding].¶
Queuing Algorithm Type = 6: indicates the Multiple Cyclic Buffers Queuing Mechanism [draft-dang-queuing-with-multiple-cyclic-buffers].¶
Queuing Parameters Sub-TLV (variable): indicuates the corresponding Queuing Parameters. The current Sub-TLVs including Deadline Sub-TLV and Cycle Sub-TLV are proposed as following sections.¶
Deadline Sub-TLV is optional for the Queuing Information Structure. The deadline-based queue mechanism has been proposed in [draft-stein-srtsn] and [draft-peng-detnet-deadline-based-forwarding]. The deadlines along the path should be computed at PCE and configured to the PCC, and then inserted into the packet headers. When the Queuing Algorithm Type is set to indicate the deadline-based queuing mechanisms, the Deadline Sub-TLV should be used to carry the deadline parameters.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Deadline |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16bits): TBD3, indicates the type of Deadline Sub-TLV.¶
Length (16bits): indicated the length of Deadline Sub-TLV.¶
Deadline (32bits): indicates the deadline time for a node to forward a DetNet flow.¶
Cycle Sub-TLV is optional for the Queuing Information Structure. The cyclic-based queue mechanism has been proposed in [IEEE802.1Qch] and improved in [draft-dang-queuing-with-multiple-cyclic-buffers]. The clycle along the path should be computed at PCE and configured to the PCC, and then inserted into the packet headers. When the Queuing Algorithm Type is set to indicate the cycle-based queuing mechanisms, the Cycle Sub-TLV should be used to carry the cycle parameters.¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cycle Profile ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cycle ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (16bits): TBD4, indicates the type of Cycle Sub-TLV.¶
Length (16bits): indicated the length of Cycle Sub-TLV.¶
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.¶
TBA¶
TBA¶
TBA¶