Mobile Ad hoc Networks Working Group S. Ratliff Internet-Draft VT iDirect Intended status: Standards Track November 13, 2016 Expires: May 17, 2017 Credit Windowing extension for DLEP draft-ietf-manet-credit-window-07 Abstract This draft describes an extension to the DLEP protocol to provide a credit-windowing scheme for destination-specific flow control. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 17, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Ratliff Expires May 17, 2017 [Page 1] Internet-Draft Credit Windowing extension for DLEP November 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. DLEP Messages for Credit-Window Extension . . . . . . . . . . 5 7. DLEP Status Codes for Credit-Window Extension . . . . . . . . 5 8. DLEP Data Items for Credit-Window Extension . . . . . . . . . 5 9. Credit Window Data Item Definitions . . . . . . . . . . . . . 6 9.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 6 9.2. Credit Window Status . . . . . . . . . . . . . . . . . . 7 9.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 8 10. Credit Data Item Use in DLEP Messages . . . . . . . . . . . . 9 10.1. DLEP Destination Up Message . . . . . . . . . . . . . . 9 10.2. DLEP Destination Announce Message . . . . . . . . . . . 9 10.3. DLEP Destination Up Response Message . . . . . . . . . . 9 10.4. DLEP Destination Announce Response Message . . . . . . . 10 10.5. DLEP Destination Update Message . . . . . . . . . . . . 11 10.6. DLEP Link Characteristics Request Message . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12.1. Registrations . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 14. Normative References . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction In the world of radio-based networking, there are modems that need fine-grained flow control over traffic ingressing from a LAN connection, bound for transmission over a Radio Frequency (RF) link. The need for such fine-grained control can exist for multiple reasons. For example, radio devices are typically connected to the network by Ethernet. The capacity of an Ethernet link is normally far superior to that of the wireless medium, leading to the possibility of overruns and dropped traffic. This is exacerbated by the fact that RF link capacity can vary from moment to moment, for an indeterminate amount of time. Additionally, the capacity of the link can vary greatly depending on the destination, due to factors such as obstructions or multipath fading. These challenges motivate the requirement for a fine-grained flow control in radio-based communications - one that can support different window sizes for each destination accessed across the RF network. To address this requirement, this document describes an extension to the Dynamic Link Exchange Protocol ([DLEP]), allowing Ratliff Expires May 17, 2017 [Page 2] Internet-Draft Credit Windowing extension for DLEP November 2016 for a Credit windowing scheme to be implemented on a destination-by- destination basis. 2. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Overview This protocol extension to DLEP describes a credit windowing scheme for flow control of data over the RF network. In this scheme, data plane traffic flowing between the router and modem is controlled by the availability of credits. Credits are expressed as if two unidirectional windows exist between the modem and router. This document identifies these windows as the 'Modem Receive Window', or MRW, and the 'Router Receive Window', or RRW. The responsibility of granting credits lies with the receiver on a window - that is, on the MRW, the modem is responsible for granting credits to the router, allowing it (the router) to send data plane traffic to the modem. Likewise, the router is responsible for granting credits on the RRW, which allows the modem to send data plane traffic to the router. Credits represent the number of data plane octets, or an increment in the number of data plane octets, that can be sent on a given window at the MAC layer to the receiver. 4. Terminology In general, the document uses the same terminology as specified in the core DLEP document [DLEP]. In addition, the document uses the following terms: o Modem Receive Window, or MRW. The MRW represents a logical, unidirectional window for traffic flowing from the router to the modem. o Router Receive Window, or RRW. The RRW represents a logical, unidirectional window for traffic flowing from the modem to the router. 5. Operation DLEP peers supporting this extension MUST include a DLEP 'Extensions Supported' data item, including the value TBD1 representing this Ratliff Expires May 17, 2017 [Page 3] Internet-Draft Credit Windowing extension for DLEP November 2016 extension in the appropriate DLEP Session Initialization and Session Initialization Response messages. Credits are managed on a destination-specific basis - separate credit counts MUST be maintained for each destination requiring the service. Credits MUST NOT be applied to the DLEP session that exists between routers and modems; they are applied only to the data plane traffic. There are no default values for either the initial credit window or the credit increments. When DLEP peers desire to employ the credit-windowing extension, the peer originating the Destination Up or Destination Announce message MUST supply a Credit Grant data item with an initial, non-zero value as the increment of the window the originator controls (i.e., the MRW, or RRW). If the credit-windowing extension is used on a destination, credits MUST be employed in both directions (e.g., both the MRW and RRW MUST be initialized and managed). When receiving a Credit Grant data item on a Destination Up or Destination Announce message, the receiver MUST take one of the following actions: 1. If the receiver of the Credit Grant data item determines that use of credits is not supported for the destination, the reciver MUST reject the use of credits for this destination, via the Destination Up Response or Destination Announce Response message containing a Status data item with a status code of 'Credit Use Rejected'. The reasons that a device might reject use of credits are proprietary in nature, but could include situations like conflict with existing quality of service algorithms already in use, or perceived infrequency of traffic to the destination, such that the credit scheme induces more overhead than is desired. 2. If the receiver supports use of credits for the destination, it MUST initialize the appropriate window value to zero, then apply the increment specified in the Credit Grant data item. The receiver then MUST issue the corresponding response message (either Destination Up Response or Destination Announce Response) with a Credit Grant Data Item to complete bi-directional window initialization. If credit-windowing initialization is successfully completed, Data plane traffic would then flow between the DLEP peers, with said peers accounting for the traffic sent/received by decrementing the appropriate credit counts. Ratliff Expires May 17, 2017 [Page 4] Internet-Draft Credit Windowing extension for DLEP November 2016 The number of credits needed for a given transmission is the length of the data portion of the packet at the MAC layer. When sending data to a credit enabled peer, the sender MUST decrement the appropriate window by the size of the data being sent, prior to encapsulation at the MAC layer. When traffic is received, the receiver MUST decrement its own window after decapsulation at the MAC layer. When the number of available credits to the destination reaches 0, the sender MUST stop sending data plane traffic to the destination, until additional credits are granted by the receiver. 6. DLEP Messages for Credit-Window Extension The credit-windowing extension does not introduce any additional DLEP signals or messages. 7. DLEP Status Codes for Credit-Window Extension The credit-windowing extension introduces two additional DLEP status code: +------------+--------+-------------+-------------------------------+ | Status | Value | Failure | Reason | | Code | | Mode | | +------------+--------+-------------+-------------------------------+ | Credit | TBD2 | Continue | Credit counts are out-of-sync | | Window Out | | | between sender and receiver | | of Sync | | | on the destination. | | Credit Use | TBD3 | Continue | Credit counts cannot be used | | Rejected | | | for the destination. | +------------+--------+-------------+-------------------------------+ 8. DLEP Data Items for Credit-Window Extension The extension introduces 3 DLEP data items: +------------+------------------------------------------------------+ | Type Code | Description | +------------+------------------------------------------------------+ | TBD4 | Credit Grant (Section 9.1) | | TBD5 | Credit Window Status (Section 9.2) | | TBD6 | Credit Request (Section 9.3) | +------------+------------------------------------------------------+ Ratliff Expires May 17, 2017 [Page 5] Internet-Draft Credit Windowing extension for DLEP November 2016 9. Credit Window Data Item Definitions 9.1. Credit Grant The Credit Grant data item is sent from a DLEP participant to grant an increment to credits on a window. The value in a Credit Grant Data Item represents an increment to be added to any existing credits available on the window. If credits are to used on a destination, the sender of the DLEP Destination Up or Destination Announce messages MUST include a Credit Grant Data Item to initialize the credit window. If present in Destination Up or Destination Announce, the receiver MUST either place a Credit Grant Data Item in the Destination Up Response or Destination Announce Response message, or reject use of credits by sending the response message with a Status Data Item containing the 'Credit Use Rejected' status code. If credits are used on a destination, the Credit Grant Data Item MAY appear in a Destination Update message. Upon successful receipt and processing of a Credit Grant data item received in Destination Update, the receiver MUST respond with another Destination Update message containing a Credit Window Status data item to report the updated aggregate values for synchronization purposes. The Credit Grant data item contains the following fields: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credit Increment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credit Increment (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD4 Length: 8 Credit Increment: A 64-bit unsigned integer representing the additional credits, in octets, to be assigned to the credit window. Since credits can only be granted by the receiver on a window, the applicable credit window (either the MRW or the RRW) is derived from the sender of the grant. The Credit Increment MUST NOT cause the Ratliff Expires May 17, 2017 [Page 6] Internet-Draft Credit Windowing extension for DLEP November 2016 window to overflow; if this condition occurs, implementations MUST set the credit window to the maximum value contained in a 64-bit quantity. 9.2. Credit Window Status During normal operation, DLEP session peers may disagree about the number of available credits. Operational credit mismatches can occur due to packets in transit on the wire, or sequencing of sending and receiving packets (e.g. packets are sent prior to processing DLEP control information). DLEP session peers SHOULD make every effort to keep credit counts in sync, and implementations MAY use the Credit Window Status data item to maintain that synchronization. This data item is informational only; it is used to inform the receiving peer of the current credit counts for both the MRW and RRW, from the perspective of the sender. Upon receipt of a Credit Window Status data item, an implementation SHOULD compare its own credit counts with that of the originator. If the receiver of Credit Window Status detects that the local credit counts are not synchronized with the originator, the receiving implementation is free to employ various algorithms to re-establish close synchrnoization, such as: o Allow the DLEP peer to completely exhaust its credits prior to re- supplying them via a Credit Grant Data Item, or o Immediately attempt resynchronization using an additional Credit Grant, if applicable, or o Issue a DLEP Destination Down message, to clear credit counts on the session, and then re-establish the destination via a Destination Up or Destination Announce message. o Other re-synchronization algorithms as deemed appropriate. Implementations issuing Destinaton Down due to credit count mismatches MUST supply a DLEP Status item, with the status code of 'Credit Window Out of Sync', as defined in this document. If a DLEP message contains both the Credit Grant (Section 9.1) data item and the Credit Window Status (Section 9.2) data item, implementations MUST first apply the Credit Grant (Section 9.1) data item before comparing the credit counts contained in Credit Window Status (Section 9.2). It is RECOMMENDED that implementations issue a DLEP Destination Update with a Credit Window Status data item at a configurable Ratliff Expires May 17, 2017 [Page 7] Internet-Draft Credit Windowing extension for DLEP November 2016 multiple of the DLEP Heartbeat timer, to serve as a continuing check on synchronization of the credit windows for a destination. The Credit Window Status data item contains the following fields: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Modem Receive Window Value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Modem Receive Window Value (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Receive Window Value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Router Receive Window Value (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD5 Length: 16 Modem Receive Window Value: A 64-bit unsigned integer, indicating the current number of credits, in octets, available on the Modem Receive Window, for the destination referred to by the message. Router Receive Window Value: A 64-bit unsigned integer, indicating the current number of credits, in octets, available on the Router Receive Window, for the destination referred to by the message. 9.3. Credit Request The Credit Request data item MAY be sent from either DLEP participant, as a data item in a DLEP Destination Update message, or a Link Characteristics Request message, to indicate the desire for the partner to grant additional credits in order for data transfer to proceed on the session. If the corresponding DLEP Destination Up or Destination Announce message for this session did not contain a Credit Grant data item, indicating that credits are to be used on the session, then receipt of the Credit Request data item MUST be considered as an error by the receiver, requiring a response message that includes a Status Data Item with the code set to "Credit Window out of Sync'. If credits are supported on the destination, then the receiver of a Credit Request Data Item SHOULD issue a Destination Update message, Ratliff Expires May 17, 2017 [Page 8] Internet-Draft Credit Windowing extension for DLEP November 2016 with a Credit Grant Data Item, giving the peer an increment of credits for the destination. The Credit Request data item contains the following fields: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD6 Length: 0 10. Credit Data Item Use in DLEP Messages 10.1. DLEP Destination Up Message If use of credits is desired for the destination, then the Destination Up message MUST contain one Credit Grant (Section 9.1) data item. The value of the credit increment is at the discretion of the implementation. If use of credits is accepted by the receiver, the value in the Credit Grant data item in the Destination Up message MUST be used as the initial value for the appropriate window. If the Destination Up message does not contain the Credit Grant data item, credits MUST NOT be used for that destination. 10.2. DLEP Destination Announce Message If use of credits is required for the destination, then the Destination Announce message MUST contain one Credit Grant (Section 9.1) data item. The value of the credit increment is at the discretion of the implementation. The receiver of the Destination Announce message MUST use the value in Credit Grant as the initial value for the appropriate window. If the Destination Announce message does not contain the Credit Grant data item, credits MUST NOT be used for that destination. 10.3. DLEP Destination Up Response Message If the corresponding Destination Up message contained a Credit Grant (Section 9.1) data item, the Destination Up Response message MUST contain either: Ratliff Expires May 17, 2017 [Page 9] Internet-Draft Credit Windowing extension for DLEP November 2016 o a Credit Grant (Section 9.1) data item, to initialize the receiver's window, or o a Status Data Item, containing the 'Credit Use Rejected' status code. Optional text MAY be included with the Status Data Item to further clarify the reason for the rejection. Likewise, if the corresponding Destination Up message did not contain a Credit Grant (Section 9.1) data item, the receiver MUST conclude that credits are NOT to be used for the destination, and therefore, the Destination Up Response message MUST NOT contain a Credit Grant (Section 9.1) data item. The receiver of Destination Up Response MUST use the received Credit Grant value to initialize the appropriate window (e.g., the MRW value for routers, the RRW value for modems). When an implementation detects a mismatch in the presence or absence of credit window data items between the DLEP Destination Up and Destination Up Response messages (e.g, the Destination Up message was sent using credits but the received Destination Up Response message does NOT include credits), the implementation detecting the credit- use mismatch MUST terminate the destination by issuing a Destination Down message with a status code of 'Credit Window Out of Sync', and continue processing on other DLEP destinations. 10.4. DLEP Destination Announce Response Message If the corresponding Destination Announce message contained a Credit Grant (Section 9.1) data item, the Destination Announce Response message MUST contain either: o a Credit Grant (Section 9.1) data item, to initialize the receiver's window, or o a Status Data Item, containing the 'Credit Use Rejected' status code. Optional text MAY be included with the Status Data Item to further clarify the reason for the rejection Likewise, if the corresponding Destination Announce message did not contain a Credit Grant (Section 9.1) data item, the receiver MUST conclude that credits are NOT to be used for the destination, and therefore, the Destination Announce Response message MUST NOT contain a Credit Grant (Section 9.1) data item. The receiver of Destination Announce Response MUST use the received Credit Grant value to initialize the appropriate window (e.g., the MRW value for routers, the RRW value for modems). Ratliff Expires May 17, 2017 [Page 10] Internet-Draft Credit Windowing extension for DLEP November 2016 When an implementation detects a mismatch in the presence or absence of credit window data items between the DLEP Destination Announce and Destination Announce Response messages (e.g, the Destination Announce message was sent using credits but the received Destination Up Response message does NOT include credits), the implementation detecting the credit-use mismatch MUST terminate the destination by issuing a Destination Down message with a status code of 'Credit Window Out of Sync', and continue processing on other DLEP destinations. 10.5. DLEP Destination Update Message If the corresponding Destination Up or Destination Announce message contained the Credit Grant data item, the Destination Update message MAY contain one of each of the following data items: o Credit Grant (Section 9.1) o Credit Window Status (Section 9.2) o Credit Request (Section 9.3) DLEP peers supporting the extension MAY format and send a DLEP Destination Update message solely for the purposes of maintaining the credit windows. In cases where a peer already has information requiring a Destination Update message, (e.g., a change in Latency on the link), the credit data items MAY be included in addition to that information. 10.6. DLEP Link Characteristics Request Message If the corresponding Destination Up or Destination Announce message contained the credit Grant data item, the Link Characteristics Request message MAY contain the following data item: o Credit Request (Section 9.3) DLEP peers supporting the extension MAY format and send a DLEP Link Characteristics Request message solely for the purposes of maintaining the credit windows. In cases where a peer already has information requiring a Link Characteristics Request message, the Credit Request data MAY be included in addition to that information. 11. Security Considerations The extension introduces a mechanims for destination-specific flow control between a router and modem supporting the DLEP protocol. The extension does not introduce any additional threats above those Ratliff Expires May 17, 2017 [Page 11] Internet-Draft Credit Windowing extension for DLEP November 2016 documented in [DLEP]. The approach taken to security in that document applies when implementing this extension. 12. IANA Considerations This section specifies requests to IANA. 12.1. Registrations This specification defines three (3) new entries in the repository entitled "Data Item Type Values for the Dynamic Link Exchange Protocol (DLEP)". Assignments from that registry are requested for: o Credit Grant o Credit Request o Credit Window Status The specification also defines an extension to the DLEP protocol. An assignment from the repository entitled "Extension Type Values for the Dynamic Link Exchange Protocol (DLEP)" is requested for: o Credit Windowing In addition, the specification defines two (2) new DLEP status codes. Assignments from the repository entitled "Status Code Values for the Dynamic Link Exchange Protocol (DLEP)" are requested for: o Credit Window Out of Sync o Credit Use Rejected 13. Acknowledgements The author would like to acknowledge and thank the members of the MANET working group, who have provided valuable insight. Specifically, the author would like to thank Lou Berger, David Wiggins, Justin Dean, Brian Amundson, Rick Taylor, John Dowdell, Shawn Jury, and Darryl Satterwhite. 14. Normative References [DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", draft- ietf-manet-dlep-25 IETF draft, October 2016. Ratliff Expires May 17, 2017 [Page 12] Internet-Draft Credit Windowing extension for DLEP November 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Author's Address Stan Ratliff VT iDirect 13861 Sunrise Valley Drive, Suite 300 Herndon, VA 20171 USA Email: sratliff@idirect.net Ratliff Expires May 17, 2017 [Page 13]