idnits 2.17.1 draft-ietf-mpls-sfl-control-02.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 21, 2022) is 826 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Bryant 3 Internet-Draft University of Surrey 4 Intended status: Standards Track G. Swallow 5 Expires: July 25, 2022 Southend Technical Center 6 S. Sivabalan 7 Ciena Corporation 8 January 21, 2022 10 A Simple Control Protocol for MPLS SFLs 11 draft-ietf-mpls-sfl-control-02 13 Abstract 15 In RFC 8957 the concept of MPLS synonymos flow labels (SFL) was 16 introduced. This document describes a simple control protocol that 17 runs over an associated control header to request, withdraw, and 18 extend the lifetime of such labels. It is not the only control 19 protocol that might be used to support SFL, but it has the benefit of 20 being able to be used without modifying of the existing MPLS control 21 protocols. The existence of this design is not intended to restrict 22 the ability to enhance an existing MPLS control protocol to add a 23 similar capability. 25 A Querier MUST wait a configured time (suggested wait of 60 seconds) 26 before re-attempting a Withdraw request. No more than three Withdraw 27 requests SHOULD be made. These restrictions are to prevent 28 overloading the control plane of the actioning router. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 25, 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. SFL Control . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. SFL Control Message . . . . . . . . . . . . . . . . . . . 3 68 3.2. SFL Control Procedures . . . . . . . . . . . . . . . . . 7 69 3.2.1. Request/Grant . . . . . . . . . . . . . . . . . . . . 7 70 3.2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.2.3. Withdraw . . . . . . . . . . . . . . . . . . . . . . 10 72 3.2.4. Timer Accuracy . . . . . . . . . . . . . . . . . . . 10 73 4. Return Path . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Allocation of MPLS Generalized Associated Channel (G-ACh) 78 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.2. Creation of SFL Simple Control Code Registry . . . . . . 12 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 In [RFC8957] the concept of MPLS synonymous flow labels (SFL) was 89 introduced. 91 This document describes a simple control protocol, that runs over an 92 associated control header to request, withdraw, and extend the 93 lifetime of such labels. This protocol is designed for use in a 94 well-managed MPLS network It is not the only control protocol that 95 might be used to support SFL, but it has the benefit of being able to 96 be used without modifying of the existing MPLS control prodocols. 97 The existance of this design is not intended to restrict the ability 98 to enhance an existing MPLS control protocol to add a similar 99 capability. 101 2. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. SFL Control 111 This document uses the terminology standardized in [RFC6374] which it 112 is assumed that the reader is familiar with. 114 This section describes the process by which the [RFC6374] Querier 115 requests SFLs, the process by which the [RFC6374] Responder sends 116 them to the Querier, and the process for managing the SFL lifetime. 117 SFL Control Messages are carried over the Generalized Associated 118 Channel (GAcH), and are identified by a new Associated Channel Header 119 (ACH), allocated by this document. The SFL ACH is carried over a 120 Pseudowire(PW) in place of the PW Control Word (CW), over an MPLS LSP 121 using the GAL, or over some other mutually agreed path. Similarly 122 the response may be returned over a PW, over a bidirectional LSP or 123 over some other mutually agreed path. See Section 4. 125 3.1. SFL Control Message 127 The format of an SFL Control message, which follows the ACH, is as 128 follows: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |Version| Flags | Control Code | Message Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Session Identifier | SFL Batch | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Lifetime (seconds) | Num-SFL | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | SFL 0 | LFlags | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 . . 142 . . 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | SFL n | LFlags | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Forwarding Equivalence Class (FEC) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1: SFL Control Message Format 151 The values for the fields are as follows: 153 Version Protocol version. Set to zero in this specification. 155 Flags Message control flags. 157 Control Code Code identifying the query or response type. 159 Message Length Total length of this message in bytes. 161 Session Identifier Set arbitrarily by the querier and used as a 162 message handle. 164 SFL Batch (6 bits) Used where the SFLs for this Session 165 Identifier are managed across multiple SFL Control 166 Messages. A given set of SFLs MUST be retained 167 in the same batch. 169 Lifetime The lifetime in seconds of the SFLs in this message. 170 In a Query message it is the requested lifetime. 171 In a Response message it is the lifetime that the 172 SFLs have been allocated for by the Responder. 173 The Querier MUST NOT use an SFL after expiry of 174 its lifetime, a Responder MUST make the SFL 175 available for at least its lifetime. 177 Num-SFL The number of SFLs in this SFL Batch. This MUST be 178 constant for the lifetime of the batch. 180 SFL n The n'th SFL carried in this TLV. This is an MPLS 181 label which is a component of a label stack entry as 182 defined in Section 2.1 of [RFC3032]. The position 183 of a label within a batch is constant for the 184 lifetime of the batch. Enumeration starts at zero. 186 LFlags The set of flags associated with the immediately 187 preceding SFL. See below. 189 FEC The Forwarding Equivalence Class that the SFLs in 190 this TLV correspond to. This is encoded as per 191 Section 3.4.1 of [RFC5036]. 193 Flags: The format of the Flags field is shown below. 195 +-+-+-+-+ 196 |R|0|0|0| 197 +-+-+-+-+ 199 SFL Control Message Flags. 201 The meanings of the flag bits are: 203 R: Query/Response indicator. Set to 0 for a Query and set 204 to 1 for a Response. 206 0: Set to zero by the Sender and ignored by the Receiver. 208 Control Code: Set as follows according to whether the message is a 209 Query or a Response as identified by the R flag. 211 For a Query: 213 0x0: SFL Request. This indicates that the responder is requested 214 to allocate the set of SFLs marked with the R LFlag in this 215 message. 217 0x1: SFL Refresh. This indicates that the responder is requested 218 to refresh the set of SFLs marked with the V LFlag in this message. 220 0x2: SFL Withdraw. This indicates that the querier will no longer 221 use the set of SFLs marked with the V Lflag and the responder 222 may expire their lifetime. 224 For a Response: 226 Codes 0x0-0xF are reserved for non-error responses. 228 0x1: SFL Grant. This indicates that the responder allocated the 229 set of SFLs marked with the A LFlag in this Message. 231 0x2: SFL Refresh-Ack. This indicates that the responder has 232 refreshed the set of SFLs marked with the V LFlag in this message, 233 and the lifetime is now as indicated by the lifetime field. 235 0x3: SFL Withdraw-Ack. This indicates that the responder has 236 received the Withdraw message and will withdraw the SFLs 238 0x10: Unspecified Error. Indicates that the operation 239 failed for an unspecified reason. 241 0x11: SFL-Unable. The Responder was unable to satisfy the SFL 242 Request. The details of the failure can be determined by 243 comparing the Request and Grant messages. 245 Editors Note - We need to revisit the RFC6374 errors and the protocol 246 to see if we need some more error codes. 248 The LFlags field is defined as follows: 250 0 1 251 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+ 253 |0|1|2|3| MBZ | 254 +-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 2: LFlags Bit Definition 258 Where: 260 0 (Valid (V)) The Label value of the corresponding SFL is valid. 261 In an SFL Request setting the V Lflag indicates a 262 request for the specified label value. Where an 263 SFL has a valid flag clear in a request message 264 this indicates that any SFL value is acceptable. 266 1 (Request (R)) Indicates to the Querier that this member of the 267 SFL batch is requested. Where a value is specified 268 in the request, but the Responder is unable honour 269 that request, no SFL is allocated and the 270 corresponding A flag MUST be cleared. 272 2 (Allocated (A) Indicates to the Querier that this SFL was 273 allocated. 275 3 (Withdraw (W)) Indicates to the Responder that this SFL is to be 276 withdrawn and to the Querier that the withdrawal has 277 been carried out. 279 MBZ MUST be sent as zero and ignored on receive. 281 A flag value of one is true/set and a flag value of zero is false/ 282 clear. The use of these bits is described in more detail in the 283 following sub-sections. 285 3.2. SFL Control Procedures 287 3.2.1. Request/Grant 289 To request a batch of SFLs the Querier constructs an SFL Control 290 Request, encapsulates it in an SFL Control ACH and sends it to the 291 Responder via an appropriate path. The Querier sets the Control 292 Message Flag to Query and the Control Code to Request. The Querier 293 chooses a session identifier as a handle for this transaction and as 294 a way of binding this batch of SFLs to other operations that will use 295 members of this SFL batch. Since members of the batch are treated as 296 a group, the SFL Batch identifier is used to identify different SFL 297 batches used in conjunction with the same session identifier. 299 The Querier sets the requested lifetime. This is the number of 300 seconds from the time of the query to the time when the batch of SFLs 301 will expire unless refreshed. 303 The Num-SFL field is set to the SFL batch size. 305 Each SFL is set as follows: if a specific value is requested (for 306 example for continuity across system restarts) this is written into 307 the SFL n field and the V LFlag set. Otherwise, and including spare 308 SFLs where an allocation is not requested, the label value is set to 309 zero and the V LFlag is cleared. For each SFL entry where an 310 allocation is requested the R LFlag is set. All other LFlags are 311 cleared. 313 The Forwarding Equivalence Class (FEC) is set to the FEC for which 314 the SFLs are requested. 316 The Message Length is determined and filled in. 318 The Responder proceeds as follows: 320 The Responder sets the control Message Flag to Response and initially 321 sets the Control Code to Grant. 323 For each SFL with an R flag set, the Responder determines whether it 324 can honour the request. If it can honour the request, it sets the A 325 Lflag, and if the SFL value in the query was zero it overwrites it 326 with the allocated SFL label value. In all other cases it leaves the 327 SFL value and LFlag unchanged. 329 The lifetime field is updated with the lifetime of the SFLs if this 330 is different from the requested lifetime. 332 All other fields in the Query message are left unchanged and the 333 message is sent back to the Querier using the signaled or previously 334 agreed message path. 336 Where the offered lifetime is other than the requested lifetime the 337 Querier may accept the proposed value, or withdraw the SFLs and 338 attempt to negotiate a new set of SFLs with a different lifetime. 340 If the Responder is unable to allocate all of the requested SFLs it 341 MUST respond with a response code of SFL-Unable. The Querier MUST 342 determine whether the allocated SFLs were adequate for its purposes 343 and MUST send a withdraw if there are not adequate. A Querier MUST 344 NOT attempt to hoard labels in the hope that the residual labels 345 needed may become available in the future. 347 A Querier MUST wait a configured time (suggested wait of 60 seconds) 348 before re-attempting negotiation for a resource. Any failure to 349 negotiate the required resources MUST be notified through the 350 management interface of both Querier and Responder. 352 A Querier MUST NOT send an expired SFL to a Responder since to do so 353 may invalidate another SFL operation. 355 3.2.2. Refresh 357 To request the lifetime refresh of a batch of SFLs the Querier 358 constructs an SFL Refresh Request, encapsulates it in an SFL Control 359 ACH and sends it to the Responder via an appropriate path. The 360 Querier sets the Control Message Flag to Query and the Control Code 361 to Refresh. The Querier uses the session identifier and the SFL 362 Batch identifier that it used to request this SFL batch. 364 The Querier sets the requested lifetime. This is the number of 365 seconds from the time of the query to the time when the batch of SFLs 366 will expire unless refreshed. 368 The Querier sets the Num-SFL field to the SFL batch size. 370 The Querier sets each SFL as follows: the allocated SFL label value 371 is written into the SFL n field and the V LFlag set. All other 372 LFlags are cleared. 374 The Forwarding Equivalence Class (FEC) is set to the FEC for which 375 the SFLs are requested. 377 The Message Length is determined and filled in. 379 The Responder proceeds as follows: 381 The Responder sets the control Message Flag to Response and sets the 382 Control Code to Refresh-Ack. 384 The Responder sets the lifetime to the lifetime of the SFL. 386 All other fields in the Query message are left unchanged and the 387 message is sent back to the Querier using the signaled or previously 388 agreed message path. 390 Where the offered lifetime is other than the requested lifetime the 391 Querier may accept the proposed value, or withdraw the SFLs and 392 attempt to negotiate a new set of SFLs with a different lifetime. 394 A Querier MUST wait a configured time (suggested wait of 60 seconds) 395 before re-attempting negotiation for a resource. Any failure to 396 negotiate the required resources MUST be notified through the 397 management interface of both Querier and Responder. 399 3.2.3. Withdraw 401 To request the withdrawal of some or all of a batch of SFLs the 402 Querier constructs an SFL Withdraw Request, encapsulates it in an SFL 403 Control ACH and sends it to the Responder via an appropriate path. 404 The Querier sets the Control Message Flag to Query and the Control 405 Code to Withdraw. It uses the session identifier and the SFL Batch 406 identifier that it used to request this SFL batch. 408 The Querier sets the requested lifetime to zero. 410 The Querier sets the Num-SFL field to the SFL batch size. 412 Each SFL being withdrawn is set as follows: the allocated SFL label 413 value is written into the SFL n field and the V and W LFlags set. 414 All other LFlags are cleared. 416 The Forwarding Equivalence Class (FEC) is set to the FEC for which 417 the SFLs are requested. 419 The Message Length field is determined and filled in. 421 The Responder proceeds as follows: 423 The Responder sets the control Message Flag to Response and sets the 424 Control Code to Withdraw-Ack. 426 All other fields in the Query message are left unchanged and the 427 message is sent back to the Querier using the signaled or previously 428 agreed message path. 430 A Querier MUST wait a configured time (suggested wait of 60 seconds) 431 before re-attempting a Withdraw request. No more than three Withdraw 432 requests SHOULD be made. These restrictions are to prevent 433 overloading the control plane of the actioning router. 435 3.2.4. Timer Accuracy 437 The lifetime of SFLs is expected to be sufficiently long that there 438 are no significant constraints on timer accuracy. A node should be 439 conservative in its assumptions concerning the lifetime of an SFL. A 440 Querier MUST stop using a SFL significantly before the expiry of its 441 lifetime and a Responder must maintain an SFL in active operation 442 significantly beyond nominal expiry. A margin of the order of 443 minutes is RECOMMENDED. 445 4. Return Path 447 Where the LSP (or other MPLS construct) is multi-point to point, or 448 multi-point to multi- point the RFC6374 Address TLV MUST be included 449 in Query packet, even if the response is requested in-band, since 450 this is needed to provide the necessary return address for this 451 request. 453 5. Privacy Considerations 455 The inclusion of originating and/or flow information in a packet 456 provides more identity information and hence potentially degrades the 457 privacy of the communication. Whilst the inclusion of the additional 458 granularity does allow greater insight into the flow characteristics 459 it does not specifically identify which node originated the packet 460 other than by inspection of the network at the point of ingress, or 461 inspection of the control protocol packets. This privacy threat may 462 be mitigated by encrypting the control protocol packets, regularly 463 changing the synonymous labels and by concurrently using a number of 464 such labels. 466 6. Security Considerations 468 It is assumed that this protocol is run in a well-managed MPLS 469 network with strict access controls preventing unwanted parties from 470 generating MPLS packets. The control protocol described in this memo 471 thus introduced no additional MPLS security vulnerabilities. 473 7. IANA Considerations 475 7.1. Allocation of MPLS Generalized Associated Channel (G-ACh) Type 477 As per the IANA considerations in [RFC5586], IANA is requested to 478 allocate the following Channel Type in the "MPLS Generalized 479 Associated Channel (G-ACh) Types" registry: 481 Value Description TLV Follows Reference 482 ------ ------------------------------------ ----------- --------- 483 0x0XXX SFL Control No This 485 A value of 0x5A is suggested. 487 7.2. Creation of SFL Simple Control Code Registry 489 IANA is requested to created a new "SFL Simple Control Code" registry 490 within the Generic Associated Channel (G-ACh) Parameters namespace. 491 This registry is divided into two separate parts, one for Query Codes 492 and the other for Response Codes, with formats and initial 493 allocations as follows: 495 Query Codes 497 Code Description Reference 498 ---- ----------------------------------- --------- 499 0x0 SFL Request This document 500 0x1 SFL Refresh This document 501 0x2 SFL Withdraw This document 503 Response Codes 505 Code Description Reference 506 ---- ----------------------------------- --------- 507 0x0 Reserved This document 508 0x1 SFL Grant This document 509 0x2 SFL Refresh-Ack This document 510 0x3 SFL Withdraw-Ack This document 511 0x10 Unspecified Error This document 512 0x11 SFL-Unable 514 IANA should indicate that the values 0x0 - 0xF in the Response Code 515 section are reserved for non-error response codes. 517 The range of the Code field is 0 - 255. 519 The allocation policy for this registry is IETF Review. 521 8. Acknowledgments 523 The authors thank Haomian Zheng for his review comments. 525 RFC Editor please remove this note which is used to force the 526 following references to appear [RFC3032] [RFC5036] 528 9. References 530 9.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, 534 DOI 10.17487/RFC2119, March 1997, 535 . 537 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 538 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 539 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 540 . 542 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 543 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 544 October 2007, . 546 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 547 "MPLS Generic Associated Channel", RFC 5586, 548 DOI 10.17487/RFC5586, June 2009, 549 . 551 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 552 Measurement for MPLS Networks", RFC 6374, 553 DOI 10.17487/RFC6374, September 2011, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 9.2. Informative References 562 [RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. 563 Mirsky, "Synonymous Flow Label Framework", RFC 8957, 564 DOI 10.17487/RFC8957, January 2021, 565 . 567 Authors' Addresses 569 Stewart Bryant 570 University of Surrey 572 Email: sb@stewartbryant.com 574 George Swallow 575 Southend Technical Center 577 Email: swallow.ietf@gmail.com 578 Siva Sivabalan 579 Ciena Corporation 581 Email: ssivabal@ciena.com