idnits 2.17.1 draft-bryant-mpls-sfl-control-09.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 (December 07, 2020) is 1235 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 Futurewei Technologies Inc. 4 Intended status: Standards Track G. Swallow 5 Expires: June 10, 2021 Southend Technical Center 6 S. Sivabalan 7 Ciena Corporation 8 December 07, 2020 10 A Simple Control Protocol for MPLS SFLs 11 draft-bryant-mpls-sfl-control-09 13 Abstract 15 In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow 16 labels (SFL) was introduced. This document describes a simple 17 control protocol that runs over an associated control header to 18 request, withdraw, and extend the lifetime of such labels. It is not 19 the only control protocol that moght be used to support SFL, but it 20 has the benefit of being able to be used without modifying of the 21 existing MPLS control prodocols. The existance of this design is not 22 intended to restrict the ability to enhance an existing MPLS control 23 protocol to add a 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 restricctions 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 June 10, 2021. 47 Copyright Notice 49 Copyright (c) 2020 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 [I-D.ietf-mpls-sfl-framework] the concept of MPLS synonymous flow 89 labels (SFL) was introduced. This document describes a simple 90 control protocol, for use in a well-managed MPLS network, that runs 91 over an associated control header to request, withdraw, and extend 92 the lifetime of such labels. It is not the only control protocol 93 that moght be used to support SFL, but it has the benefit of being 94 able to be used without modifying of the existing MPLS control 95 prodocols. The existance of this design is not intended to restrict 96 the ability to enhance an existing MPLS control protocol to add a 97 similar capability. 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. SFL Control 109 EDITOR'S note look at whether we continue to use RFC6374 terms query 110 respond, or normal client server terms. 112 This section describes the process by which the [RFC6374] Querier 113 requests SFLs, the process by which the [RFC6374] Responder sends 114 them to the Querier, and the process for managing the SFL lifetime. 115 SFL Control Messages are carried over the SFL Control ACH. The SFL 116 ACH is carried over a Pseudowire(PW) in place of the PW Control Word 117 (CW), over an MPLS LSP using the GAL, or over some other mutually 118 agreed path. Similarly the response may be returned over a PW, over 119 a bidirectional LSP or over some other mutually agreed path. See 120 Section 4. 122 3.1. SFL Control Message 124 The format of an SFL Control message, which follows the Associated 125 Channel Header (ACH), is as follows: 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 |Version| Flags | Control Code | Message Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Session Identifier | SFL Batch | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Lifetime (seconds) | Num SFL | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | SFL 0 | LFlags | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 . . 139 . . 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | SFL n | LFlags | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Forwarding Equivalence Class (FEC) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: SFL Control Message Format 148 Reserved fields MUST be set to 0 and ignored upon receipt. The 149 possible values for the remaining fields are as follows: 151 Version Protocol version. Set to zero in this specification. 153 Flags Message control flags. 155 Control Code Code identifying the query or response type. 157 Message Length Total length of this message in bytes. 159 Session Identifier Set arbitrarily by the querier and used as a 160 message handle. 162 SFL Batch (6 bits) Used where the SFLs for this Session 163 Identifier are managed across multiple SFL Control 164 Messages. A given set of SFLs MUST be retained 165 in the same batch. 167 Lifetime The lifetime in seconds of the SFLs in this message. 168 In a Query message it is the requested lifetime. 169 In a Response message it is the lifetime that the 170 SFLs have been allocated for by the Responder. 171 The Querier MUST NOT use an SFL after expiry of 172 its lifetime, a Responder MUST make the SFL 173 available for at least its lifetime. 175 Num SFL The number of SFLs in this SFL Batch. This MUST be 176 constant for the lifetime of the batch. 178 SFL n The n'th SFL carried in this TLV. This is an MPLS 179 label which is a component of a label stack entry as 180 defined in Section 2.1 of [RFC3032]. The position 181 of a label within a batch is constant for the 182 lifetime of the batch. Enumeration starts at zero. 184 LFlags The set of flags associated with the immediately 185 preceding SFL. See below. 187 FEC The Forwarding Equivalence Class that the SFLs in 188 this TLV correspond to. This is encoded as per 189 Section 3.4.1 of [RFC5036]. 191 Flags: The format of the Flags field is shown below. 193 +-+-+-+-+ 194 |R|0|0|0| 195 +-+-+-+-+ 197 SFL Control Message Flags. 199 The meanings of the flag bits are: 201 R: Query/Response indicator. Set to 0 for a Query and set 202 to 1 for a Response. 204 0: Set to zero by the Sender and ignored by the Receiver. 206 Control Code: Set as follows according to whether the message is a 207 Query or a Response as identified by the R flag. 209 For a Query: 211 0x0: SFL Request. This indicates that the responder is requested 212 to allocate the set of SFLs marked with the R LFlag in this 213 message. 215 0x1: SFL Refresh. This indicates that the responder is requested 216 to refresh the set of SFLs marked with the V LFlag in this message. 218 0x2: SFL Withdraw. This indicates that the querier will no longer 219 use the set of SFLs marked with the V Lflag and the responder 220 may expire their lifetime. 222 For a Response: 224 Codes 0x0-0xF are reserved for non-error responses. 226 0x1: SFL Grant. This indicates that the responder allocated the 227 set of SFLs marked with the A LFlag in this Message. 229 0x2: SFL Refresh-Ack. This indicates that the responder has 230 refreshed the set of SFLs marked with the V LFlag in this message, 231 and the lifetime is now as indicated by the lifetime field. 233 0x3: SFL Withdraw-Ack. This indicates that the responder has 234 received the Withdraw message and will withdraw the SFLs 236 0x10: Unspecified Error. Indicates that the operation 237 failed for an unspecified reason. 239 0x11: SFL-Unable. The Responder was unable to satisfy the SFL 240 Request. The details of the failure can be determined by 241 comparing the Request and Grant messages. 243 Editors Note - We need to revisit the RFC6374 errors and the protocol 244 to see if we need some more error codes. 246 The LFlags field is defined as follows: 248 0 1 249 0 1 2 3 4 5 6 7 8 9 0 1 250 +-+-+-+-+-+-+-+-+-+-+-+-+ 251 |0|1|2|3| MBZ | 252 +-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 2: LFlags Bit Definition 256 Where: 258 0 (Valid (V)) The Label value of the corresponding SFL is valid. 259 In an SFL Request setting the V Lflag indicates a 260 request for the specified label value. Where an 261 SFL has a valid flag clear in a request message 262 this indicates that any SFL value is acceptable. 264 1 (Request (R)) Indicates to the Querier that this member of the 265 SFL batch is requested. Where a value is specified 266 in the request, but the Responder is unable honour 267 that request, no SFL is allocated and the 268 corresponding A flag MUST be cleared. 270 2 (Allocated (A) Indicates to the Querier that this SFL was 271 allocated. 273 3 (Withdraw (W)) Indicates to the Responder that this SFL is to be 274 withdrawn and to the Querier that the withdrawal has 275 been carried out. 277 MBZ MUST be sent as zero and ignored on receive. 279 A flag value of one is true/set and a flag value of zero is false/ 280 clear. The use of these bits is described in more detail in the 281 following sub-sections. 283 3.2. SFL Control Procedures 285 3.2.1. Request/Grant 287 To request a batch of SFLs the Querier constructs an SFL Control 288 Request, encapsulates it in an SFL Control ACH and sends it to the 289 Responder via an appropriate path. The Querier sets the Control 290 Message Flag to Query and the Control Code to Request. The Querier 291 chooses a session identifier as a handle for this transaction and as 292 a way of binding this batch of SFLs to other operations that will use 293 members of this SFL batch. Since members of the batch are treated as 294 a group, the SFL Batch identifier is used to identify different SFL 295 batches used in conjunction with the same session identifier. 297 The Querier sets the requested lifetime. This is the number of 298 seconds from the time of the query to the time when the batch of SFLs 299 will expire unless refreshed. 301 The Num SFL field is set to the SFL batch size. 303 Each SFL is set as follows: if a specific value is requested (for 304 example for continuity across system restarts) this is written into 305 the SFL n field and the V LFlag set. Otherwise, and including spare 306 SFLs where an allocation is not requested, the label value is set to 307 zero and the V LFlag is cleared. For each SFL entry where an 308 allocation is requested the R LFlag is set. All other LFlags are 309 cleared. 311 The Forwarding Equivalence Class (FEC) is set to the FEC for which 312 the SFLs are requested. 314 The Message Length is determined and filled in. 316 The Responder proceeds as follows: 318 The Responder sets the control Message Flag to Response and initially 319 sets the Control Code to Grant. 321 For each SFL with an R flag set, the Responder determines whether it 322 can honour the request, if so sets the A Lflag, and if the SFL value 323 in the query was zero it overwrites it with the allocated SFL label 324 value. In all other cases it leaves the SFL value and LFlag 325 unchanged. 327 The lifetime field is updated with the lifetime of the SFLs if this 328 is different from the requested lifetime. 330 All other fields in the Query message are left unchanged and the 331 message is sent back to the Querier using the signaled or previously 332 agreed message path. 334 Where the offered lifetime is other than the requested lifetime the 335 Querier may accept the proposed value, or withdraw the SFLs and 336 attempt to negotiate a new set of SFLs with a different lifetime. 338 If the Responder is unable to allocate all of the requested SFLs it 339 MUST respond with a response code of SFL-Unable. The Querier MUST 340 determine whether the allocated SFLs were adequate for its purposes 341 and MUST send a withdraw if there are not adequate. A Querier MUST 342 NOT attempt to hoard labels in the hope that the residual labels 343 needed may become available in the future. 345 A Querier MUST wait a configured time (suggested wait of 60 seconds) 346 before re-attempting negotiation for a resource. Any failure to 347 negotiate the required resources MUST be notified through the 348 management interface of both Querier and Responder. 350 A Querier MUST NOT send an expired SFL to a Responder since to do so 351 may invalidate another SFL operation. 353 3.2.2. Refresh 355 To request the lifetime refresh of a batch of SFLs the Querier 356 constructs an SFL Refresh Request, encapsulates it in an SFL Control 357 ACH and sends it to the Responder via an appropriate path. The 358 Querier sets the Control Message Flag to Query and the Control Code 359 to Refresh. The Querier uses the session identifier and the SFL 360 Batch identifier that it used to request this SFL batch. 362 The Querier sets the requested lifetime. This is the number of 363 seconds from the time of the query to the time when the batch of SFLs 364 will expire unless refreshed. 366 The Querier sets the Num SFL field to the SFL batch size. 368 The Querier sets each SFL as follows: the allocated SFL label value 369 is written into the SFL n field and the V LFlag set. All other 370 LFlags are cleared. 372 The Forwarding Equivalence Class (FEC) is set to the FEC for which 373 the SFLs are requested. 375 The Message Length is determined and filled in. 377 The Responder proceeds as follows: 379 The Responder sets the control Message Flag to Response and sets the 380 Control Code to Refresh-Ack. 382 The Responder sets the lifetime to the lifetime of the SFL. 384 All other fields in the Query message are left unchanged and the 385 message is sent back to the Querier using the signaled or previously 386 agreed message path. 388 Where the offered lifetime is other than the requested lifetime the 389 Querier may accept the proposed value, or withdraw the SFLs and 390 attempt to negotiate a new set of SFLs with a different lifetime. 392 A Querier MUST wait a configured time (suggested wait of 60 seconds) 393 before re-attempting negotiation for a resource. Any failure to 394 negotiate the required resources MUST be notified through the 395 management interface of both Querier and Responder. 397 3.2.3. Withdraw 399 To request the withdrawal of some or all of a batch of SFLs the 400 Querier constructs an SFL Withdraw Request, encapsulates it in an SFL 401 Control ACH and sends it to the Responder via an appropriate path. 402 The Querier sets the Control Message Flag to Query and the Control 403 Code to Withdraw. It uses the session identifier and the SFL Batch 404 identifier that it used to request this SFL batch. 406 The Querier sets the requested lifetime to zero. 408 The Querier sets the Num SFL field to the SFL batch size. 410 Each SFL being withdrawn is set as follows: the allocated SFL label 411 value is written into the SFL n field and the V and W LFlags set. 412 All other LFlags are cleared. 414 The Forwarding Equivalence Class (FEC) is set to the FEC for which 415 the SFLs are requested. 417 The Message Length field is determined and filled in. 419 The Responder proceeds as follows: 421 The Responder sets the control Message Flag to Response and sets the 422 Control Code to Withdraw-Ack. 424 All other fields in the Query message are left unchanged and the 425 message is sent back to the Querier using the signaled or previously 426 agreed message path. 428 A Querier MUST wait a configured time (suggested wait of 60 seconds) 429 before re-attempting a Withdraw request. No more than three Withdraw 430 requests SHOULD be made. These restricctions are to prevent 431 overloading the control plane of the actioning router. 433 3.2.4. Timer Accuracy 435 The lifetime of SFLs is expected to be sufficiently long that there 436 are no significant constraints on timer accuracy. A node should be 437 conservative in its assumptions concerning the lifetime of an SFL. A 438 Querier MUST stop using a SFL significantly before the expiry of its 439 lifetime and a Responder must maintain an SFL in active operation 440 significantly beyond nominal expiry. A margin of the order of 441 minutes is RECOMMENDED. 443 4. Return Path 445 Where the LSP (or other MPLS construct) is multi-point to point, or 446 multi-point to multi- point the RFC6374 Address TLV MUST be included 447 in Query packet, even if the response is requested in-band, since 448 this is needed to provide the necessary return address for this 449 request. 451 EDITIORS NOTE - Look at this text and see if we need to make changes 452 regarding operation over IP. 454 5. Privacy Considerations 456 The inclusion of originating and/or flow information in a packet 457 provides more identity information and hence potentially degrades the 458 privacy of the communication. Whilst the inclusion of the additional 459 granularity does allow greater insight into the flow characteristics 460 it does not specifically identify which node originated the packet 461 other than by inspection of the network at the point of ingress, or 462 inspection of the control protocol packets. This privacy threat may 463 be mitigated by encrypting the control protocol packets, regularly 464 changing the synonymous labels and by concurrently using a number of 465 such labels. 467 6. Security Considerations 469 It is assumed that this protocol is run in a well-managed MPLS 470 network with strict access controls preventing unwanted parties from 471 generating MPLS packets. The control protocol described in this memo 472 thus introduced no additional MPLS security vulnerabilities. 474 7. IANA Considerations 476 7.1. Allocation of MPLS Generalized Associated Channel (G-ACh) Type 478 As per the IANA considerations in [RFC5586], IANA is requested to 479 allocate the following Channel Type in the "MPLS Generalized 480 Associated Channel (G-ACh) Types" registry: 482 Value Description TLV Follows Reference 483 ------ ------------------------------------ ----------- --------- 484 0x0XXX SFL Control No This 486 A value of 0x5A is suggested. 488 7.2. Creation of SFL Simple Control Code Registry 490 IANA is requested to created a new "SFL Simple Control Code" registry 491 within the Generic Associated Channel (G-ACh) Parameters namespace. 492 This registry is divided into two separate parts, one for Query Codes 493 and the other for Response Codes, with formats and initial 494 allocations as follows: 496 Query Codes 498 Code Description Reference 499 ---- ----------------------------------- --------- 500 0x0 SFL Request This 501 0x1 SFL Refresh This 502 0x2 SFL Withdraw This 504 Response Codes 506 Code Description Reference 507 ---- ----------------------------------- --------- 508 0x0 Reserved This 509 0x1 SFL Grant This 510 0x2 SFL Refresh-Ack This 511 0x3 SFL Withdraw-Ack This 512 0x10 Unspecified Error This 513 0x11 SFL-Unable 515 IANA should indicate that the values 0x0 - 0xF in the Response Code 516 section are reserved for non-error response codes. 518 The range of the Code field is 0 - 255. 520 The allocation policy for this registry is IETF Review. 522 8. Acknowledgments 524 The authors thank Haomian Zheng for his review comments. 526 RFC Editor please remove this note which is used to force the 527 following references to appear [RFC3032] [RFC5036] 529 9. References 531 9.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 539 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 540 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 541 . 543 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 544 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 545 October 2007, . 547 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 548 "MPLS Generic Associated Channel", RFC 5586, 549 DOI 10.17487/RFC5586, June 2009, 550 . 552 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 553 Measurement for MPLS Networks", RFC 6374, 554 DOI 10.17487/RFC6374, September 2011, 555 . 557 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 558 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 559 May 2017, . 561 9.2. Informative References 563 [I-D.ietf-mpls-sfl-framework] 564 Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. 565 Mirsky, "Synonymous Flow Label Framework", draft-ietf- 566 mpls-sfl-framework-11 (work in progress), October 2020. 568 Authors' Addresses 570 Stewart Bryant 571 Futurewei Technologies Inc. 573 Email: sb@stewartbryant.com 575 George Swallow 576 Southend Technical Center 578 Email: swallow.ietf@gmail.com 579 Siva Sivabalan 580 Ciena Corporation 582 Email: ssivabal@ciena.com