Mobile Ad hoc Networks Working Group S. Ratliff Internet-Draft VT iDirect Intended status: Standards Track October 16, 2015 Expires: April 18, 2016 Credit Windowing extension for DLEP draft-ietf-manet-credit-window-00 Abstract Extends the DLEP protocol to provide a credit-windowing scheme analogous to that in RFC5578 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 April 18, 2016. Copyright Notice Copyright (c) 2015 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 April 18, 2016 [Page 1] Internet-Draft Credit Windowing extension for DLEP October 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. DLEP Messages for Credit-Window Extension . . . . . . . . . . 4 6. DLEP Data Items for Credit-Window Extension . . . . . . . . . 4 6.1. DLEP Destination Up Message . . . . . . . . . . . . . . . 4 6.2. DLEP Destination Up Response Message . . . . . . . . . . 4 6.3. DLEP Destination Update Message . . . . . . . . . . . . . 5 7. Credit Window Data Item Definitions . . . . . . . . . . . . . 5 7.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 5 7.2. Credit Window Status . . . . . . . . . . . . . . . . . . 6 7.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 the RF. 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 RF, 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 Event Protocol ([DLEP]), allowing for a Credit windowing scheme to be implemented on a destination-by- destination basis. 2. Terminology Ratliff Expires April 18, 2016 [Page 2] Internet-Draft Credit Windowing extension for DLEP October 2015 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. 3. Overview This protocol extension to DLEP describes a credit windowing scheme analogous to the one documented in [RFC5578]. 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 octets, or an increment in the number of plane octets, that can be sent on a given window at OSI Layer 2 to the receiver. 4. Operation DLEP peers supporting this extension MUST include a DLEP 'Extensions Supported' data item, including the value TBD representing this extension in the appropriate DLEP Session Initialization and Session Initialization Response messages. Credits are managed on a destination-specific basis; that is, 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. Credits MUST only be granted by the receiver on a given window. In the case of the MRW, only the modem can grant credits. Conversely, only the router can grant credits for the RRW. There are no default values for either the initial credit window or the credit increments. The number of credits needed for a given transmission is the length of the data portion of the packet at OSI Layer 2. When sending data to a credit enabled peer, the sender MUST decrement the appropriate Ratliff Expires April 18, 2016 [Page 3] Internet-Draft Credit Windowing extension for DLEP October 2015 window by the size of the data being sent, prior to encapsulation at OSI Layer 2. When traffic is received, the receiver MUST decrement its own window after decapsulation at OSI Layer 2. 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. 5. DLEP Messages for Credit-Window Extension The credit-windowing extension does not introduce any additional DLEP signals or messages. 6. DLEP Data Items for Credit-Window Extension The extension introduces 3 DLEP data items: +------------+-------------------------------------+ | Type Code | Description | +------------+-------------------------------------+ | TBD | Credit Grant (Section 7.1) | | TBD | Credit Window Status (Section 7.2) | | TBD | Credit Request (Section 7.3) | +------------+-------------------------------------+ Descriptions of the data items are included below. The credit- windowing data items are inserted into DLEP messages as follows: 6.1. DLEP Destination Up Message If use of credits is required for the destination, then the Destination Up message MUST contain one Credit Grant (Section 7.1) data item. The value of the credit increment is at the discretion of the implementation. The receiver of the Destination Up message MUST use the value in Credit Grant 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. 6.2. DLEP Destination Up Response Message If the corresponding Destination Up message contained the Credit Grant data item, the Destination Up Response message MUST contain one Credit Window Status (Section 7.2) data item. The receiver of Destination Up Response MUST use the appropriate window value in Credit Window Status (e.g., the MRW value for Ratliff Expires April 18, 2016 [Page 4] Internet-Draft Credit Windowing extension for DLEP October 2015 routers, the RRW value for modems) to initialize the originator's receive window. The case where a Destination Up message was sent with a Credit Grant data item, and the corresponding Destination Up Response message is received without a a Credit Window status data item MUST be treated as an error requiring termination of the DLEP peer session. 6.3. DLEP Destination Update Message If the corresponding Destination Up 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 7.1) o Credit Request (Section 7.3) o Credit Window Status (Section 7.2) DLEP peers supporting the extension MAY format and send a DLEP Destination Update message solely for the purposes of maintaining the credit windows - that is, a Destination Update message MAY carry only a Credit Grant data item for the peer, or a Credit request. In cases where a peer already has information requiring a Destination Update message, (e.g., a change in Current Data Rate, for example), the credit data items MAY be included in addition to that information. 7. Credit Window Data Item Definitions 7.1. Credit Grant The Credit Grant data item is sent from a DLEP participant to grant an increment to credits on a window. The Credit Grant data item MAY appear in the DLEP Destination Up and Destination Update messages. The value in a Credit Grant data item represents an increment to be added to any existing credits available on the window. Upon successful receipt and processing of a Credit Grant data item, the receiver MUST respond with a message containing a Credit Window Status data item to report the updated aggregate values for synchronization purposes, and if initializing a new credit window, granting initial credits. Ratliff Expires April 18, 2016 [Page 5] Internet-Draft Credit Windowing extension for DLEP October 2015 When DLEP peers desire to employ the credit-windowing extension, the peer originating the Destination Up message MUST supply an initial, non-zero value as the credit increment of the receive window it controls (i.e., the MRW, or RRW). When receiving a Credit Grant data item on a Destination Up message, the receiver MUST take one of the following actions: 1. Reject the use of credits for this destination, via the Destination Up Response message containing a Status data item with a status code of 'Request Denied'. (See status codes in [DLEP]), or 2. Initialize the appropriate window value of zero, then apply the increment specified in the Credit Grant data item. If the initialization completes successfully, the receiver MUST respond to the Destination Up message with a Destination Up Response message that contains a Credit Window Status data item, initializing its receive window. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 8 Reserved: A 64-bit unsigned integer representing the additional credits 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 window to overflow; if this condition occurs, implementations MUST set the credit window to the maximum value contained in a 64-bit quantity. 7.2. Credit Window Status Ratliff Expires April 18, 2016 [Page 6] Internet-Draft Credit Windowing extension for DLEP October 2015 When credits are used, the receiver of a Credit Grant data item MUST respond with a DLEP message containing a Credit Window Status data item to acknowledge the Credit Grant. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Receive Window Value : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Router Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 16 Modem Receive Window Value: A 64-bit unsigned integer, indicating the current number of credits 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 available on the Router Receive Window, for the destination referred to by the message. 7.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, 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 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 termination of the DLEP peer session. 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 Ratliff Expires April 18, 2016 [Page 7] Internet-Draft Credit Windowing extension for DLEP October 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 0 8. Security Considerations The extension introduces a mechanism for destination-specific flow control between a router and modem supporting the DLEP protocol. In cases where an adversary can access the network segment on which the router and modem are attached, the following threats are possibe: 1. An attacker could act as either modem or router, establishing a session with the DLEP peer. This session could be used to flood the session with various requests, amounting to a denial of service attack. In these environments, implementations MUST employ [TLS], as the certificate verification in that protocol will verify the identity of devices attempting to connect. 2. An attacker could mount a Man In The Middle (MITM) attack, altering the credit values supplied by the DLEP peers. Such an alteration could cause either (a) a cessation of traffic (by setting credit values to 0), or (b) overruns and drops (e.g., by setting credit values to the maximum value of a 64-bit integer). In these environments, implementations MUST employ [TLS], leveraging the message protection mechanisms in that protocol. 9. IANA Considerations This section specifies requests to IANA. 9.1. Registrations This specification defines three (3) new data items for DLEP. Assignments from the DLEP data item registry are requested for: o Credit Grant o Credit Request o Credit Window Status The specification also defined an extension to the DLEP protocol. An assignment from the DLEP extension registry is requested for 'Credit Windowing'. 10. Acknowledgements Ratliff Expires April 18, 2016 [Page 8] Internet-Draft Credit Windowing extension for DLEP October 2015 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, Justin Dean, Brian Amundson, Rick Taylor, John Dowdell, Shawn Jury, and Darryl Satterwhite. 11. References 11.1. Normative References [DLEP] Ratliff, S., Berry, B., Jury, S., Satterwhite, D., Taylor, R., "Dynamic Link Exchange Protocol (DLEP)", http://tools.ietf.org/html/draft-ietf-manet-dlep-17 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . 11.2. Informative References [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, February 2010, . Author's Address Stan Ratliff VT iDirect 13861 Sunrise Valley Drive, Suite 300 Herndon, VA 20171 USA Email: sratliff@idirect.net Ratliff Expires April 18, 2016 [Page 9]