Mobile Ad hoc Networks Working Group                          S. Ratliff
Internet-Draft                                                VT iDirect
Intended status: Standards Track                        October 31, 2016
Expires: May 4, 2017

                  Credit Windowing extension for DLEP
                   draft-ietf-manet-credit-window-05
                   draft-ietf-manet-credit-window-06

Abstract

   This draft describes an extension to the DLEP protocol to provide a
   credit-windowing scheme analogous to that in RFC5578 for destination-
   specific 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 4, 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4   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
     8.1.  DLEP Destination Up Message . .
   9.  Credit Window Data Item Definitions . . . . . . . . . . . . .   6
     8.2.  DLEP Destination Announce Message
     9.1.  Credit Grant  . . . . . . . . . . . .   6
     8.3.  DLEP Destination Up Response Message . . . . . . . . . .   6
     8.4.  DLEP Destination Announce Response Message  . .
     9.2.  Credit Window Status  . . . . .   7
     8.5.  DLEP Destination Update Message . . . . . . . . . . . . .   8
     8.6.  DLEP Link Characteristics   7
     9.3.  Credit Request Message  . . . . . . . .   8
   9.  Credit Window Data Item Definitions . . . . . . . . . . . . .   8
     9.1.  Credit Grant
     9.4.  DLEP Destination Up Message . . . . . . . . . . . . . . .   9
     9.5.  DLEP Destination Announce Message . . . . . . . .   8
     9.2.  Credit Window Status . . . .   9
     9.6.  DLEP Destination Up Response Message  . . . . . . . . . .   9
     9.7.  DLEP Destination Announce Response Message  . . . .   9
     9.3.  Credit Request . . .  10
     9.8.  DLEP Destination Update Message . . . . . . . . . . . . .  11
     9.9.  DLEP Link Characteristics Request Message . . . . . . . .  11
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  12  11
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Registrations  . . . . . . . . . . . . . . . . . . . . .  12
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     13.1. Normative References  . . . . . . . . . . . . . . . . . .  13
     13.2.  Informative References . . . . . . . . . . . . . . . . .  13  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 Event Exchange Protocol ([DLEP]), allowing
   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
   analogous to
   for flow control of data over the one documented in [RFC5578]. 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 draft document uses the same terminology as specified in
   the core DLEP draft document [DLEP].  In addition, the draft 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 TBD TBD1 representing this
   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.

   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     | TBD TBD2   | Continue    | Credit counts are out-of-sync |
   | Window Out |        |             | between sender and receiver   |
   | of Sync    |        |             | on the destination.           |
   | Credit Use | TBD 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                                          |
   +------------+------------------------------------------------------+
   | TBD TBD4       | Credit Grant (Section 9.1)                           |
   | TBD TBD5       | Credit Window Status (Section 9.2)                   |
   | TBD TBD6       | Credit Request (Section 9.3)                         |
   +------------+------------------------------------------------------+

   Descriptions of the data items are included below.  The credit-
   windowing data items are inserted into DLEP messages as follows:

8.1.  DLEP Destination Up Message

   If use of credits is desired for the destination, then the
   Destination Up message MUST contain one

9.  Credit Window Data Item Definitions

9.1.  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 is sent from a DLEP participant to grant
   an increment to credits on a window.

   If the Destination Up message does not contain the  The value in a Credit Grant data
   item, credits MUST NOT
   Data Item represents an increment to be used for that destination.

8.2.  DLEP Destination Announce Message

   If use of added to any existing credits is required for
   available on the window.

   If credits are to used on a 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 sender of the DLEP
   Destination Up or Destination Announce message messages MUST use the value in include a Credit
   Grant as the initial
   value for Data Item to initialize the appropriate credit window.  If the Destination Announce message does not contain the Credit Grant
   data item, credits MUST NOT be used for that destination.

