idnits 2.17.1 draft-bryant-mpls-sfl-control-07.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 (June 04, 2020) is 1415 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) == Outdated reference: A later version (-11) exists of draft-ietf-mpls-sfl-framework-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 S. Bryant 4 Intended status: Standards Track Futurewei Technologies Inc. 5 Expires: December 6, 2020 G. Swallow 6 Southend Technical Center 7 S. Sivabalan 8 Cisco Systems 9 June 04, 2020 11 A Simple Control Protocol for MPLS SFLs 12 draft-bryant-mpls-sfl-control-07 14 Abstract 16 In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow 17 labels (SFL) was introduced. This document describes a simple 18 control protocol that runs over an associated control header to 19 request, withdraw, and extend the lifetime of such labels. It is not 20 the only control protocol that moght be used to support SFL, but it 21 has the benefit of being able to be used without modifying of the 22 existing MPLS control prodocols. The existance of this design is not 23 intended to restrict the ability to enhance an existing MPLS control 24 protocol to add a similar capability. 26 A Querier MUST wait a configured time (suggested wait of 60 seconds) 27 before re-attempting a Withdraw request. No more than three Withdraw 28 requests SHOULD be made. These restricctions are to prevent 29 overloading the control plane of the actioning router. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 6, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. SFL Control . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. SFL Control Message . . . . . . . . . . . . . . . . . . . 3 69 3.2. SFL Control Procedures . . . . . . . . . . . . . . . . . 7 70 3.2.1. Request/Grant . . . . . . . . . . . . . . . . . . . . 7 71 3.2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2.3. Withdraw . . . . . . . . . . . . . . . . . . . . . . 10 73 3.2.4. Timer Accuracy . . . . . . . . . . . . . . . . . . . 10 74 4. Return Path . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Allocation of MPLS Generalized Associated Channel (G-ACh) 79 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.2. Creation of SFL Simple Control Code Registry . . . . . . 12 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 9.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 In [I-D.ietf-mpls-sfl-framework] the concept of MPLS synonymous flow 90 labels (SFL) was introduced. This document describes a simple 91 control protocol, for use in a well-managed MPLS network, that runs 92 over an associated control header to request, withdraw, and extend 93 the lifetime of such labels. It is not the only control protocol 94 that moght be used to support SFL, but it has the benefit of being 95 able to be used without modifying of the existing MPLS control 96 prodocols. The existance of this design is not intended to restrict 97 the ability to enhance an existing MPLS control protocol to add a 98 similar capability. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 3. SFL Control 110 EDITOR'S note look at whether we continue to use RFC6374 terms query 111 respond, or normal client server terms. 113 This section describes the process by which the [RFC6374] Querier 114 requests SFLs, the process by which the [RFC6374] Responder sends 115 them to the Querier, and the process for managing the SFL lifetime. 116 SFL Control Messages are carried over the SFL Control ACH. The SFL 117 ACH is carried over a Pseudowire(PW) in place of the PW Control Word 118 (CW), over an MPLS LSP using the GAL, or over some other mutually 119 agreed path. Similarly the response may be returned over a PW, over 120 a bidirectional LSP or over some other mutually agreed path. See 121 Section 4. 123 3.1. SFL Control Message 125 The format of an SFL Control message, which follows the Associated 126 Channel Header (ACH), is as follows: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |Version| Flags | Control Code | Message Length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Session Identifier | SFL Batch | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Lifetime (seconds) | Num SFL | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | SFL 0 | LFlags | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 . . 140 . . 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | SFL n | LFlags | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Forwarding Equivalence Class (FEC) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 1: SFL Control Message Format 149 Reserved fields MUST be set to 0 and ignored upon receipt. The 150 possible values for the remaining fields are as follows: 152 Version Protocol version. Set to zero in this specification. 154 Flags Message control flags. 156 Control Code Code identifying the query or response type. 158 Message Length Total length of this message in bytes. 160 Session Identifier Set arbitrarily by the querier and used as a 161 message handle. 163 SFL Batch (6 bits) Used where the SFLs for this Session 164 Identifier are managed across multiple SFL Control 165 Messages. A given set of SFLs MUST be retained 166 in the same batch. 168 Lifetime The lifetime in seconds of the SFLs in this message. 169 In a Query message it is the requested lifetime. 170 In a Response message it is the lifetime that the 171 SFLs have been allocated for by the Responder. 172 The Querier MUST NOT use an SFL after expiry of 173 its lifetime, a Responder MUST make the SFL 174 available for at least its lifetime. 176 Num SFL The number of SFLs in this SFL Batch. This MUST be 177 constant for the lifetime of the batch. 179 SFL n The n'th SFL carried in this TLV. This is an MPLS 180 label which is a component of a label stack entry as 181 defined in Section 2.1 of [RFC3032]. The position 182 of a label within a batch is constant for the 183 lifetime of the batch. Enumeration starts at zero. 185 LFlags The set of flags associated with the immediately 186 preceding SFL. See below. 188 FEC The Forwarding Equivalence Class that the SFLs in 189 this TLV correspond to. This is encoded as per 190 Section 3.4.1 of [RFC5036]. 192 Flags: The format of the Flags field is shown below. 194 +-+-+-+-+ 195 |R|0|0|0| 196 +-+-+-+-+ 198 SFL Control Message Flags. 200 The meanings of the flag bits are: 202 R: Query/Response indicator. Set to 0 for a Query and set 203 to 1 for a Response. 205 0: Set to zero by the Sender and ignored by the Receiver. 207 Control Code: Set as follows according to whether the message is a 208 Query or a Response as identified by the R flag. 210 For a Query: 212 0x0: SFL Request. This indicates that the responder is requested 213 to allocate the set of SFLs marked with the R LFlag in this 214 message. 216 0x1: SFL Refresh. This indicates that the responder is requested 217 to refresh the set of SFLs marked with the V LFlag in this message. 219 0x2: SFL Withdraw. This indicates that the querier will no longer 220 use the set of SFLs marked with the V Lflag and the responder 221 may expire their lifetime. 223 For a Response: 225 Codes 0x0-0xF are reserved for non-error responses. 227 0x1: SFL Grant. This indicates that the responder allocated the 228 set of SFLs marked with the A LFlag in this Message. 230 0x2: SFL Refresh-Ack. This indicates that the responder has 231 refreshed the set of SFLs marked with the V LFlag in this message, 232 and the lifetime is now as indicated by the lifetime field. 234 0x3: SFL Withdraw-Ack. This indicates that the responder has 235 received the Withdraw message and will withdraw the SFLs 237 0x10: Unspecified Error. Indicates that the operation 238 failed for an unspecified reason. 240 0x11: SFL-Unable. The Responder was unable to satisfy the SFL 241 Request. The details of the failure can be determined by 242 comparing the Request and Grant messages. 244 Editors Note - We need to revisit the RFC6374 errors and the protocol 245 to see if we need some more error codes. 247 The LFlags field is defined as follows: 249 0 1 250 0 1 2 3 4 5 6 7 8 9 0 1 251 +-+-+-+-+-+-+-+-+-+-+-+-+ 252 |0|1|2|3| MBZ | 253 +-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 2: LFlags Bit Definition 257 Where: 259 0 (Valid (V)) The Label value of the corresponding SFL is valid. 260 In an SFL Request setting the V Lflag indicates a 261 request for the specified label value. Where an 262 SFL has a valid flag clear in a request message 263 this indicates that any SFL value is acceptable. 265 1 (Request (R)) Indicates to the Querier that this member of the 266 SFL batch is requested. Where a value is specified 267 in the request, but the Responder is unable honour 268 that request, no SFL is allocated and the 269 corresponding A flag MUST be cleared. 271 2 (Allocated (A) Indicates to the Querier that this SFL was 272 allocated. 274 3 (Withdraw (W)) Indicates to the Responder that this SFL is to be 275 withdrawn and to the Querier that the withdrawal has 276 been carried out. 278 MBZ MUST be sent as zero and ignored on receive. 280 A flag value of one is true/set and a flag value of zero is false/ 281 clear. The use of these bits is described in more detail in the 282 following sub-sections. 284 3.2. SFL Control Procedures 286 3.2.1. Request/Grant 288 To request a batch of SFLs the Querier constructs an SFL Control 289 Request, encapsulates it in an SFL Control ACH and sends it to the 290 Responder via an appropriate path. The Querier sets the Control 291 Message Flag to Query and the Control Code to Request. The Querier 292 chooses a session identifier as a handle for this transaction and as 293 a way of binding this batch of SFLs to other operations that will use 294 members of this SFL batch. Since members of the batch are treated as 295 a group, the SFL Batch identifier is used to identify different SFL 296 batches used in conjunction with the same session identifier. 298 The Querier sets the requested lifetime. This is the number of 299 seconds from the time of the query to the time when the batch of SFLs 300 will expire unless refreshed. 302 The Num SFL field is set to the SFL batch size. 304 Each SFL is set as follows: if a specific value is requested (for 305 example for continuity across system restarts) this is written into 306 the SFL n field and the V LFlag set. Otherwise, and including spare 307 SFLs where an allocation is not requested, the label value is set to 308 zero and the V LFlag is cleared. For each SFL entry where an 309 allocation is requested the R LFlag is set. All other LFlags are 310 cleared. 312 The Forwarding Equivalence Class (FEC) is set to the FEC for which 313 the SFLs are requested. 315 The Message Length is determined and filled in. 317 The Responder proceeds as follows: 319 The Responder sets the control Message Flag to Response and initially 320 sets the Control Code to Grant. 322 For each SFL with an R flag set, the Responder determines whether it 323 can honour the request, if so sets the A Lflag, and if the SFL value 324 in the query was zero it overwrites it with the allocated SFL label 325 value. In all other cases it leaves the SFL value and LFlag 326 unchanged. 328 The lifetime field is updated with the lifetime of the SFLs if this 329 is different from the requested lifetime. 331 All other fields in the Query message are left unchanged and the 332 message is sent back to the Querier using the signaled or previously 333 agreed message path. 335 Where the offered lifetime is other than the requested lifetime the 336 Querier may accept the proposed value, or withdraw the SFLs and 337 attempt to negotiate a new set of SFLs with a different lifetime. 339 If the Responder is unable to allocate all of the requested SFLs it 340 MUST respond with a response code of SFL-Unable. The Querier MUST 341 determine whether the allocated SFLs were adequate for its purposes 342 and MUST send a withdraw if there are not adequate. A Querier MUST 343 NOT attempt to hoard labels in the hope that the residual labels 344 needed may become available in the future. 346 A Querier MUST wait a configured time (suggested wait of 60 seconds) 347 before re-attempting negotiation for a resource. Any failure to 348 negotiate the required resources MUST be notified through the 349 management interface of both Querier and Responder. 351 A Querier MUST NOT send an expired SFL to a Responder since to do so 352 may invalidate another SFL operation. 354 3.2.2. Refresh 356 To request the lifetime refresh of a batch of SFLs the Querier 357 constructs an SFL Refresh Request, encapsulates it in an SFL Control 358 ACH and sends it to the Responder via an appropriate path. The 359 Querier sets the Control Message Flag to Query and the Control Code 360 to Refresh. The Querier uses the session identifier and the SFL 361 Batch identifier that it used to request this SFL batch. 363 The Querier sets the requested lifetime. This is the number of 364 seconds from the time of the query to the time when the batch of SFLs 365 will expire unless refreshed. 367 The Querier sets the Num SFL field to the SFL batch size. 369 The Querier sets each SFL as follows: the allocated SFL label value 370 is written into the SFL n field and the V LFlag set. All other 371 LFlags are cleared. 373 The Forwarding Equivalence Class (FEC) is set to the FEC for which 374 the SFLs are requested. 376 The Message Length is determined and filled in. 378 The Responder proceeds as follows: 380 The Responder sets the control Message Flag to Response and sets the 381 Control Code to Refresh-Ack. 383 The Responder sets the lifetime to the lifetime of the SFL. 385 All other fields in the Query message are left unchanged and the 386 message is sent back to the Querier using the signaled or previously 387 agreed message path. 389 Where the offered lifetime is other than the requested lifetime the 390 Querier may accept the proposed value, or withdraw the SFLs and 391 attempt to negotiate a new set of SFLs with a different lifetime. 393 A Querier MUST wait a configured time (suggested wait of 60 seconds) 394 before re-attempting negotiation for a resource. Any failure to 395 negotiate the required resources MUST be notified through the 396 management interface of both Querier and Responder. 398 3.2.3. Withdraw 400 To request the withdrawal of some or all of a batch of SFLs the 401 Querier constructs an SFL Withdraw Request, encapsulates it in an SFL 402 Control ACH and sends it to the Responder via an appropriate path. 403 The Querier sets the Control Message Flag to Query and the Control 404 Code to Withdraw. It uses the session identifier and the SFL Batch 405 identifier that it used to request this SFL batch. 407 The Querier sets the requested lifetime to zero. 409 The Querier sets the Num SFL field to the SFL batch size. 411 Each SFL being withdrawn is set as follows: the allocated SFL label 412 value is written into the SFL n field and the V and W LFlags set. 413 All other LFlags are cleared. 415 The Forwarding Equivalence Class (FEC) is set to the FEC for which 416 the SFLs are requested. 418 The Message Length field is determined and filled in. 420 The Responder proceeds as follows: 422 The Responder sets the control Message Flag to Response and sets the 423 Control Code to Withdraw-Ack. 425 All other fields in the Query message are left unchanged and the 426 message is sent back to the Querier using the signaled or previously 427 agreed message path. 429 A Querier MUST wait a configured time (suggested wait of 60 seconds) 430 before re-attempting a Withdraw request. No more than three Withdraw 431 requests SHOULD be made. These restricctions are to prevent 432 overloading the control plane of the actioning router. 434 3.2.4. Timer Accuracy 436 The lifetime of SFLs is expected to be sufficiently long that there 437 are no significant constraints on timer accuracy. A node should be 438 conservative in its assumptions concerning the lifetime of an SFL. A 439 Querier MUST stop using a SFL significantly before the expiry of its 440 lifetime and a Responder must maintain an SFL in active operation 441 significantly beyond nominal expiry. A margin of the order of 442 minutes is RECOMMENDED. 444 4. Return Path 446 Where the LSP (or other MPLS construct) is multi-point to point, or 447 multi-point to multi- point the RFC6374 Address TLV MUST be included 448 in Query packet, even if the response is requested in-band, since 449 this is needed to provide the necessary return address for this 450 request. 452 EDITIORS NOTE - Look at this text and see if we need to make changes 453 regarding operation over IP. 455 5. Privacy Considerations 457 The inclusion of originating and/or flow information in a packet 458 provides more identity information and hence potentially degrades the 459 privacy of the communication. Whilst the inclusion of the additional 460 granularity does allow greater insight into the flow characteristics 461 it does not specifically identify which node originated the packet 462 other than by inspection of the network at the point of ingress, or 463 inspection of the control protocol packets. This privacy threat may 464 be mitigated by encrypting the control protocol packets, regularly 465 changing the synonymous labels and by concurrently using a number of 466 such labels. 468 6. Security Considerations 470 It is assumed that this protocol is run in a well-managed MPLS 471 network with strict access controls preventing unwanted parties from 472 generating MPLS packets. The control protocol described in this memo 473 thus introduced no additional MPLS security vulnerabilities. 475 7. IANA Considerations 477 7.1. Allocation of MPLS Generalized Associated Channel (G-ACh) Type 479 As per the IANA considerations in [RFC5586], IANA is requested to 480 allocate the following Channel Type in the "MPLS Generalized 481 Associated Channel (G-ACh) Types" registry: 483 Value Description TLV Follows Reference 484 ------ ------------------------------------ ----------- --------- 485 0x0XXX SFL Control No This 487 A value of 0x5A is suggested. 489 7.2. Creation of SFL Simple Control Code Registry 491 IANA is requested to created a new "SFL Simple Control Code" registry 492 within the Generic Associated Channel (G-ACh) Parameters namespace. 493 This registry is divided into two separate parts, one for Query Codes 494 and the other for Response Codes, with formats and initial 495 allocations as follows: 497 Query Codes 499 Code Description Reference 500 ---- ----------------------------------- --------- 501 0x0 SFL Request This 502 0x1 SFL Refresh This 503 0x2 SFL Withdraw This 505 Response Codes 507 Code Description Reference 508 ---- ----------------------------------- --------- 509 0x0 Reserved This 510 0x1 SFL Grant This 511 0x2 SFL Refresh-Ack This 512 0x3 SFL Withdraw-Ack This 513 0x10 Unspecified Error This 514 0x11 SFL-Unable 516 IANA should indicate that the values 0x0 - 0xF in the Response Code 517 section are reserved for non-error response codes. 519 The range of the Code field is 0 - 255. 521 The allocation policy for this registry is IETF Review. 523 8. Acknowledgments 525 The authors thank Haomian Zheng for his review comments. 527 RFC Editor please remove this note which is used to force the 528 following references to appear [RFC3032] [RFC5036] 530 9. References 532 9.1. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, 537 . 539 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 540 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 541 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 542 . 544 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 545 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 546 October 2007, . 548 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 549 "MPLS Generic Associated Channel", RFC 5586, 550 DOI 10.17487/RFC5586, June 2009, 551 . 553 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 554 Measurement for MPLS Networks", RFC 6374, 555 DOI 10.17487/RFC6374, September 2011, 556 . 558 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 559 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 560 May 2017, . 562 9.2. Informative References 564 [I-D.ietf-mpls-sfl-framework] 565 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 566 and G. Mirsky, "Synonymous Flow Label Framework", draft- 567 ietf-mpls-sfl-framework-07 (work in progress), June 2020. 569 Authors' Addresses 571 Stewart Bryant 572 Futurewei Technologies Inc. 574 Email: stewart.bryant@gmail.com 576 Stewart Bryant 577 Futurewei Technologies Inc. 579 Email: sb@stewartbryant.com 580 George Swallow 581 Southend Technical Center 583 Email: swallow.ietf@gmail.com 585 Siva Sivabalan 586 Cisco Systems 588 Email: msiva@cisco.com