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 (