8.3.  DLEP present in
   Destination Up Response Message

   If the corresponding or Destination Up message contained Announce, the receiver MUST either
   place a Credit Grant
   (Section 9.1) data item, Data Item in the Destination Up Response message MUST
   contain either:

   o  a Credit Grant (Section 9.1) data item, to initialize the
      receiver's window, or

   o
   Destination Announce Response message, or reject use of credits by
   sending the response message with a Status Data Item, Item containing the
   'Credit Use Rejected' status code.  Optional text MAY be included with

   If credits are used on a destination, the Status Credit Grant Data Item to
      further clarify the reason for the rejection.

   Likewise, if the corresponding MAY
   appear in a Destination Up message did not contain Update message.  Upon successful receipt and
   processing of a Credit Grant (Section 9.1) data item, item received in Destination
   Update, the receiver MUST conclude
   that credits are NOT to be used for the destination, and therefore,
   the respond with another Destination Up Response Update
   message MUST NOT contain containing a Credit Grant
   (Section 9.1) Window Status data item.

   The receiver of Destination Up Response MUST use item to report the received
   updated aggregate values for synchronization purposes.

   The Credit Grant value to initialize data item contains the appropriate window (e.g., 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 MRW value
   for routers,
      additional credits, in octets, to be assigned to the RRW value for modems).

   When an implementation detects credit
      window.

   Since credits can only be granted by the receiver on a mismatch in window, the presence or absence
   of
   applicable credit window data items between (either the DLEP Destination Up and
   Destination Up Response messages (e.g, MRW or the Destination Up message was
   sent using credits but RRW) is derived from
   the received Destination Up Response message
   does NOT include credits), sender of the implementation detecting grant.  The Credit Increment MUST NOT cause the credit-
   use mismatch
   window to overflow; if this condition occurs, implementations MUST terminate
   set the destination by issuing a Destination
   Down message with credit window to the maximum value contained in a status code of 'Credit 64-bit
   quantity.

9.2.  Credit Window Out Status

   During normal operation, DLEP session peers may disagree about the
   number of Sync', available credits.  Operational credit mismatches can occur
   due to packets in transit on the wire, or sequencing of sending and
   continue
   receiving packets (e.g. packets are sent prior to processing on other DLEP destinations.

8.4.
   control information).  DLEP Destination Announce Response Message

   If session peers SHOULD make every effort to
   keep credit counts in sync, and implementations MAY use the corresponding Destination Announce message contained a Credit
   Grant (Section 9.1)
   Window Status data item, the Destination Announce Response
   message MUST contain either:

   o  a Credit Grant (Section 9.1) item to maintain that synchronization.  This data item,
   item is informational only; it is used 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 inform the Status Data Item to
      further clarify receiving peer
   of the reason current credit counts for both the rejection

   Likewise, if MRW and RRW, from the corresponding Destination Announce message did not
   contain
   perspective of the sender.

   Upon receipt of a Credit Grant (Section 9.1) Window Status data item, the receiver MUST
   conclude an implementation
   SHOULD compare its own credit counts with that credits are NOT to be used for of the destination, and
   therefore, originator.  If
   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 Window Status detects that the appropriate window (e.g., local credit
   counts are not synchronized with the
   MRW value for routers, originator, the RRW value for modems).

   When an receiving
   implementation detects a mismatch in the presence or absence
   of credit window data items between is free to employ various algorithms to re-establish
   close synchrnoization, such as:

   o  Allow the DLEP Destination Announce and
   Destination Announce Response messages (e.g, the Destination Announce
   message was sent using peer to completely exhaust its credits but the received 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 Up
   Response message does NOT include credits), the implementation
   detecting Down message, to clear credit counts on
      the credit-use mismatch MUST terminate session, and then re-establish the destination by
   issuing via a
      Destination Up or Destination Announce message.

   o  Other re-synchronization algorithms as deemed appropriate.

   Implementations issuing Destinaton Down message with due to credit count
   mismatches MUST supply a DLEP Status item, with the status code of
   'Credit Window Out of Sync', and continue processing on other DLEP
   destinations.

