idnits 2.17.1 draft-bryant-mpls-sfl-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2015) is 3343 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 S. Bryant 3 Internet-Draft G. Swallow 4 Intended status: Standards Track S. Sivabalan 5 Expires: September 3, 2015 Cisco Systems 6 March 2, 2015 8 A Control Protocol for Synonymous Flow Labels 9 draft-bryant-mpls-sfl-control-00 11 Abstract 13 In draft-bryant-mpls-synonymous-flow-labels the concept of MPLS 14 synonymous flow labels (SFL) was introduced. This document describes 15 a control protocol that runs over an associated control header to 16 request, withdrawn and extend the lifetime of such labels. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 3, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. SFL Control . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3.1. SFL Control Message . . . . . . . . . . . . . . . . . . . 3 56 3.2. SFL Control Proceedures . . . . . . . . . . . . . . . . . 6 57 3.2.1. Request/Grant . . . . . . . . . . . . . . . . . . . . 6 58 3.2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.2.3. Withdraw . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2.4. Timer Accuracy . . . . . . . . . . . . . . . . . . . 9 61 4. Return Path . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5. Manageability Considerations . . . . . . . . . . . . . . . . 9 63 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 In [draft-bryant-mpls-synonymous-flow-labels] the concept of MPLS 73 synonymous flow labels (SFL) was introduced. This document describes 74 a simple control protocol that runs over an associated control header 75 to request, withdrawn and extend the lifetime of such labels. In 76 [draft-bryant-mpls-RFC63740-over-udp] it is shown how to run this 77 over UDP transport. 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. 143 In a Query message it is the requested lifetime. In a 144 Response message it is the lifetime that the SFLs have 145 been allocated for by the Responder. The Querier MUST 146 NOT use an SFL after expiry of its lifetime, a 147 Responder MUST make the SFL available for at least its 148 lifetime. 150 Num SFL The number of SFLs in this SFL Batch. This MUST be 151 constant for the lifetime of the batch. 153 SFL n The n'th SFL carried in this TLV. This is an MPLS 154 label which is a component of a label stack entry as 155 defined in Section 2.1 of [RFC3032]. The position of 156 a label within a batch is constant for the lifetime of 157 the batch. Enumeration starts at zero. 159 LFlags The set of flags associated with the immediately 160 preceding SFL. See below. 162 FEC The Forwarding Equivalence Class that the SFLs in this 163 TLV correspond to. This is encoded as per 164 Section 3.4.1 of [RFC5036]. 166 Flags: The format of the Flags field is shown below. 168 +-+-+-+-+ 169 |R|0|0|0| 170 +-+-+-+-+ 172 SFL Control Message Flag 174 R: Query/Response indicator. Set to 0 for a Query and 1 for a 175 Response. 177 0: Set to zero by the Sender and ignored by the Receiver. 179 Control Code: Set as follows according to whether the message is a 180 Query or a Response as identified by the R flag. 182 For a Query: 184 Request This indicates that the responder is requested to allocate 185 the set of SFLs marked with the R LFlag in this Message. 187 Refresh This indicates that the responder is requested to refresh 188 the set of SFLs marked with the V LFlag in this Message. 190 Withdraw This indicates that the querier will no longer use the set 191 of SFLs marked with the V Lflag and the responder may expire their 192 lifetime. 194 For a Response: 196 Grant This indicates that the responder allocated the set of SFLs 197 marked with the A LFlag in this Message. 199 Refresh-Ack This indicates that the responder has refreshed the set 200 of SFLs marked with the V LFlag in this Message, and the lifetime 201 is now as indicated by the lifetime field. 203 Withdraw-Ack This indicates that the responder has received the 204 Withdraw message and will withdraw the SFLs 206 SFL-Unable The Responder was unable to satisfy the SFL Request. The 207 details of the failure can be determined by comparing the Request 208 and Grant messages. 210 Further error codes are for future study. 212 The LFlags field is defined as follows: 214 0 1 215 0 1 2 3 4 5 6 7 8 9 0 1 216 +-+-+-+-+-+-+-+-+-+-+-+-+ 217 |0|1|2|3| MBZ | 218 +-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 2: LFLAGS Bit Definition 222 Where: 224 0 (Valid (V)) The Label value of the corresponding SFL is valid. In 225 an SFL Request setting the V Lflag indicates a request 226 for the specified label value. Where an SFL has a 227 valid flag clear in a request message this indicates 228 that any SFL value is acceptable. 230 1 (Request (R)) Indicates to the Querier that this member of the SFL 231 batch is requested. Where a value is specified in the 232 request, but the Responder is unable honour that 233 request, no SFL is allocated and the corresponding A 234 flag MUST be cleared. 236 2 (Allocated (A) Indicates to the Querier that this SFL was 237 allocated. 239 3 (Withdraw (W)) Indicates to the Responser that this SFL is to be 240 withdrawn and to the Querier that the withdrawal has 241 been carried out. 243 MBZ MUST be sent as zero and ignored on receive. 245 A flag value of one is true/set and a flag value of zero is false/ 246 clear. The use of these bits is described in more detail in the 247 following sub-sections. 249 3.2. SFL Control Proceedures 251 3.2.1. Request/Grant 253 To request a batch of SFLs the Querier constructs an SFL Control 254 Request, encapsulates it in an SFL Control ACH and sends it to the 255 Responder via an appropriate path. It sets the Control Message Flag 256 to Query and the Control Code to Request. It chooses a session 257 identifier as a handle for this transaction and as a way of binding 258 this batch of SFLs to other operations that will use members of this 259 SFL batch. Since members of the batch are treated as a group, the 260 SFL Batch identifier is used to identify different SFL batches used 261 in conjunction with the same session identifier. 263 The requested lifetime is set. This is the number of seconds from 264 the time of the query to the time when the batch of SFLs will expire 265 unless refreshed. 267 The Num SFL field is set to the SFL batch size. 269 Each SFL is set as follows: if a specific value is requested (for 270 example for continuity across system restarts) this is written into 271 the SFV n field and the V LFlag set. Otherwise, and including spare 272 SFLs where an allocation is not requested, the label value is set to 273 zero and the V LFlag is cleared. For each SFL entry where an 274 allocation is requested the R LFlag is set. All other LFlags are 275 cleared. 277 The Forwarding Equivalence Class (FEC) is set to the FEC for which 278 the SFLs are requested. 280 The Message Length is determined and filled in. 282 The Responder proceeds as follows: 284 It sets the control Message Flag to Response and initially sets the 285 Control Code to Grant. 287 For each SFL with an R flag set, it determines whether it can honour 288 the request, if so sets the A Lflag, and if the SFL value in the 289 query was zero it overwrites it with the allocated SFL label value. 290 In all other cases it leaves the SFL value and LFlag unchanged. 292 The lifetime field is updated with the lifetime of the SFLs if this 293 is different from the requested lifetime. 295 All other fields in the Query message are left unchanged and the 296 message is sent back to the Querier using the signaled or previously 297 agreed message path. 299 Where the offered lifetime is other than the requested lifetime the 300 Querier may accept the proposed value, or withdraw the SFLs and 301 attempt to negotiate a new set of SFLs with a different lifetime. 303 If the Responder is unable to allocate all of the requested SFLs it 304 MUST respond with a response code of SFL-Unable. The Querier MUST 305 determine whether the allocated SFLs were adequate for its purposes 306 and MUST send a withdraw if there are not adequate. A Querier MUST 307 NOT attempt to hoard labels in the hope that the residual labels 308 needed may become available in the future. 310 A Querier MUST wait a configured time (suggested wait of 60 seconds) 311 before reattempting negotiation for a resource. Any failure to 312 negotiate the required resources MUST be notified through the 313 management interface of both Querier and Responder. 315 A Querier MUST NOT send an expired SFL to a Responder since to do so 316 may invalidate another SFL operation. 318 3.2.2. Refresh 320 To request the lifetime refresh of a batch of SFLs the Querier 321 constructs an SFL Refresh Request, encapsulates it in an SFL Control 322 ACH and sends it to the Responder via an appropriate path. It sets 323 the Control Message Flag to Query and the Control Code to Refresh. 324 It uses the session identifier and the SFL Batch identifier that it 325 used to request this SFL batch. 327 The requested lifetime is set. This is the number of seconds from 328 the time of the query to the time when the batch of SFLs will expire 329 unless refreshed. 331 The Num SFL field is set to the SFL batch size. 333 Each SFL is set as follows: the allocated SFL label value is written 334 into the SFL n field and the V LFlag set. All other LFlags are 335 cleared. 337 The Forwarding Equivalence Class (FEC) is set to the FEC for which 338 the SFLs are requested. 340 The Message Length is determined and filled in. 342 The Responder proceeds as follows: 344 It sets the control Message Flag to Response and sets the Control 345 Code to Refresh-Ack. 347 It sets the lifetime to the lifetime of the SFL. 349 All other fields in the Query message are left unchanged and the 350 message is sent back to the Querier using the signaled or previously 351 agreed message path. 353 Where the offered lifetime is other than the requested lifetime the 354 Querier may accept the proposed value, or withdraw the SFLs and 355 attempt to negotiate a new set of SFLs with a different lifetime. 357 A Querier MUST wait a configured time (suggested wait of 60 seconds) 358 before reattempting negotiation for a resource. Any failure to 359 negotiate the required resources MUST be notified through the 360 management interface of both Querier and Responder. 362 3.2.3. Withdraw 364 To request the withdrawal of some or all of a batch of SFLs the 365 Querier constructs an SFL Withdraw Request, encapsulates it in an SFL 366 Control ACH and sends it to the Responder via an appropriate path. 367 It sets the Control Message Flag to Query and the Control Code to 368 Withdraw. It uses the session identifier and the SFL Batch 369 identifier that it used to request this SFL batch. 371 The requested lifetime is set to zero. 373 The Num SFL field is set to the SFL batch size. 375 Each SFL being withdrawn is set as follows: the allocated SFL label 376 value is written into the SFL n field and the V and W LFlags set. 377 All other LFlags are cleared. 379 The Forwarding Equivalence Class (FEC) is set to the FEC for which 380 the SFLs are requested. 382 The Message Length is determined and filled in. 384 The Responder proceeds as follows: 386 It sets the control Message Flag to Response and sets the Control 387 Code to Withdraw-Ack. 389 All other fields in the Query message are left unchanged and the 390 message is sent back to the Querier using the signaled or previously 391 agreed message path. 393 A Querier MUST wait a configured time (suggested wait of 60 seconds) 394 before reattempting a Withdraw request. No more than three Withdraw 395 requests should be made. 397 3.2.4. Timer Accuracy 399 The lifetime of SFLs is expected to be sufficiently long that there 400 are no significant constraints on timer accuracy. A node should be 401 conservative in its assumptions concerning the lifetime of an SFL. A 402 Querier MUST stop using a SFL significantly before the expiry of its 403 lifetime and a Responder must maintain an SFL in active operation 404 significantly beyond nominal expiry. A margin of the order of 405 minutes is RECOMMENDED. 407 4. Return Path 409 Where the LSP is a mulit-point to point, or multi-point to multi- 410 point MPLS LSP (or other MPLS construct) the RFC6374 Address TLV MUST 411 be included in Query packet, even if the response is requested in- 412 band, since this is needed to provide the necessary return address 413 for this request. 415 5. Manageability Considerations 417 This may be provided in a future version of this memo. 419 6. Privacy Considerations 421 The inclusion of originating and/or flow information in a packet 422 provides more identity information and hence potentially degrades the 423 privacy of the communication. Whilst the inclusion of the additional 424 granularity does allow greater insight into the flow characteristics 425 it does not specifically identify which node originated the packet 426 other than by inspection of the network at the point of ingress, or 427 inspection of the control protocol packets. This privacy threat may 428 be mitigated by encrypting the control protocol packets, regularly 429 changing the synonymous labels and by concurrently using a number of 430 such labels. 432 7. Security Considerations 434 It is assumed that this protocol is run in a well managed MPLS 435 network with strict access controls preventing unwanted parties from 436 generating MPLS OAM packets. The control protocol described in this 437 memo thus introduced no additional MPLS security vulnerabilities. 439 8. IANA Considerations 441 As per the IANA considerations in [RFC5586], IANA is requested to 442 allocate the following Channel Types in the "MPLS Generalized 443 Associated Channel (G-ACh) Types" registry: 445 Value Description TLV Follows Reference 446 ------ ---------------------------------------- ----------- --------- 447 0x0XXX SFL Control No This 449 A value of 0x60 is suggested. 451 9. Acknowledgements 453 TBD 455 10. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 461 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 462 Encoding", RFC 3032, January 2001. 464 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 465 Specification", RFC 5036, October 2007. 467 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 468 Associated Channel", RFC 5586, June 2009. 470 Authors' Addresses 472 Stewart Bryant 473 Cisco Systems 475 Email: stbryant@cisco.com 476 George Swallow 477 Cisco Systems 479 Email: swallow@cisco.com 481 Siva Sivabalan 482 Cisco Systems 484 Email: msiva@cisco.com