| Internet-Draft | Abbreviated-Title | April 2023 |
| Zhang, et al. | Expires 25 October 2023 | [Page] |
PCEP is used to provide a communication between a PCC and a PCE. This document defines the extensions to PCEP to support the bounded- latency path computation. Specifically, two new objects and three new TLVs are defined for the transmission of bounded latency information between PCC and PCE to guarantee the bounded latency transmission in control plane.¶
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 25 October 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.¶
[RFC8665] provides the overall architecture for Deterministic Networking (DetNet), which provides the capability to carry specified unicast or multicast data flows with extremely low data loss rates and bounded end-to-end latency within a network domain. Based on this, [draft-finn-detnet-bounded-latency] proposed a timing model for sources, destinations, and DetNet transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods.¶
[RFC5440] describes the Path Computation Element Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. PCEP defines the interaction and data format of path calculation requests and path computation replies between PCC and PCE.[RFC8231] specifies extension to PCEP to enable stateful control of LSPs within and across PCEP sessions in compliance with[RFC4657].[I-D.yzz-detnet-enhanced-data-plane] enhances the DetNet data plane by introducing Bounded Latency Information (BLI) which facilitates DetNet transit nodes to guarantee the bounded latency transmission in data plane. Based on that,[I-D.geng-spring-sr-enhanced-detnet] defines how to leverage Segment Routing (SR) and Segment Routing over IPv6 (SRv6) to implement bounded latency.¶
When a PCE is used to compute paths using PCEP, it is important that the PCE understands the bounded latency requirement and the head end of the path also need to understands the bounded latency information associated with the candidate path.¶
This document defines the extensions to PCEP to support the bounded- latency path computation. Specifically, two new objects and three new TLVs are defined for the transmission of bounded latency information between PCC and PCE to guarantee the bounded latency transmission in control plane.¶
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[RFC2119].¶
[RFC5440] defines the Open object in open message used to specify the PCEP version, Keepalive frequency, DeadTimer, PCEP session ID, and other communication parameters. The Open object may also contain a set of TLVs used to convey various session characteristics.¶
During the PCEP initialization phase, PCEP speakers SHOULD advertise their support of Bounded Latency features, for this reason this document defines the Bounded Latency capability TLV.¶
A PCEP speaker includes the Bounded Latency capability TLV in the Open object to advertise its support for Bounded Latency features. The format of the Bounded Latency capability TLV is formatted as follows:¶
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=TBD1 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Type: To be assigned by IANA.¶
Length: 16 bits value to indicate the length of the value portion in bytes.¶
Type-Flag: 16 bits of flags to indicate which kind of BLI Type the speaker supports. A new registry “Bounded Latency Type Flags” is expected to be created. Table 1 shows the assignment of Bounded Latency Type Flags. The speaker sets the defined bit in flag to indicate that it supports this Type of BLI. The undefined bits MUST be set to zero by the sender and MUST be ignored by the receiver.¶
+----------------+---------------------------------------+---------------------------------------+ | Bit | BLI Type | BLI Format | +----------------+---------------------------------------+---------------------------------------+ | 0 | Reserved | Undefined | +----------------+---------------------------------------+---------------------------------------+ | 1 | Time resource ID | 32-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 2 | Priority | 8-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 3 | End-to-end delay budget | 32-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 4 | Local delay budget | 32-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 5 | Reserved | Undefined | +----------------+---------------------------------------+---------------------------------------+ | 6 | Reserved | Undefined | +----------------+---------------------------------------+---------------------------------------+ | 7 | End-to-end delay variation budget | 16-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 8 | Local delay variation budget | 16-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 9-15 | Undefined | Undefined | +----------------+---------------------------------------+---------------------------------------+¶
Table1: The BLI type and format of each bit flag¶
The RP (Request Parameters) object is defined in[RFC5440], used to specify various characteristics of the path computation request and MUST be carried within each PCReq and PCRep messages. The format of RP object is as follows:¶
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 |O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The detail information about the fields in the RP object is defined in section 7.4 of[RFC5440].¶
In order to specify the type and format of the BLI associated with candidate path, this document defines a new TLV named BLI type TLV. The BLI type TLV is formatted 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD2 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLI Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Type: to be assigned by IANA.¶
Length: 16 bits value to indicate the length of the value portion in bytes. The value of this field is 4.¶
BLI Type: 8 bits value to indicate the type of BLI that PCC desires. Table 3 shows the values and their corresponding BLI types.¶
+----------------+---------------------------------------+---------------------------------------+ | BLI Type Value | Bounded Latency Information | Format | +----------------+---------------------------------------+---------------------------------------+ | 0 | Reserved | Undefined | +----------------+---------------------------------------+---------------------------------------+ | 1 | Time resource ID | 32-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 2 | Priority | 8-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 3 | End-to-end delay variation budget | 16-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 4 | Local delay budget | 32-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 5 | End-to-end queue delay budget | 32-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+ | 6 | Local queue delay budget | 32-bit unsigned Integer | +----------------+---------------------------------------+---------------------------------------+¶
Table2: The BLI type and format of each value¶
When PCC needs to request a bounded-latency path, it MUST include the BLI Type TLV in the RP object in PCReq message. If a PCC includes an BLI Type TLV on a path calculation request, then the PCE will reply the specific type of BLI associated with computed path.¶
The Traffic Model Object is optional in the PCReq message and used to specify the traffic model for the bounded-latency path computation. The traffic model object contains a set of fields used to specify the traffic features.[RFC9016] defines the traffic specification of the DetNet flow, which includes a set of attributes to specify how the DetNet Ingress transmits packets for the DetNet flow. Based on that, this document proposes the Traffic Model Object to describe the DetNet flow for bounded-latency path computation.¶
Traffic Model Object-Class is TBD3;¶
Traffic Model Object-Type is 1.¶
The format of the Traffic Model Object is shown in below:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic ID | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinPacketsPerInterval | MaxPacketsPerInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinPayloadSize | MaxPayloadSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinBandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxLatency | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxLatencyVariation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Traffic ID: The only identification of the specify traffic in PCC. When the PCC need to request a path computation for a traffic, it MUST assign a 16-bit traffic identifier to specify the traffic in local.¶
Flags: 16 bits of flags. A new registry “Traffic Model Flags” is expected to be created. At the writing time, all flags are unused and undefined.¶
MinPacketsPerInterval: the minimum number of packets that the Ingress will transmit in one Interval.¶
MaxPacketsPerInterval: the maximum number of packets that the Ingress will transmit in one Interval.¶
MinPayloadSize: the minimum payload size that the Ingress will transmit.¶
MaxPayloadSize: the maximum payload size that the Ingress will transmit.¶
Interval: the period of time in which the traffic specification is specified.¶
MinBandwith: the minimum bandwidth that has to be guaranteed for the DetNet traffic.¶
MaxLatency: the end-to-end maximum latency for a single packet of the DetNet traffic.¶
MaxLatencyVariation: the difference between the minimum and the maximum end-to-end, one-way latency.¶
The Traffic Model object body has a variable length and may contain TLVs for the additional attributes of the traffic model. At the writing time there is no TLV defined for Traffic Mode Object.¶
In order to support the bounded-latency path computation, a new kind of object named BLI object is defined in this document to indicate the bounded latency information of a candidate path.¶
The BLI object is optionally carried within a PCRep message so as to indicate the requirement and resource allocation for the candidate path. When a PCC request a bounded-latency path computation and the PCE find out a path satisfying the set of constraints, the PCE MUST include the BLI object in PCRep message.¶
BLI Object-Class is TBD4.¶
BLI Object-Type is 1.¶
The format of BLI object is as follows:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The BLI object body has a variable length and may contain TLVs for the different kinds of BLI. This document defines two kinds of BLI TLV for different scenarios.¶
When all of the nodes in the Explicit Route Object (ERO)[RFC5440] request different BLI to guarantee bounded latency, a BLI list TLV is defined.¶
The BLI list sub-TLV is formatted as follows.¶
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=TBD5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLI List [m] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLI List [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Type: to be assigned by IANA.¶
Length: 16 bits length value to indicate the length of BLI list in octet.¶
BLI List [1… m]: 32 bits length bounded latency information, representing the nth BLI in the BLI list.¶
The BLI in the BLI List corresponds to the node in the ERO object one by one. The length of the BLI List depends on the number of nodes in the ERO object.¶
When all of the nodes in the ERO indicated by the sub-object list request BLI to guarantee bounded latency with the same BLI value, the Shared BLI TLV is defined.¶
The Shared BLI TLV is defined as follows:¶
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=TBD6 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Where:¶
Type: to be assigned by IANA.¶
Length: 16 bits value to indicate the length of BLI in octet.¶
BLI: 32 bits value of Bounded Latency Information to guarantee the bounded latency.¶
[I-D.ietf-pce-segment-routing-policy-cp] proposes extension to PCEP to support association among candidate paths of a given SR policy. For the bounded latency path, the additional bounded latency information associated with the candidate path SHOULD be carried with SR Policy. Therefore, the additional BLI TLV SHOULD be defined to indicate the bounded-latency requirement and resources allocation for the nodes along the candidate path. For different scenario, different BLI TLV need to be carried by SR policy.¶
When all of the nodes/adjacencies in the explicit path indicated by the segment list request different BLI to guarantee bounded latency, a BLI list TLV is need to be carried by SR Policy. The BLI list TLV is defined in section 3.4.1.¶
When all of the nodes/adjacencies in the explicit path indicated by the segment list request BLI to guarantee bounded latency with the same BLI value, a Shared BLI TLV is need to be carried by SR Policy. The Shared BLI TLV is defined in section 3.4.2.¶
This document defines four new TLVs and two new Object.¶
+-----------------+---------------------------------+----------------+ | Value | Name | Reference | +-----------------+---------------------------------+----------------+ | TBD1 | Bounded-Latency Capability TLV | This document | +-----------------+---------------------------------+----------------+ | TBD2 | BLI Type TLV | This document | +-----------------+---------------------------------+----------------+ | TBD5 | BLI list TLV | This document | +-----------------+---------------------------------+----------------+ | TBD6 | Shared BLI TLV | This document | +-----------------+---------------------------------+----------------+¶
IANA is requested to make the assignment from the “PCEP Object” sub-registry as follows:¶
+-----------------+---------------------------------+----------------+ | Value | Name | Reference | +-----------------+---------------------------------+----------------+ | TBD3 | Traffic Model Object | This document | +-----------------+---------------------------------+----------------+ | TBD4 | BLI Object | This document | +-----------------+---------------------------------+----------------+¶
TBD¶