Mobile Ad hoc Networks Working Group                          S. Ratliff
Internet-Draft                                                VT iDirect
Intended status: Standards Track                        October 16, 2015                        February 4, 2016
Expires: April 18, August 7, 2016

                  Credit Windowing extension for DLEP
                   draft-ietf-manet-credit-window-00
                   draft-ietf-manet-credit-window-01

Abstract

   Extends

   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 April 18, August 7, 2016.

Copyright Notice

   Copyright (c) 2015 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.  Terminology  Overview  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Overview .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  DLEP Messages for Credit-Window Extension . . . . . . . . . .   4
   6.  DLEP Status Codes for Credit-Window Extension . . . . . . . .   4
   7.  DLEP Data Items for Credit-Window Extension . . . . . . . . .   4
     6.1.   5
     7.1.  DLEP Destination Up Message . . . . . . . . . . . . . . .   4
     6.2.   5
     7.2.  DLEP Destination Up Response Message  . . . . . . . . . .   4
     6.3.   5
     7.3.  DLEP Destination Update Message . . . . . . . . . . . . .   5
   7.   6
     7.4.  DLEP Link Characteristics Request Message . . . . . . . .   6
   8.  Credit Window Data Item Definitions . . . . . . . . . . . . .   5
     7.1.   6
     8.1.  Credit Grant  . . . . . . . . . . . . . . . . . . . . . .   5
     7.2.   7
     8.2.  Credit Window Status  . . . . . . . . . . . . . . . . . .   6
     7.3.   7
     8.3.  Credit Request  . . . . . . . . . . . . . . . . . . . . .   7
   8.   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  10
     10.1.  Registrations  . . . . . . . . . . . . . . . . . . . . . .   8
   10.  10
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11.  10
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  10
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  10
     12.2.  Informative References . . . . . . . . . . . . . . . . .   9  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9  11

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
   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 plane octets, or an increment in
   the number of data plane octets, that can be sent on a given window
   at OSI Layer 2 to the receiver.

3.  Terminology

   In general, the draft uses the same terminology as specified in the
   core DLEP draft [DLEP].  In addition, the draft 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.

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

   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

   When DLEP peers desire to employ the data portion of credit-windowing extension, the
   peer originating the Destination Up 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).

   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 Grant data item, initializing its
   receive window.

   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 OSI Layer 2.  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
   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 Status Codes for Credit-Window Extension

   The credit-windowing extension introduces one additional DLEP status
   code:

   +------------+--------+-------------+-------------------------------+
   | Status     | Value  | Failure     | Reason                        |
   | Code       |        | Mode        |                               |
   +------------+--------+-------------+-------------------------------+
   | Credit     | TBD    | Terminate   | Credit counts are out-of-sync |
   | Window Out |        |             | between sender and receiver   |
   | of Sync    |        |             | on the destination.           |
   +------------+--------+-------------+-------------------------------+

7.  DLEP Data Items for Credit-Window Extension

   The extension introduces 3 DLEP data items:

           +------------+-------------------------------------+

   +------------+------------------------------------------------------+
   | Type Code  | Description                                          |
           +------------+-------------------------------------+
   +------------+------------------------------------------------------+
   | TBD        | Credit Grant (Section 7.1) 8.1)                           |
   | TBD        | Credit Window Status (Section 7.2) 8.2)                   |
   | TBD        | Credit Request (Section 7.3) 8.3)                         |
           +------------+-------------------------------------+
   +------------+------------------------------------------------------+

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

6.1.

7.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) 8.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.

7.2.  DLEP Destination Up Response Message

   If the corresponding Destination Up message contained the a Credit Grant
   (Section 8.1) data item, the Destination Up Response message MUST
   also contain one a Credit Window Status Grant (Section 7.2) 8.1) data item.

   The receiver of

   Likewise, if the corresponding Destination Up Response MUST use the appropriate
   window value in Credit Window Status message did not contain
   a Credit Grant (Section 8.1) data item, the Destination Up Response
   message MUST NOT contain a Credit Grant (Section 8.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) to initialize the originator's
   receive window.

   The case where modems).

   When an implementation detects a mismatch in the presence or absence
   of credit window data items between the DLEP Destination Up message was sent with a Credit Grant
   data item, and the corresponding
   Destination Up Response message is
   received without messages, the implementation detecting the
   mismatch MUST terminate the session by issuing a Peer Termination
   message with a Credit Window status data item MUST be treated
   as an error requiring termination code of 'XXXX', and transition to the DLEP peer session.

6.3. Session
   Termination state.

7.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) 8.1)

   o  Credit Window Status (Section 7.2) 8.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. windows.  In cases where a peer already has information
   requiring a Destination Update message, (e.g., a change in Current Data Rate, for example), Latency on
   the link), the credit data items MAY be included in addition to that
   information.

7.

7.4.  DLEP Link Characteristics Request Message

   If the corresponding Destination Up message contained the credit
   Grant data item, the Link Characteristics Request message MAY contain
   the following data item:

   o  Credit Request (Section 8.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.

8.  Credit Window Data Item Definitions

7.1.
8.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.

   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  Upon
   successful receipt and processing of a Credit Grant data item.

   If the initialization completes successfully, item, the
   receiver MUST respond to the Destination Up message with a Destination Up Response message that contains containing a Credit Window
   Status data item, item to report the updated aggregate values for
   synchronization purposes, and if initializing
   its receive window. a new credit window,
   granting initial credits.

   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.

8.2.  Credit Window Status

   When credits are used, DLEP session peers MAY use the Credit Window
   Status data item to maintain synchronization of credit counts.  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 MAY either 1.  Attempt resynchronization using Credit
   Grant, if applicable, or 2.  Issue a DLEP Destination Down message,
   to clear credit counts on the session.

   Implementations issuing Destinaton Down 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 8.1) data
   item and the Credit Window Status (Section 8.2) data item,
   implementations MUST
   respond with first apply the Credit Grant (Section 8.1) data
   item before comparing the credit counts contained in Credit Window
   Status (Section 8.2).

   It is recommended that implementations issue a DLEP message containing Destination
   Update with a Credit Window Status data item at a configurable
   multiple of the DLEP Heartbeat timer, to acknowledge serve as a continuing check
   on synchronization of the Credit Grant. 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                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   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.

8.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type                | Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Data Item Type:  TBD

   Length:  0

8.

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

10.  IANA Considerations

   This section specifies requests to IANA.

9.1.

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

   In addition, the specification defines an additional DLEP status
   code.  An assignment from the DLEP registry for status codes is
   requested for 'Credit Window Out of Sync'.

11.  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, Justin Dean,
   Brian Amundson, Rick Taylor, John Dowdell, Shawn Jury, and Darryl
   Satterwhite.

11.

12.  References

11.1.

12.1.  Normative References

   [DLEP]     Ratliff, S., Berry, B., Jury, S., Satterwhite, D., Taylor, R., and B.
              Berry, "Dynamic Link Exchange Protocol (DLEP)",
              http://tools.ietf.org/html/draft-ietf-manet-dlep-17 draft-
              ietf-manet-dlep-18 IETF draft, February 2015.

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

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/
              RFC5246, 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

11.2.

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