idnits 2.17.1 draft-ietf-manet-credit-window-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 (November 13, 2016) is 2721 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-25 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group S. Ratliff 3 Internet-Draft VT iDirect 4 Intended status: Standards Track November 13, 2016 5 Expires: May 17, 2017 7 Credit Windowing extension for DLEP 8 draft-ietf-manet-credit-window-07 10 Abstract 12 This draft describes an extension to the DLEP protocol to provide a 13 credit-windowing scheme for destination-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 May 17, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 9. Credit Window Data Item Definitions . . . . . . . . . . . . . 6 58 9.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 6 59 9.2. Credit Window Status . . . . . . . . . . . . . . . . . . 7 60 9.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 8 61 10. Credit Data Item Use in DLEP Messages . . . . . . . . . . . . 9 62 10.1. DLEP Destination Up Message . . . . . . . . . . . . . . 9 63 10.2. DLEP Destination Announce Message . . . . . . . . . . . 9 64 10.3. DLEP Destination Up Response Message . . . . . . . . . . 9 65 10.4. DLEP Destination Announce Response Message . . . . . . . 10 66 10.5. DLEP Destination Update Message . . . . . . . . . . . . 11 67 10.6. DLEP Link Characteristics Request Message . . . . . . . 11 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 12.1. Registrations . . . . . . . . . . . . . . . . . . . . . 12 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 14. Normative References . . . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 In the world of radio-based networking, there are modems that need 78 fine-grained flow control over traffic ingressing from a LAN 79 connection, bound for transmission over a Radio Frequency (RF) link. 80 The need for such fine-grained control can exist for multiple 81 reasons. For example, radio devices are typically connected to the 82 network by Ethernet. The capacity of an Ethernet link is normally 83 far superior to that of the wireless medium, leading to the 84 possibility of overruns and dropped traffic. This is exacerbated by 85 the fact that RF link capacity can vary from moment to moment, for an 86 indeterminate amount of time. Additionally, the capacity of the link 87 can vary greatly depending on the destination, due to factors such as 88 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 Exchange Protocol ([DLEP]), allowing 95 for a 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 for flow control of data over the RF network. 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 document uses the same terminology as specified in 127 the core DLEP document [DLEP]. In addition, the document uses the 128 following 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 TBD1 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 If the credit-windowing extension is used on a destination, credits 159 MUST be employed in both directions (e.g., both the MRW and RRW MUST 160 be initialized and managed). 162 When receiving a Credit Grant data item on a Destination Up or 163 Destination Announce message, the receiver MUST take one of the 164 following actions: 166 1. If the receiver of the Credit Grant data item determines that use 167 of credits is not supported for the destination, the reciver MUST 168 reject the use of credits for this destination, via the 169 Destination Up Response or Destination Announce Response message 170 containing a Status data item with a status code of 'Credit Use 171 Rejected'. The reasons that a device might reject use of credits 172 are proprietary in nature, but could include situations like 173 conflict with existing quality of service algorithms already in 174 use, or perceived infrequency of traffic to the destination, such 175 that the credit scheme induces more overhead than is desired. 177 2. If the receiver supports use of credits for the destination, it 178 MUST initialize the appropriate window value to zero, then apply 179 the increment specified in the Credit Grant data item. The 180 receiver then MUST issue the corresponding response message 181 (either Destination Up Response or Destination Announce Response) 182 with a Credit Grant Data Item to complete bi-directional window 183 initialization. 185 If credit-windowing initialization is successfully completed, Data 186 plane traffic would then flow between the DLEP peers, with said peers 187 accounting for the traffic sent/received by decrementing the 188 appropriate credit counts. 190 The number of credits needed for a given transmission is the length 191 of the data portion of the packet at the MAC layer. When sending 192 data to a credit enabled peer, the sender MUST decrement the 193 appropriate window by the size of the data being sent, prior to 194 encapsulation at the MAC layer. When traffic is received, the 195 receiver MUST decrement its own window after decapsulation at the MAC 196 layer. 198 When the number of available credits to the destination reaches 0, 199 the sender MUST stop sending data plane traffic to the destination, 200 until additional credits are granted by the receiver. 202 6. DLEP Messages for Credit-Window Extension 204 The credit-windowing extension does not introduce any additional DLEP 205 signals or messages. 207 7. DLEP Status Codes for Credit-Window Extension 209 The credit-windowing extension introduces two additional DLEP status 210 code: 212 +------------+--------+-------------+-------------------------------+ 213 | Status | Value | Failure | Reason | 214 | Code | | Mode | | 215 +------------+--------+-------------+-------------------------------+ 216 | Credit | TBD2 | Continue | Credit counts are out-of-sync | 217 | Window Out | | | between sender and receiver | 218 | of Sync | | | on the destination. | 219 | Credit Use | TBD3 | Continue | Credit counts cannot be used | 220 | Rejected | | | for the destination. | 221 +------------+--------+-------------+-------------------------------+ 223 8. DLEP Data Items for Credit-Window Extension 225 The extension introduces 3 DLEP data items: 227 +------------+------------------------------------------------------+ 228 | Type Code | Description | 229 +------------+------------------------------------------------------+ 230 | TBD4 | Credit Grant (Section 9.1) | 231 | TBD5 | Credit Window Status (Section 9.2) | 232 | TBD6 | Credit Request (Section 9.3) | 233 +------------+------------------------------------------------------+ 235 9. Credit Window Data Item Definitions 237 9.1. Credit Grant 239 The Credit Grant data item is sent from a DLEP participant to grant 240 an increment to credits on a window. The value in a Credit Grant 241 Data Item represents an increment to be added to any existing credits 242 available on the window. 244 If credits are to used on a destination, the sender of the DLEP 245 Destination Up or Destination Announce messages MUST include a Credit 246 Grant Data Item to initialize the credit window. If present in 247 Destination Up or Destination Announce, the receiver MUST either 248 place a Credit Grant Data Item in the Destination Up Response or 249 Destination Announce Response message, or reject use of credits by 250 sending the response message with a Status Data Item containing the 251 'Credit Use Rejected' status code. 253 If credits are used on a destination, the Credit Grant Data Item MAY 254 appear in a Destination Update message. Upon successful receipt and 255 processing of a Credit Grant data item received in Destination 256 Update, the receiver MUST respond with another Destination Update 257 message containing a Credit Window Status data item to report the 258 updated aggregate values for synchronization purposes. 260 The Credit Grant data item contains the following fields: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Data Item Type | Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Credit Increment | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Credit Increment (continued) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Data Item Type: TBD4 274 Length: 8 276 Credit Increment: A 64-bit unsigned integer representing the 277 additional credits, in octets, to be assigned to the credit 278 window. 280 Since credits can only be granted by the receiver on a window, the 281 applicable credit window (either the MRW or the RRW) is derived from 282 the sender of the grant. The Credit Increment MUST NOT cause the 283 window to overflow; if this condition occurs, implementations MUST 284 set the credit window to the maximum value contained in a 64-bit 285 quantity. 287 9.2. Credit Window Status 289 During normal operation, DLEP session peers may disagree about the 290 number of available credits. Operational credit mismatches can occur 291 due to packets in transit on the wire, or sequencing of sending and 292 receiving packets (e.g. packets are sent prior to processing DLEP 293 control information). DLEP session peers SHOULD make every effort to 294 keep credit counts in sync, and implementations MAY use the Credit 295 Window Status data item to maintain that synchronization. This data 296 item is informational only; it is used to inform the receiving peer 297 of the current credit counts for both the MRW and RRW, from the 298 perspective of the sender. 300 Upon receipt of a Credit Window Status data item, an implementation 301 SHOULD compare its own credit counts with that of the originator. If 302 the receiver of Credit Window Status detects that the local credit 303 counts are not synchronized with the originator, the receiving 304 implementation is free to employ various algorithms to re-establish 305 close synchrnoization, such as: 307 o Allow the DLEP peer to completely exhaust its credits prior to re- 308 supplying them via a Credit Grant Data Item, or 310 o Immediately attempt resynchronization using an additional Credit 311 Grant, if applicable, or 313 o Issue a DLEP Destination Down message, to clear credit counts on 314 the session, and then re-establish the destination via a 315 Destination Up or Destination Announce message. 317 o Other re-synchronization algorithms as deemed appropriate. 319 Implementations issuing Destinaton Down due to credit count 320 mismatches MUST supply a DLEP Status item, with the status code of 321 'Credit Window Out of Sync', as defined in this document. 323 If a DLEP message contains both the Credit Grant (Section 9.1) data 324 item and the Credit Window Status (Section 9.2) data item, 325 implementations MUST first apply the Credit Grant (Section 9.1) data 326 item before comparing the credit counts contained in Credit Window 327 Status (Section 9.2). 329 It is RECOMMENDED that implementations issue a DLEP Destination 330 Update with a Credit Window Status data item at a configurable 331 multiple of the DLEP Heartbeat timer, to serve as a continuing check 332 on synchronization of the credit windows for a destination. 334 The Credit Window Status data item contains the following fields: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Data Item Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Modem Receive Window Value : 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 : Modem Receive Window Value (continued) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Router Receive Window Value : 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 : Router Receive Window Value (continued) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Data Item Type: TBD5 352 Length: 16 354 Modem Receive Window Value: A 64-bit unsigned integer, indicating 355 the current number of credits, in octets, available on the Modem 356 Receive Window, for the destination referred to by the message. 358 Router Receive Window Value: A 64-bit unsigned integer, indicating 359 the current number of credits, in octets, available on the Router 360 Receive Window, for the destination referred to by the message. 362 9.3. Credit Request 364 The Credit Request data item MAY be sent from either DLEP 365 participant, as a data item in a DLEP Destination Update message, or 366 a Link Characteristics Request message, to indicate the desire for 367 the partner to grant additional credits in order for data transfer to 368 proceed on the session. If the corresponding DLEP Destination Up or 369 Destination Announce message for this session did not contain a 370 Credit Grant data item, indicating that credits are to be used on the 371 session, then receipt of the Credit Request data item MUST be 372 considered as an error by the receiver, requiring a response message 373 that includes a Status Data Item with the code set to "Credit Window 374 out of Sync'. 376 If credits are supported on the destination, then the receiver of a 377 Credit Request Data Item SHOULD issue a Destination Update message, 378 with a Credit Grant Data Item, giving the peer an increment of 379 credits for the destination. 381 The Credit Request data item contains the following fields: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Data Item Type | Length | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Data Item Type: TBD6 391 Length: 0 393 10. Credit Data Item Use in DLEP Messages 395 10.1. DLEP Destination Up Message 397 If use of credits is desired for the destination, then the 398 Destination Up message MUST contain one Credit Grant (Section 9.1) 399 data item. The value of the credit increment is at the discretion of 400 the implementation. If use of credits is accepted by the receiver, 401 the value in the Credit Grant data item in the Destination Up message 402 MUST be used as the initial value for the appropriate window. 404 If the Destination Up message does not contain the Credit Grant data 405 item, credits MUST NOT be used for that destination. 407 10.2. DLEP Destination Announce Message 409 If use of credits is required for the destination, then the 410 Destination Announce message MUST contain one Credit Grant 411 (Section 9.1) data item. The value of the credit increment is at the 412 discretion of the implementation. The receiver of the Destination 413 Announce message MUST use the value in Credit Grant as the initial 414 value for the appropriate window. 416 If the Destination Announce message does not contain the Credit Grant 417 data item, credits MUST NOT be used for that destination. 419 10.3. DLEP Destination Up Response Message 421 If the corresponding Destination Up message contained a Credit Grant 422 (Section 9.1) data item, the Destination Up Response message MUST 423 contain either: 425 o a Credit Grant (Section 9.1) data item, to initialize the 426 receiver's window, or 428 o a Status Data Item, containing the 'Credit Use Rejected' status 429 code. Optional text MAY be included with the Status Data Item to 430 further clarify the reason for the rejection. 432 Likewise, if the corresponding Destination Up message did not contain 433 a Credit Grant (Section 9.1) data item, the receiver MUST conclude 434 that credits are NOT to be used for the destination, and therefore, 435 the Destination Up Response message MUST NOT contain a Credit Grant 436 (Section 9.1) data item. 438 The receiver of Destination Up Response MUST use the received Credit 439 Grant value to initialize the appropriate window (e.g., the MRW value 440 for routers, the RRW value for modems). 442 When an implementation detects a mismatch in the presence or absence 443 of credit window data items between the DLEP Destination Up and 444 Destination Up Response messages (e.g, the Destination Up message was 445 sent using credits but the received Destination Up Response message 446 does NOT include credits), the implementation detecting the credit- 447 use mismatch MUST terminate the destination by issuing a Destination 448 Down message with a status code of 'Credit Window Out of Sync', and 449 continue processing on other DLEP destinations. 451 10.4. DLEP Destination Announce Response Message 453 If the corresponding Destination Announce message contained a Credit 454 Grant (Section 9.1) data item, the Destination Announce Response 455 message MUST contain either: 457 o a Credit Grant (Section 9.1) data item, to initialize the 458 receiver's window, or 460 o a Status Data Item, containing the 'Credit Use Rejected' status 461 code. Optional text MAY be included with the Status Data Item to 462 further clarify the reason for the rejection 464 Likewise, if the corresponding Destination Announce message did not 465 contain a Credit Grant (Section 9.1) data item, the receiver MUST 466 conclude that credits are NOT to be used for the destination, and 467 therefore, the Destination Announce Response message MUST NOT contain 468 a Credit Grant (Section 9.1) data item. 470 The receiver of Destination Announce Response MUST use the received 471 Credit Grant value to initialize the appropriate window (e.g., the 472 MRW value for routers, the RRW value for modems). 474 When an implementation detects a mismatch in the presence or absence 475 of credit window data items between the DLEP Destination Announce and 476 Destination Announce Response messages (e.g, the Destination Announce 477 message was sent using credits but the received Destination Up 478 Response message does NOT include credits), the implementation 479 detecting the credit-use mismatch MUST terminate the destination by 480 issuing a Destination Down message with a status code of 'Credit 481 Window Out of Sync', and continue processing on other DLEP 482 destinations. 484 10.5. DLEP Destination Update Message 486 If the corresponding Destination Up or Destination Announce message 487 contained the Credit Grant data item, the Destination Update message 488 MAY contain one of each of the following data items: 490 o Credit Grant (Section 9.1) 492 o Credit Window Status (Section 9.2) 494 o Credit Request (Section 9.3) 496 DLEP peers supporting the extension MAY format and send a DLEP 497 Destination Update message solely for the purposes of maintaining the 498 credit windows. In cases where a peer already has information 499 requiring a Destination Update message, (e.g., a change in Latency on 500 the link), the credit data items MAY be included in addition to that 501 information. 503 10.6. DLEP Link Characteristics Request Message 505 If the corresponding Destination Up or Destination Announce message 506 contained the credit Grant data item, the Link Characteristics 507 Request message MAY contain the following data item: 509 o Credit Request (Section 9.3) 511 DLEP peers supporting the extension MAY format and send a DLEP Link 512 Characteristics Request message solely for the purposes of 513 maintaining the credit windows. In cases where a peer already has 514 information requiring a Link Characteristics Request message, the 515 Credit Request data MAY be included in addition to that information. 517 11. Security Considerations 519 The extension introduces a mechanims for destination-specific flow 520 control between a router and modem supporting the DLEP protocol. The 521 extension does not introduce any additional threats above those 522 documented in [DLEP]. The approach taken to security in that 523 document applies when implementing this extension. 525 12. IANA Considerations 527 This section specifies requests to IANA. 529 12.1. Registrations 531 This specification defines three (3) new entries in the repository 532 entitled "Data Item Type Values for the Dynamic Link Exchange 533 Protocol (DLEP)". Assignments from that registry are requested for: 535 o Credit Grant 537 o Credit Request 539 o Credit Window Status 541 The specification also defines an extension to the DLEP protocol. An 542 assignment from the repository entitled "Extension Type Values for 543 the Dynamic Link Exchange Protocol (DLEP)" is requested for: 545 o Credit Windowing 547 In addition, the specification defines two (2) new DLEP status codes. 548 Assignments from the repository entitled "Status Code Values for the 549 Dynamic Link Exchange Protocol (DLEP)" are requested for: 551 o Credit Window Out of Sync 553 o Credit Use Rejected 555 13. Acknowledgements 557 The author would like to acknowledge and thank the members of the 558 MANET working group, who have provided valuable insight. 559 Specifically, the author would like to thank Lou Berger, David 560 Wiggins, Justin Dean, Brian Amundson, Rick Taylor, John Dowdell, 561 Shawn Jury, and Darryl Satterwhite. 563 14. Normative References 565 [DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 566 Berry, "Dynamic Link Exchange Protocol (DLEP)", draft- 567 ietf-manet-dlep-25 IETF draft, October 2016. 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 Author's Address 576 Stan Ratliff 577 VT iDirect 578 13861 Sunrise Valley Drive, Suite 300 579 Herndon, VA 20171 580 USA 582 Email: sratliff@idirect.net