8.5.  DLEP Destination Update Message as defined in this document.

   If the corresponding Destination Up or Destination Announce a DLEP message
   contained contains both the Credit Grant (Section 9.1) data item, the Destination Update message
   MAY contain one of each of
   item and the following Credit Window Status (Section 9.2) data items:

   o item,
   implementations MUST first apply the Credit Grant (Section 9.1)

   o data
   item before comparing the credit counts contained in Credit Window
   Status (Section 9.2)

   o  Credit Request (Section 9.3)

   DLEP peers supporting the extension MAY format and send 9.2).

   It is RECOMMENDED that implementations issue a DLEP Destination
   Update message solely for with a Credit Window Status data item at a configurable
   multiple of the purposes DLEP Heartbeat timer, to serve as a continuing check
   on synchronization of maintaining the credit windows.  In cases where windows for a peer already has information
   requiring a Destination Update message, (e.g., a change 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 Latency octets, available on the link), Modem
      Receive Window, for the credit 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 items item MAY be included sent from either DLEP
   participant, as a data item in addition to that
   information.

8.6. a DLEP Destination Update message, or
   a Link Characteristics Request Message 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
   contained the credit for this session did not contain a
   Credit Grant data item, indicating that credits are to be used on the Link Characteristics
   Request message MAY contain
   session, then receipt of the following data item:

   o Credit Request (Section 9.3)

   DLEP peers supporting data item MUST be
   considered as an error by 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 receiver, requiring a Link Characteristics Request message, the
   Credit Request data MAY be included in addition to response message
   that information.

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 includes a window.  The value in a Credit Grant Status Data Item represents an increment to be added to any existing credits
   available on with the window. code set to "Credit Window
   out of Sync'.

   If credits are to used supported on a the destination, then the sender receiver of the DLEP
   Destination Up or Destination Announce messages MUST include a
   Credit
   Grant Request Data Item to initialize the credit window.  If present in
   Destination Up or Destination Announce, the receiver MUST either
   place SHOULD issue a Credit Grant Data Item in the Destination Up Response or Destination Announce Response Update 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 Item, giving the
   updated aggregate values peer an increment of
   credits for synchronization purposes. the destination.

   The Credit Grant 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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Credit Increment                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Credit Increment                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Data Item Type:  TBD  TBD6

   Length:  8

   Credit Increment:  A 64-bit unsigned integer representing the
      additional credits, in octets, to be assigned to the credit
      window.

   Since  0

   The credit-windowing data items are inserted into DLEP messages as
   follows:

9.4.  DLEP Destination Up Message

   If use of 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 desired for the grant.  The Credit Increment MUST NOT cause destination, then the
   window to overflow; if this condition occurs, implementations
   Destination Up message MUST
   set contain one Credit Grant (Section 9.1)
   data item.  The value of 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 increment is at the
   number discretion of available credits.  Operational credit mismatches can occur
   due to packets in transit on
   the wire, or sequencing implementation.  If use 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 credits is accepted by the receiver,
   the value in sync, and implementations MAY use the Credit
   Window Status data item to maintain that synchronization.  This Grant data item is informational only; it is used to inform in the receiving peer
   of Destination Up message
   MUST be used as the current credit counts initial value for both the MRW and RRW, from appropriate window.

   If the
   perspective of Destination Up message does not contain the sender.

   Upon receipt of a Credit Window Status Grant data
   item, an implementation
   SHOULD compare its own credit counts with credits MUST NOT be used for that of the originator. destination.

9.5.  DLEP Destination Announce Message

   If
   the receiver use of Credit Window Status detects that the local credit
   counts are not synchronized with the originator, the receiving
   implementation credits is free to employ various algorithms to re-establish
   close synchrnoization, such as:

   o  Allow required for the DLEP peer to completely exhaust its credits prior to re-
      supplying them via a destination, then the
   Destination Announce message MUST contain one 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
   (Section 9.1) data item.  The value of the credit counts on increment is at the session, and then re-establish
   discretion of the implementation.  The receiver of 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 message MUST supply a DLEP Status item, with use the status code of
   'Credit Window Out of Sync', as defined value in this document. Credit Grant as the initial
   value for the appropriate window.

   If a DLEP the Destination Announce message contains both does not contain the Credit Grant (Section 9.1) data
   item and the Credit Window Status (Section 9.2)
   data item,
   implementations credits MUST first apply NOT be used for that destination.

