idnits 2.17.1 draft-bryant-mpls-sfl-control-03.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 09, 2019) is 1933 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-04 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 Huawei 4 Intended status: Standards Track G. Swallow 5 Expires: July 13, 2019 S. Sivabalan 6 Cisco Systems 7 January 09, 2019 9 MPLS Flow Identification Considerations 10 draft-bryant-mpls-sfl-control-03 12 Abstract 14 In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow 15 labels (SFL) was introduced. This document describes a control 16 protocol that runs over an associated control header to request, 17 withdrawn and extend the lifetime of such labels. 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 July 13, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. SFL Control . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3.1. SFL Control Message . . . . . . . . . . . . . . . . . . . 3 57 3.2. SFL Control Proceedures . . . . . . . . . . . . . . . . . 6 58 3.2.1. Request/Grant . . . . . . . . . . . . . . . . . . . . 6 59 3.2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2.3. Withdraw . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2.4. Timer Accuracy . . . . . . . . . . . . . . . . . . . 9 62 4. Return Path . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Manageability Considerations . . . . . . . . . . . . . . . . 10 64 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 9.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 In [I-D.ietf-mpls-sfl-framework] the concept of MPLS synonymous flow 75 labels (SFL) was introduced. This document describes a simple 76 control protocol that runs over an associated control header to 77 request, withdrawn and extend the lifetime of such labels. 79 2. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in 84 [RFC2119]. 86 3. SFL Control 88 This section describes the process by which the RFC6374 Querier 89 requests SFLs, the process by which the RFC6374 Responder sends them 90 to the Querier, and the process for managing the SFL lifetime. SFL 91 Control Messages are carried over the SFL Control ACH. The SFL ACH 92 is carried over a Pseudowire(PW) in place of the PW Control Word 93 (CW), over an MPLS LSP using the GAL, or over some other mutually 94 agreed path. Similarly the response may be returned over a PW, over 95 a bidirectional LSP or over some other mutually agreed path. See 96 Section 4. 98 3.1. SFL Control Message 100 The format of an SFL Control message, which follows the Associated 101 Channel Header (ACH), is as follows: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 |Version| Flags | Control Code | Message Length | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Session Identifier | SFL Batch | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Lifetime (seconds) | Num SFL | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | SFL 0 | LFlags | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 . . 115 . . 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | SFL n | LFlags | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Forwarding Equivalence Class (FEC) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 1: SFL Control Message Format 124 Reserved fields MUST be set to 0 and ignored upon receipt. The 125 possible values for the remaining fields are as follows: 127 Version Protocol version. Set to zero in this specification. 129 Flags Message control flags. 131 Control Code Code identifying the query or response type. 133 Message Length Total length of this message in bytes. 135 Session Identifier Set arbitrarily by the querier and used as a 136 message handle. 138 SFL Batch Used where the SFLs for this Session Identifier 139 managed across multiple SFL Control Messages. A given 140 set of SFLs MUST be retained in the same batch. 142 Lifetime The lifetime in seconds of the SFLs in this message. 144 In a Query message it is the requested lifetime. In a 145 Response message it is the lifetime that the SFLs have 146 been allocated for by the Responder. The Querier MUST 147 NOT use an SFL after expiry of its lifetime, a 148 Responder MUST make the SFL available for at least its 149 lifetime. 151 Num SFL The number of SFLs in this SFL Batch. This MUST be 152 constant for the lifetime of the batch. 154 SFL n The n'th SFL carried in this TLV. This is an MPLS 155 label which is a component of a label stack entry as 156 defined in Section 2.1 of [RFC3032]. The position of 157 a label within a batch is constant for the lifetime of 158 the batch. Enumeration starts at zero. 160 LFlags The set of flags associated with the immediately 161 preceding SFL. See below. 163 FEC The Forwarding Equivalence Class that the SFLs in this 164 TLV correspond to. This is encoded as per 165 Section 3.4.1 of [RFC5036]. 167 Flags: The format of the Flags field is shown below. 169 +-+-+-+-+ 170 |R|0|0|0| 171 +-+-+-+-+ 173 SFL Control Message Flag 175 R: Query/Response indicator. Set to 0 for a Query and 1 for a 176 Response. 178 0: Set to zero by the Sender and ignored by the Receiver. 180 Control Code: Set as follows according to whether the message is a 181 Query or a Response as identified by the R flag. 183 For a Query: 185 Request This indicates that the responder is requested to allocate 186 the set of SFLs marked with the R LFlag in this Message. 188 Refresh This indicates that the responder is requested to refresh 189 the set of SFLs marked with the V LFlag in this Message. 191 Withdraw This indicates that the querier will no longer use the set 192 of SFLs marked with the V Lflag and the responder may expire their 193 lifetime. 195 For a Response: 197 Grant This indicates that the responder allocated the set of SFLs 198 marked with the A LFlag in this Message. 200 Refresh-Ack This indicates that the responder has refreshed the set 201 of SFLs marked with the V LFlag in this Message, and the lifetime 202 is now as indicated by the lifetime field. 204 Withdraw-Ack This indicates that the responder has received the 205 Withdraw message and will withdraw the SFLs 207 SFL-Unable The Responder was unable to satisfy the SFL Request. The 208 details of the failure can be determined by comparing the Request 209 and Grant messages. 211 Further error codes are for future study. 213 The LFlags field is defined as follows: 215 0 1 216 0 1 2 3 4 5 6 7 8 9 0 1 217 +-+-+-+-+-+-+-+-+-+-+-+-+ 218 |0|1|2|3| MBZ | 219 +-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 2: LFlags Bit Definition 223 Where: 225 0 (Valid (V)) The Label value of the corresponding SFL is valid. In 226 an SFL Request setting the V Lflag indicates a request 227 for the specified label value. Where an SFL has a 228 valid flag clear in a request message this indicates 229 that any SFL value is acceptable. 231 1 (Request (R)) Indicates to the Querier that this member of the SFL 232 batch is requested. Where a value is specified in the 233 request, but the Responder is unable honour that 234 request, no SFL is allocated and the corresponding A 235 flag MUST be cleared. 237 2 (Allocated (A) Indicates to the Querier that this SFL was 238 allocated. 240 3 (Withdraw (W)) Indicates to the Responser that this SFL is to be 241 withdrawn and to the Querier that the withdrawal has 242 been carried out. 244 MBZ MUST be sent as zero and ignored on receive. 246 A flag value of one is true/set and a flag value of zero is false/ 247 clear. The use of these bits is described in more detail in the 248 following sub-sections. 250 3.2. SFL Control Proceedures 252 3.2.1. Request/Grant 254 To request a batch of SFLs the Querier constructs an SFL Control 255 Request, encapsulates it in an SFL Control ACH and sends it to the 256 Responder via an appropriate path. It sets the Control Message Flag 257 to Query and the Control Code to Request. It chooses a session 258 identifier as a handle for this transaction and as a way of binding 259 this batch of SFLs to other operations that will use members of this 260 SFL batch. Since members of the batch are treated as a group, the 261 SFL Batch identifier is used to identify different SFL batches used 262 in conjunction with the same session identifier. 264 The requested lifetime is set. This is the number of seconds from 265 the time of the query to the time when the batch of SFLs will expire 266 unless refreshed. 268 The Num SFL field is set to the SFL batch size. 270 Each SFL is set as follows: if a specific value is requested (for 271 example for continuity across system restarts) this is written into 272 the SFV n field and the V LFlag set. Otherwise, and including spare 273 SFLs where an allocation is not requested, the label value is set to 274 zero and the V LFlag is cleared. For each SFL entry where an 275 allocation is requested the R LFlag is set. All other LFlags are 276 cleared. 278 The Forwarding Equivalence Class (FEC) is set to the FEC for which 279 the SFLs are requested. 281 The Message Length is determined and filled in. 283 The Responder proceeds as follows: 285 It sets the control Message Flag to Response and initially sets the 286 Control Code to Grant. 288 For each SFL with an R flag set, it determines whether it can honour 289 the request, if so sets the A Lflag, and if the SFL value in the 290 query was zero it overwrites it with the allocated SFL label value. 291 In all other cases it leaves the SFL value and LFlag unchanged. 293 The lifetime field is updated with the lifetime of the SFLs if this 294 is different from the requested lifetime. 296 All other fields in the Query message are left unchanged and the 297 message is sent back to the Querier using the signaled or previously 298 agreed message path. 300 Where the offered lifetime is other than the requested lifetime the 301 Querier may accept the proposed value, or withdraw the SFLs and 302 attempt to negotiate a new set of SFLs with a different lifetime. 304 If the Responder is unable to allocate all of the requested SFLs it 305 MUST respond with a response code of SFL-Unable. The Querier MUST 306 determine whether the allocated SFLs were adequate for its purposes 307 and MUST send a withdraw if there are not adequate. A Querier MUST 308 NOT attempt to hoard labels in the hope that the residual labels 309 needed may become available in the future. 311 A Querier MUST wait a configured time (suggested wait of 60 seconds) 312 before reattempting negotiation for a resource. Any failure to 313 negotiate the required resources MUST be notified through the 314 management interface of both Querier and Responder. 316 A Querier MUST NOT send an expired SFL to a Responder since to do so 317 may invalidate another SFL operation. 319 3.2.2. Refresh 321 To request the lifetime refresh of a batch of SFLs the Querier 322 constructs an SFL Refresh Request, encapsulates it in an SFL Control 323 ACH and sends it to the Responder via an appropriate path. It sets 324 the Control Message Flag to Query and the Control Code to Refresh. 325 It uses the session identifier and the SFL Batch identifier that it 326 used to request this SFL batch. 328 The requested lifetime is set. This is the number of seconds from 329 the time of the query to the time when the batch of SFLs will expire 330 unless refreshed. 332 The Num SFL field is set to the SFL batch size. 334 Each SFL is set as follows: the allocated SFL label value is written 335 into the SFL n field and the V LFlag set. All other LFlags are 336 cleared. 338 The Forwarding Equivalence Class (FEC) is set to the FEC for which 339 the SFLs are requested. 341 The Message Length is determined and filled in. 343 The Responder proceeds as follows: 345 It sets the control Message Flag to Response and sets the Control 346 Code to Refresh-Ack. 348 It sets the lifetime to the lifetime of the SFL. 350 All other fields in the Query message are left unchanged and the 351 message is sent back to the Querier using the signaled or previously 352 agreed message path. 354 Where the offered lifetime is other than the requested lifetime the 355 Querier may accept the proposed value, or withdraw the SFLs and 356 attempt to negotiate a new set of SFLs with a different lifetime. 358 A Querier MUST wait a configured time (suggested wait of 60 seconds) 359 before reattempting negotiation for a resource. Any failure to 360 negotiate the required resources MUST be notified through the 361 management interface of both Querier and Responder. 363 3.2.3. Withdraw 365 To request the withdrawal of some or all of a batch of SFLs the 366 Querier constructs an SFL Withdraw Request, encapsulates it in an SFL 367 Control ACH and sends it to the Responder via an appropriate path. 368 It sets the Control Message Flag to Query and the Control Code to 369 Withdraw. It uses the session identifier and the SFL Batch 370 identifier that it used to request this SFL batch. 372 The requested lifetime is set to zero. 374 The Num SFL field is set to the SFL batch size. 376 Each SFL being withdrawn is set as follows: the allocated SFL label 377 value is written into the SFL n field and the V and W LFlags set. 378 All other LFlags are cleared. 380 The Forwarding Equivalence Class (FEC) is set to the FEC for which 381 the SFLs are requested. 383 The Message Length is determined and filled in. 385 The Responder proceeds as follows: 387 It sets the control Message Flag to Response and sets the Control 388 Code to Withdraw-Ack. 390 All other fields in the Query message are left unchanged and the 391 message is sent back to the Querier using the signaled or previously 392 agreed message path. 394 A Querier MUST wait a configured time (suggested wait of 60 seconds) 395 before reattempting a Withdraw request. No more than three Withdraw 396 requests should be made. 398 3.2.4. Timer Accuracy 400 The lifetime of SFLs is expected to be sufficiently long that there 401 are no significant constraints on timer accuracy. A node should be 402 conservative in its assumptions concerning the lifetime of an SFL. A 403 Querier MUST stop using a SFL significantly before the expiry of its 404 lifetime and a Responder must maintain an SFL in active operation 405 significantly beyond nominal expiry. A margin of the order of 406 minutes is RECOMMENDED. 408 4. Return Path 410 Where the LSP is a mulit-point to point, or multi-point to multi- 411 point MPLS LSP (or other MPLS construct) the RFC6374 Address TLV MUST 412 be included in Query packet, even if the response is requested in- 413 band, since this is needed to provide the necessary return address 414 for this request. 416 5. Manageability Considerations 418 This may be provided in a future version of this memo. 420 6. Privacy Considerations 422 The inclusion of originating and/or flow information in a packet 423 provides more identity information and hence potentially degrades the 424 privacy of the communication. Whilst the inclusion of the additional 425 granularity does allow greater insight into the flow characteristics 426 it does not specifically identify which node originated the packet 427 other than by inspection of the network at the point of ingress, or 428 inspection of the control protocol packets. This privacy threat may 429 be mitigated by encrypting the control protocol packets, regularly 430 changing the synonymous labels and by concurrently using a number of 431 such labels. 433 7. Security Considerations 435 It is assumed that this protocol is run in a well managed MPLS 436 network with strict access controls preventing unwanted parties from 437 generating MPLS OAM packets. The control protocol described in this 438 memo thus introduced no additional MPLS security vulnerabilities. 440 8. IANA Considerations 442 As per the IANA considerations in [RFC5586], IANA is requested to 443 allocate the following Channel Types in the "MPLS Generalized 444 Associated Channel (G-ACh) Types" registry: 446 Value Description TLV Follows Reference 447 ------ ---------------------------------------- ----------- --------- 448 0x0XXX SFL Control No This 450 A value of 0x60 is suggested. 452 Force references to appear with mkd [RFC3032] [RFC5036] 454 9. References 456 9.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 464 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 465 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 466 . 468 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 469 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 470 October 2007, . 472 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 473 "MPLS Generic Associated Channel", RFC 5586, 474 DOI 10.17487/RFC5586, June 2009, 475 . 477 9.2. Informative References 479 [I-D.ietf-mpls-sfl-framework] 480 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 481 and G. Mirsky, "Synonymous Flow Label Framework", draft- 482 ietf-mpls-sfl-framework-04 (work in progress), December 483 2018. 485 Authors' Addresses 487 Stewart Bryant 488 Huawei 490 Email: stewart.bryant@gmail.com 492 George Swallow 493 Cisco Systems 495 Email: swallow.ietf@gmail.com 496 Siva Sivabalan 497 Cisco Systems 499 Email: msiva@cisco.com