idnits 2.17.00 (12 Aug 2021) /tmp/idnits18573/draft-xiong-pce-detnet-bounded-latency-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 February 2022) is 82 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8233' is mentioned on line 137, but not defined == Missing Reference: 'IEEE802.1Q-2014' is mentioned on line 252, but not defined == Missing Reference: 'IEEE802.1Qcr' is mentioned on line 253, but not defined == Missing Reference: 'RFC2212' is mentioned on line 256, but not defined == Missing Reference: 'IEEE802.1Qch' is mentioned on line 302, but not defined == Unused Reference: 'RFC4915' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC6549' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 377, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Q. Xiong, Ed. 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track P. Liu 5 Expires: 25 August 2022 China Mobile 6 21 February 2022 8 PCEP Extension for DetNet Bounded Latency 9 draft-xiong-pce-detnet-bounded-latency-00 11 Abstract 13 In certain networks, such as Deterministic Networking (DetNet), it is 14 required to consider the bounded latency for path selection. This 15 document describes the extensions to PCEP to carry bounded latency 16 constraints and distribute deterministic paths for end-to-end path 17 computation in DetNet service. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 25 August 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1.1. End-to-End Bounded Latency Metric . . . . . . . . . . 4 58 3.1.2. End-to-End Bounded Jitter Metric . . . . . . . . . . 4 59 3.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3.1. Queue Information Structure . . . . . . . . . . . . . 5 62 3.3.1.1. Deadline Sub-TLV . . . . . . . . . . . . . . . . 7 63 3.3.1.2. Cycle Sub-TLV . . . . . . . . . . . . . . . . . . 7 64 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 [RFC5440] describes the Path Computation Element Protocol (PCEP) 74 which is used between a Path Computation Element (PCE) and a Path 75 Computation Client (PCC) (or other PCE) to enable computation of 76 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 77 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 78 [RFC8231] describes a set of extensions to PCEP to enable active 79 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. As depicted 80 in [RFC4655], a PCE MUST be able to compute the path of a TE LSP by 81 operating on the TED and considering bandwidth and other constraints 82 applicable to the TE LSP service request. The constraint parameters 83 are provided such as metric, bandwidth, delay, affinity, etc. 84 However these parameters can't meet the DetNet requirements. 86 According to [RFC8655], Deterministic Networking (DetNet) operates at 87 the IP layer and delivers service which provides extremely low data 88 loss rates and bounded latency within a network domain. The bounded 89 latency indicates the minimum and maximum end-to-end latency from 90 source to destination and bounded jitter (packet delay variation). 91 The computing method of end-to-end delay bounds is defined in [draft- 92 ietf-detnet-bounded-latency]. It is the sum of the 6 delays in 93 DetNet bounded latency model. And these delays should be measured 94 and ccollected, but the related mechanisms are out of this document. 95 The end-to-end delay bounds can also be computed as the sum of non 96 queuing delay bound and queuing delay bound along the path. The 97 upper bounds of non queuing delay are constant and depend on the 98 specific network and the value of queuing delay bound depends on the 99 queuing mechanisms deployed along the path. 101 As per [draft-ietf-detnet-controller-plane-framework], explicit path 102 should be calculated and established in control plane to guarantee 103 the deterministic transimission. When the PCE is deployed, the path 104 computation should be applicable for DetNet networks. It is required 105 that bounded latency including minimum and maximum end-to-end latency 106 and bounded delay variation are considered during the deterministic 107 path selection for PCE. The bounded latency constriants should be 108 extended for PCEP. Moreover, the information along the deterministic 109 path should be provided to the PCC after the path conputation such as 110 queuing parameters. 112 This document describes the extensions to PCEP to carry bounded 113 latency constraints and distribute deterministic paths for end-to-end 114 path computation in DetNet service. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2. Terminology 124 The terminology is defined as [RFC8655] and [RFC5440]. 126 3. PCEP Extensions 128 3.1. METRIC Object 130 The METRIC object is defined in Section 7.8 of [RFC5440], comprising 131 metric-value and metric-type (T field), and a flags field, comprising 132 a number of bit flags (B bit and C bit). This document defines two 133 types for the METRIC object. 135 3.1.1. End-to-End Bounded Latency Metric 137 [RFC8233] has proposed the Path Delay metric type of the METRIC 138 object to represent the sum of the Link Delay metric of all links 139 along a P2P path. This document proposes the End-to-End Bounded 140 Latency metric in PCEP to represent the sum of Output delay, Link 141 delay, Frame preemption delay, Processing delay, Regulation delay and 142 Queuing delay as defined in [draft-ietf-detnet-bounded-latency] along 143 a deterministic path. Or the End-to-End Bounded Latency metric can 144 be encoded as the sum of non queuing delay bound and queuing delay 145 bound along the deterministic path. The extensions for End-to-End 146 Bounded Latency Metric are as following shown: 148 * T=TBD1: End-to-End Bounded Latency Metric. 150 * The value of End-to-End Bounded Latency Metric is the encoding in 151 units of microseconds with 32 bits. 153 * The B bit MUST be set to suggest a maximum bound for the end-to- 154 end latency of deterministic path. The end-to-end latency must be 155 less than or equal to the value. 157 A PCC MAY use the End-to-End Bounded Latency metric in a Path 158 Computation Request (PCReq) message to request a deterministic path 159 meeting the end-to-end latency requirement. A PCE MAY use the End- 160 to-End Bounded Latency metric in a Path Computation Reply (PCRep) 161 message along with a NO-PATH object in the case where the PCE cannot 162 compute a path meeting this constraint. A PCE can also use this 163 metric to send the computed end-to-end bounded latency to the PCC. 165 3.1.2. End-to-End Bounded Jitter Metric 167 RFC8233 has proposed the Path Delay Variation metric type of the 168 METRIC object to represent the sum of the Link Delay Variation metric 169 of all links along the path. This document proposes the End-to-end 170 Bounded Jitter metric in PCEP to represent the difference between the 171 end-to-end upper bounded latecny and the end-to-end lower bounded 172 latecny along a deterministic path. The extensions for End-to-End 173 Bounded Jitter Metric are as following shown: 175 * T=TBD2: End-to-End Bounded Jitter Metric. 177 * The value of End-to-End Bounded Jitter Metric is the encoding in 178 units of microseconds with 32 bits. 180 * The B bit MUST be set to suggest a maximum bound for the end-to- 181 end jitter of deterministic path. The end-to-end jitter must be 182 less than or equal to the value. 184 A PCC MAY use the End-to-End Bounded Jitter metric in a PCReq message 185 to request a deterministic path meeting the end-to-end delay 186 variation requirement. A PCE MAY use the End-to-End Bounded Jitter 187 metric in a PCRep message along with a NO-PATH object in the case 188 where the PCE cannot compute a path meeting this constraint. A PCE 189 can also use this metric to send the computed end-to-end bounded 190 Jitter to the PCC. 192 3.2. LSP Object 194 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 195 defiend a new flag (D-flag) to present the deterministic path for the 196 LSP-EXTENDED-FLAG TLV carried in LSP Object as defined in [draft- 197 ietf-pce-lsp-extended-flags]. 199 D (Request for Deterministic Path) : If the bit is set to 1, it 200 indicates that the PCC requests PCE to compute the deterministic 201 path. A PCE would also set this bit to 1 to indicate that the 202 deterministic path is included by PCE and encoded in the PCRep, PCUpd 203 or PCInitiate message. 205 3.3. ERO Object 207 The Explicit Route Object (ERO) is defined in RFC5440 to encode the 208 path of a TE LSP through the network. SR-ERO subobject is used for 209 SR-TE path which consists of one or more SIDs as defined in 210 [RFC8664]. SRV6-ERO subobject is used for SRv6 path as defined in 211 [draft-ietf-pce-segment-routing-ipv6]. This document defines 212 deterministic path information for ERO, SR-ERO and SRv6-ERO 213 subobjects. 215 3.3.1. Queue Information Structure 217 As defined in [draft-ietf-detnet-bounded-latency], the end-to-end 218 delay bounds can be presented as the sum of non queuing delay bound 219 and queuing delay bound along the path. The upper bounds of non 220 queuing delay are constant and depend on the specific network, but 221 the value of queuing delay bound depends on the queuing mechanisms 222 deployed along the deterministic path. So to meet the requirements 223 of the end-to-end delay, the PCE should select a queuing mechanism 224 and configure the related parameters to the PCC. This document 225 proposes the Queuing Information Structure carried in ERO or SR-ERO 226 as shown in Figure 2. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Queuing Identifier | Queuing Algorithm Type | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Queuing Parameters Sub-TLV (variable) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 1: Queuing Information Structure 238 Queuing Identifier (16bits): indicates the unique identifier of a 239 queue for the node forwarding a DetNet flow. 241 Queuing Algorithm Type (16bits): indicates the type of queuing 242 algorithm and each type represents the corresponding queuing 243 mechanisms. The type can be defined refer to the queuing mechanisms 244 which have been discussed such as [draft-ietf-detnet-bounded- 245 latency]. More types can be defined due to the new queuing 246 mechanisms. 248 Queuing Algorithm Type = 1: indicates the Time Aware Shaping 249 [IIEEE802.1Qbv]. 251 Queuing Algorithm Type = 2: indicates the Credit-Based 252 Shaper[IEEE802.1Q-2014] with Asynchronous Traffic 253 Shaping[IEEE802.1Qcr]. 255 Queuing Algorithm Type = 3: indicates the Guaranteed-Service IntServ 256 [RFC2212]. 258 Queuing Algorithm Type = 4: indicates the Cyclic Queuing and 259 Forwarding [IEEE802.1Qch]. 261 Queuing Algorithm Type = 5: indicates the Deadline Based Forwarding 262 [draft-peng-detnet-deadline-based-forwarding]. 264 Queuing Algorithm Type = 6: indicates the Multiple Cyclic Buffers 265 Queuing Mechanism [draft-dang-queuing-with-multiple-cyclic-buffers]. 267 Queuing Parameters Sub-TLV (variable): indicuates the corresponding 268 Queuing Parameters. The current Sub-TLVs including Deadline Sub-TLV 269 and Cycle Sub-TLV are proposed as following sections. 271 3.3.1.1. Deadline Sub-TLV 273 Deadline Sub-TLV is optional for the Queuing Information Structure. 274 The deadline-based queue mechanism has been proposed in [draft-stein- 275 srtsn] and [draft-peng-detnet-deadline-based-forwarding]. The 276 deadlines along the path should be computed at PCE and configured to 277 the PCC, and then inserted into the packet headers. When the Queuing 278 Algorithm Type is set to indicate the deadline-based queuing 279 mechanisms, the Deadline Sub-TLV should be used to carry the deadline 280 parameters. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Deadline | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 2: Deadline Sub-TLV 292 Type (16bits): TBD3, indicates the type of Deadline Sub-TLV. 294 Length (16bits): indicated the length of Deadline Sub-TLV. 296 Deadline (32bits): indicates the deadline time for a node to forward 297 a DetNet flow. 299 3.3.1.2. Cycle Sub-TLV 301 Cycle Sub-TLV is optional for the Queuing Information Structure. The 302 cyclic-based queue mechanism has been proposed in [IEEE802.1Qch] and 303 improved in [draft-dang-queuing-with-multiple-cyclic-buffers]. The 304 clycle along the path should be computed at PCE and configured to the 305 PCC, and then inserted into the packet headers. When the Queuing 306 Algorithm Type is set to indicate the cycle-based queuing mechanisms, 307 the Cycle Sub-TLV should be used to carry the cycle parameters. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Cycle Profile ID | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Cycle ID | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 3: Cycle Sub-TLV 321 Type (16bits): TBD4, indicates the type of Cycle Sub-TLV. 323 Length (16bits): indicated the length of Cycle Sub-TLV. 325 Cycle Profile ID (32bits): indicates the profile ID which the cyclic 326 queue applied at a node. 328 Cycle ID (32bits): indicates the Cycle ID for a node to forward a 329 DetNet flow. 331 4. Acknowledgements 333 TBA 335 5. IANA Considerations 337 TBA 339 6. Security Considerations 341 TBA 343 7. References 345 7.1. Normative References 347 [draft-ietf-pce-lsp-extended-flags] 348 "LSP Extended Flags", July 2021, . 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC4655] "A Path Computation Element (PCE)-Based Architecture", 357 August 2006, . 359 [RFC4915] "Multi-Topology (MT) Routing in OSPF", June 2007, 360 . 362 [RFC5120] "M-ISIS: Multi Topology (MT) Routing in Intermediate 363 System to Intermediate Systems (IS-ISs)", February 2008, 364 . 366 [RFC5440] "Path Computation Element (PCE) Communication Protocol 367 (PCEP)", March 2009, 368 . 370 [RFC6549] "OSPFv2 Multi-Instance Extensions", March 2012, 371 . 373 [RFC7752] "North-Bound Distribution of Link-State and Traffic 374 Engineering (TE) Information Using BGP", March 2016, 375 . 377 [RFC8174] "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 378 Words", May 2017, 379 . 381 [RFC8231] "Path Computation Element Communication Protocol (PCEP) 382 Extensions for Stateful PCE", September 2017, 383 . 385 [RFC8655] "DetNet Architecture", June 2017, 386 . 388 [RFC8664] "SR-PCE", August 2020, 389 . 391 Authors' Addresses 393 Quan Xiong (editor) 394 ZTE Corporation 395 China 396 Email: xiong.quan@zte.com.cn 398 Peng Liu 399 China Mobile 400 Beijing 401 China 402 Email: liupengyjy@chinamobile.com