9.6.  DLEP Destination Up Response Message

   If the corresponding Destination Up message contained a Credit Grant
   (Section 9.1) data
   item before comparing item, the credit counts contained in Credit Window
   Status (Section 9.2).

   It is recommended that implementations issue a DLEP Destination
   Update with Up Response message MUST
   contain either:

   o  a Credit Window Status Grant (Section 9.1) data item at item, to initialize the
      receiver's window, or

   o  a configurable
   multiple of Status Data Item, containing the DLEP Heartbeat timer, 'Credit Use Rejected' status
      code.  Optional text MAY be included with the Status Data Item to serve as
      further clarify the reason for the rejection.

   Likewise, if the corresponding Destination Up message did not contain
   a continuing check 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 synchronization other DLEP destinations.

9.7.  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 credit windows
   MRW value for routers, the RRW value for modems).

   When an implementation detects a destination.

   The Credit Window Status mismatch in the presence or absence
   of credit window data item contains items between 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 DLEP Destination Announce and
   Destination Announce Response messages (e.g, the current number of credits, in octets, available on Destination Announce
   message was sent using credits but the Modem
      Receive Window, for received Destination Up
   Response message does NOT include credits), the implementation
   detecting the credit-use mismatch MUST terminate the destination referred to by the message.

   Router Receive
   issuing a Destination Down message with a status code of 'Credit
   Window Value:  A 64-bit unsigned integer, indicating
      the current number Out of credits, in octets, available Sync', and continue processing on other DLEP
   destinations.

9.8.  DLEP Destination Update Message

   If the Router
      Receive Window, for corresponding Destination Up or Destination Announce message
   contained the destination referred to by Credit Grant data item, the message.

9.3. Destination Update message
   MAY contain one of each of the following data items:

   o  Credit Request

   The Grant (Section 9.1)

   o  Credit Window Status (Section 9.2)

   o  Credit Request data item (Section 9.3)

   DLEP peers supporting the extension MAY be sent from either format and send a DLEP
   participant, as
   Destination Update message solely for the purposes of maintaining the
   credit windows.  In cases where a data item in peer already has information
   requiring a DLEP Destination Update message, or (e.g., a Link Characteristics Request message, to indicate change in Latency on
   the desire for link), the partner to grant additional credits in order for credit data transfer items MAY be included in addition to
   proceed on the session. that
   information.

9.9.  DLEP Link Characteristics Request Message

   If the corresponding DLEP Destination Up or Destination Announce message for this session did not contain a
   Credit
   contained the credit Grant data item, indicating that credits are to be used on the
   session, then receipt of Link Characteristics
   Request message MAY contain the following data item:

   o  Credit Request data item MUST be
   considered as an error by (Section 9.3)

   DLEP peers supporting the receiver, requiring termination extension MAY format and send a DLEP Link
   Characteristics Request message solely for the purposes of
   maintaining the
   DLEP credit windows.  In cases where a peer session.

   The already has
   information requiring a Link Characteristics Request message, 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:  TBD
   Length:  0 MAY be included in addition to that information.

10.  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 thos those
   documented in [DLEP].  The mitigation strategy described approach taken to security in that
   document is sufficient to secure operation of applies when implementing this extension.

11.  IANA Considerations

   This section specifies requests to IANA.

11.1.  Registrations

   This specification defines three (3) new entries in the repository
   entitled "Data Item Type Values for the Dynamic Link Event 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 Event 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 Event Exchange Protocol (DLEP)" are requested for:

   o  Credit Window Out of Sync

   o  Credit Use Rejected

12.  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.

13.  References

13.1.  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.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

13.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, <http://www.rfc-editor.org/info/rfc5578>.

Author's Address

   Stan Ratliff
   VT iDirect
   13861 Sunrise Valley Drive, Suite 300
   Herndon, VA  20171
   USA

   Email: sratliff@idirect.net