idnits 2.17.1 draft-ietf-manet-credit-window-04.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 (April 10, 2016) is 2931 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 (-29) exists of draft-ietf-manet-dlep-22 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad hoc Networks Working Group S. Ratliff 2 Internet-Draft VT iDirect 3 Intended status: Standards Track April 10, 2016 4 Expires: October 12, 2016 6 Credit Windowing extension for DLEP 7 draft-ietf-manet-credit-window-04 9 Abstract 11 This draft describes an extension to the DLEP protocol to provide a 12 credit-windowing scheme analogous to that in RFC5578 for destination- 13 specific flow control. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on October 12, 2016. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 6. DLEP Messages for Credit-Window Extension . . . . . . . . . . 5 55 7. DLEP Status Codes for Credit-Window Extension . . . . . . . . 5 56 8. DLEP Data Items for Credit-Window Extension . . . . . . . . . 5 57 8.1. DLEP Destination Up Message . . . . . . . . . . . . . . . 5 58 8.2. DLEP Destination Announce Message . . . . . . . . . . . . 6 59 8.3. DLEP Destination Up Response Message . . . . . . . . . . 6 60 8.4. DLEP Destination Announce Response Message . . . . . . . 7 61 8.5. DLEP Destination Update Message . . . . . . . . . . . . . 7 62 8.6. DLEP Link Characteristics Request Message . . . . . . . . 7 63 9. Credit Window Data Item Definitions . . . . . . . . . . . . . 8 64 9.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 8 65 9.2. Credit Window Status . . . . . . . . . . . . . . . . . . 9 66 9.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 10 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 11 70 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 13.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 In the world of radio-based networking, there are modems that need 79 fine-grained flow control over traffic ingressing from a LAN 80 connection, bound for transmission over the RF. The need for such 81 fine-grained control can exist for multiple reasons. For example, 82 radio devices are typically connected to the network by Ethernet. 83 The capacity of an Ethernet link is normally far superior to that of 84 the RF, leading to the possibility of overruns and dropped traffic. 85 This is exacerbated by the fact that RF link capacity can vary from 86 moment to moment, for an indeterminate amount of time. Additionally, 87 the capacity of the link can vary greatly depending on the 88 destination, due to factors such as obstructions or multipath fading. 90 These challenges motivate the requirement for a fine-grained flow 91 control in radio-based communications - one that can support 92 different window sizes for each destination accessed across the RF 93 network. To address this requirement, this document describes an 94 extension to the Dynamic Link Event Protocol ([DLEP]), allowing for a 95 Credit windowing scheme to be implemented on a destination-by- 96 destination basis. 98 2. Requirements 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14, RFC 2119 [RFC2119]. 105 3. Overview 107 This protocol extension to DLEP describes a credit windowing scheme 108 analogous to the one documented in [RFC5578]. In this scheme, data 109 plane traffic flowing between the router and modem is controlled by 110 the availability of credits. Credits are expressed as if two 111 unidirectional windows exist between the modem and router. This 112 document identifies these windows as the 'Modem Receive Window', or 113 MRW, and the 'Router Receive Window', or RRW. The responsibility of 114 granting credits lies with the receiver on a window - that is, on the 115 MRW, the modem is responsible for granting credits to the router, 116 allowing it (the router) to send data plane traffic to the modem. 117 Likewise, the router is responsible for granting credits on the RRW, 118 which allows the modem to send data plane traffic to the router. 120 Credits represent the number of data plane octets, or an increment in 121 the number of data plane octets, that can be sent on a given window 122 at the MAC layer to the receiver. 124 4. Terminology 126 In general, the draft uses the same terminology as specified in the 127 core DLEP draft [DLEP]. In addition, the draft uses the following 128 terms: 130 o Modem Receive Window, or MRW. The MRW represents a logical, 131 unidirectional window for traffic flowing from the router to the 132 modem. 134 o Router Receive Window, or RRW. The RRW represents a logical, 135 unidirectional window for traffic flowing from the modem to the 136 router. 138 5. Operation 140 DLEP peers supporting this extension MUST include a DLEP 'Extensions 141 Supported' data item, including the value TBD representing this 142 extension in the appropriate DLEP Session Initialization and Session 143 Initialization Response messages. 145 Credits are managed on a destination-specific basis - separate credit 146 counts MUST be maintained for each destination requiring the service. 147 Credits MUST NOT be applied to the DLEP session that exists between 148 routers and modems; they are applied only to the data plane traffic. 149 There are no default values for either the initial credit window or 150 the credit increments. 152 When DLEP peers desire to employ the credit-windowing extension, the 153 peer originating the Destination Up or Destination Announce message 154 MUST supply a Credit Grant data item with an initial, non-zero value 155 as the increment of the window the originator controls (i.e., the 156 MRW, or RRW). 158 When receiving a Credit Grant data item on a Destination Up or 159 Destination Announce message, the receiver MUST take one of the 160 following actions: 162 1. Reject the use of credits for this destination, via the 163 Destination Up Response or Destination Announce Response message 164 containing a Status data item with a status code of 'Credit Use 165 Rejected', or 167 2. Initialize the appropriate window value of zero, then apply the 168 increment specified in the Credit Grant data item. 170 If the initialization completes successfully, the receiver MUST 171 respond to the Destination Up/Destination Announce message with a 172 response message that contains a Credit Grant data item, initializing 173 its receive window. 175 Data plane traffic would then flow between the DLEP peers, with said 176 peers accounting for the traffic sent/received by decrementing the 177 appropriate credit counts. 179 The number of credits needed for a given transmission is the length 180 of the data portion of the packet at the MAC layer. When sending 181 data to a credit enabled peer, the sender MUST decrement the 182 appropriate window by the size of the data being sent, prior to 183 encapsulation at the MAC layer. When traffic is received, the 184 receiver MUST decrement its own window after decapsulation at the MAC 185 layer. 187 When the number of available credits to the destination reaches 0, 188 the sender MUST stop sending data plane traffic to the destination, 189 until additional credits are granted by the receiver. 191 6. DLEP Messages for Credit-Window Extension 193 The credit-windowing extension does not introduce any additional DLEP 194 signals or messages. 196 7. DLEP Status Codes for Credit-Window Extension 198 The credit-windowing extension introduces two additional DLEP status 199 code: 201 +--------------+----------+------------+----------------------------+ 202 | Status Code | Value | Failure | Reason | 203 | | | Mode | | 204 +--------------+----------+------------+----------------------------+ 205 | Credit | TBD | Continue | Credit counts are out-of- | 206 | Window Out | | | sync between sender and | 207 | of Sync | | | receiver on the | 208 | | | | destination. | 209 | Credit Use | TBD | Continue | Credit counts cannot be | 210 | Rejected | | | used for the destination. | 211 +--------------+----------+------------+----------------------------+ 213 8. DLEP Data Items for Credit-Window Extension 215 The extension introduces 3 DLEP data items: 217 +------------+-------------------------------------+ 218 | Type Code | Description | 219 +------------+-------------------------------------+ 220 | TBD | Credit Grant (Section 9.1) | 221 | TBD | Credit Window Status (Section 9.2) | 222 | TBD | Credit Request (Section 9.3) | 223 +------------+-------------------------------------+ 225 Descriptions of the data items are included below. The credit- 226 windowing data items are inserted into DLEP messages as follows: 228 8.1. DLEP Destination Up Message 229 If use of credits is required for the destination, then the 230 Destination Up message MUST contain one Credit Grant (Section 9.1) 231 data item. The value of the credit increment is at the discretion of 232 the implementation. The receiver of the Destination Up message MUST 233 use the value in Credit Grant as the initial value for the 234 appropriate window. 236 If the Destination Up message does not contain the Credit Grant data 237 item, credits MUST NOT be used for that destination. 239 8.2. DLEP Destination Announce Message 241 If use of credits is required for the destination, then the 242 Destination Announce message MUST contain one Credit Grant 243 (Section 9.1) data item. The value of the credit increment is at the 244 discretion of the implementation. The receiver of the Destination 245 Announce message MUST use the value in Credit Grant as the initial 246 value for the appropriate window. 248 If the Destination Announce message does not contain the Credit Grant 249 data item, credits MUST NOT be used for that destination. 251 8.3. DLEP Destination Up Response Message 253 If the corresponding Destination Up message contained a Credit Grant 254 (Section 9.1) data item, the Destination Up Response message MUST 255 also contain a Credit Grant (Section 9.1) data item. 257 Likewise, if the corresponding Destination Up message did not contain 258 a Credit Grant (Section 9.1) data item, the Destination Up Response 259 message MUST NOT contain a Credit Grant (Section 9.1) data item. 261 The receiver of Destination Up Response MUST use the received Credit 262 Grant value to initialize the appropriate window (e.g., the MRW value 263 for routers, the RRW value for modems). 265 When an implementation detects a mismatch in the presence or absence 266 of credit window data items between the DLEP Destination Up and 267 Destination Up Response messages, the implementation detecting the 268 mismatch MUST terminate the session by issuing a Peer Termination 269 message with a status code of 'Credit Window Out of Sync', and 270 transition to the Session Termination state. 272 8.4. DLEP Destination Announce Response Message 274 If the corresponding Destination Announce message contained a Credit 275 Grant (Section 9.1) data item, the Destination Announce Response 276 message MUST also contain a Credit Grant (Section 9.1) data item. 278 Likewise, if the corresponding Destination Announce message did not 279 contain a Credit Grant (Section 9.1) data item, the Destination 280 Announce Response message MUST NOT contain a Credit Grant 281 (Section 9.1) data item. 283 The receiver of Destination Announce Response MUST use the received 284 Credit Grant value to initialize the appropriate window (e.g., the 285 MRW value for routers, the RRW value for modems). 287 When an implementation detects a mismatch in the presence or absence 288 of credit window data items between the DLEP Destination Announce and 289 Destination Announce Response messages, the implementation detecting 290 the mismatch MUST terminate the session by issuing a Peer Termination 291 message with a status code of 'Credit Window Out of Sync', and 292 transition to the Session Termination state. 294 8.5. DLEP Destination Update Message 296 If the corresponding Destination Up or Destination Announce message 297 contained the Credit Grant data item, the Destination Update message 298 MAY contain one of each of the following data items: 300 o Credit Grant (Section 9.1) 302 o Credit Window Status (Section 9.2) 304 o Credit Request (Section 9.3) 306 DLEP peers supporting the extension MAY format and send a DLEP 307 Destination Update message solely for the purposes of maintaining the 308 credit windows. In cases where a peer already has information 309 requiring a Destination Update message, (e.g., a change in Latency on 310 the link), the credit data items MAY be included in addition to that 311 information. 313 8.6. DLEP Link Characteristics Request Message 315 If the corresponding Destination Up or Destination Announce message 316 contained the credit Grant data item, the Link Characteristics 317 Request message MAY contain the following data item: 319 o Credit Request (Section 9.3) 320 DLEP peers supporting the extension MAY format and send a DLEP Link 321 Characteristics Request message solely for the purposes of 322 maintaining the credit windows. In cases where a peer already has 323 information requiring a Link Characteristics Request message, the 324 Credit Request data MAY be included in addition to that information. 326 9. Credit Window Data Item Definitions 328 9.1. Credit Grant 330 The Credit Grant data item is sent from a DLEP participant to grant 331 an increment to credits on a window. The Credit Grant data item MAY 332 appear in the DLEP Destination Up, Destination Announce, and 333 Destination Update messages. The value in a Credit Grant data item 334 represents an increment to be added to any existing credits available 335 on the window. Upon successful receipt and processing of a Credit 336 Grant data item, the receiver MUST respond with a message containing 337 a Credit Window Status data item to report the updated aggregate 338 values for synchronization purposes, and if initializing a new credit 339 window, granting initial credits. 341 The Credit Grant data item contains the following fields: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Data Item Type | Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Credit Increment | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Credit Increment | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Data Item Type: TBD 355 Length: 8 357 Credit Increment: A 64-bit unsigned integer representing the 358 additional credits, in octets, to be assigned to the credit 359 window. 361 Since credits can only be granted by the receiver on a window, the 362 applicable credit window (either the MRW or the RRW) is derived from 363 the sender of the grant. The Credit Increment MUST NOT cause the 364 window to overflow; if this condition occurs, implementations MUST 365 set the credit window to the maximum value contained in a 64-bit 366 quantity. 368 9.2. Credit Window Status 370 During normal operation, DLEP session peers may disagree about the 371 number of available credits. Operational credit mismatches can occur 372 due to packets in transit on the wire. DLEP session peers MAY use 373 the Credit Window Status data item to maintain synchronization of 374 credit counts. This data item is informational only; it is used to 375 inform the receiving peer of the current credit counts for both the 376 MRW and RRW, from the perspective of the sender. 378 Upon receipt of a Credit Window Status data item, an implementation 379 SHOULD compare its own credit counts with that of the originator. If 380 the receiver of Credit Window Status detects that the local credit 381 counts are not synchronized with the originator, the receiving 382 implementation MAY either: o Attempt resynchronization using an 383 additional Credit Grant, if applicable, or o Issue a DLEP Destination 384 Down message, to clear credit counts on the session. 386 Implementations issuing Destinaton Down MUST supply a DLEP Status 387 item, with the status code of 'Credit Window Out of Sync', as defined 388 in this document. 390 If a DLEP message contains both the Credit Grant (Section 9.1) data 391 item and the Credit Window Status (Section 9.2) data item, 392 implementations MUST first apply the Credit Grant (Section 9.1) data 393 item before comparing the credit counts contained in Credit Window 394 Status (Section 9.2). 396 It is recommended that implementations issue a DLEP Destination 397 Update with a Credit Window Status data item at a configurable 398 multiple of the DLEP Heartbeat timer, to serve as a continuing check 399 on synchronization of the credit windows for a destination. 401 The Credit Window Status data item contains the following fields: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Data Item Type | Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Modem Receive Window Value : 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 : Modem Receive Window Value | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Router Receive Window Value : 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 : Router Receive Window Value | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Data Item Type: TBD 418 Length: 16 420 Modem Receive Window Value: A 64-bit unsigned integer, indicating 421 the current number of credits, in octets, available on the Modem 422 Receive Window, for the destination referred to by the message. 424 Router Receive Window Value: A 64-bit unsigned integer, indicating 425 the current number of credits, in octets, available on the Router 426 Receive Window, for the destination referred to by the message. 428 9.3. Credit Request 430 The Credit Request data item MAY be sent from either DLEP 431 participant, as a data item in a DLEP Destination Update message, or 432 a Link Characteristics Request message, to indicate the desire for 433 the partner to grant additional credits in order for data transfer to 434 proceed on the session. If the corresponding DLEP Destination Up or 435 Destination Announce message for this session did not contain a 436 Credit Grant data item, indicating that credits are to be used on the 437 session, then receipt of the Credit Request data item MUST be 438 considered as an error by the receiver, requiring termination of the 439 DLEP peer session. 441 The Credit Request data item contains the following fields: 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Data Item Type | Length | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 Data Item Type: TBD 451 Length: 0 453 10. Security Considerations 455 The extension introduces a mechanism for destination-specific flow 456 control between a router and modem supporting the DLEP protocol. The 457 extension does not introduce any additional threats above those 458 documented in [DLEP]. 459 The mitigation strategy documented in that document is sufficient to 460 secure operation of this extension. 462 11. IANA Considerations 463 This section specifies requests to IANA. 465 11.1. Registrations 467 This specification defines three (3) new entries in the repository 468 entitled "Data Item Type Values for the Dynamic Link Event Protocol 469 (DLEP)". Assignments from that registry are requested for: 471 o Credit Grant 473 o Credit Request 475 o Credit Window Status 477 The specification also defines an extension to the DLEP protocol. An 478 assignment from the repository entitled "Extension Type Values for 479 the Dynamic Link Event Protocol (DLEP)" is requested for: 481 o Credit Windowing 483 In addition, the specification defines two (2) new DLEP status codes. 484 Assignments from the repository entitled "Status Code Values for the 485 Dynamic Link Event Protocol (DLEP)" are requested for: 487 o Credit Window Out of Sync 489 o Credit Use Rejected 491 12. Acknowledgements 493 The author would like to acknowledge and thank the members of the 494 MANET working group, who have provided valuable insight. 495 Specifically, the author would like to thank Lou Berger, David 496 Wiggins, Justin Dean, Brian Amundson, Rick Taylor, John Dowdell, 497 Shawn Jury, and Darryl Satterwhite. 499 13. References 501 13.1. Normative References 503 [DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 504 Berry, "Dynamic Link Exchange Protocol (DLEP)", draft- 505 ietf-manet-dlep-22 IETF draft, March 2016. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 509 RFC2119, March 1997, 510 . 512 13.2. Informative References 514 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 515 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 516 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 517 February 2010, . 519 Author's Address 521 Stan Ratliff 522 VT iDirect 523 13861 Sunrise Valley Drive, Suite 300 524 Herndon, VA 20171 525 USA 527 Email: sratliff@idirect.net