draft-ietf-manet-credit-window-05.txt   draft-ietf-manet-credit-window-06.txt 
Mobile Ad hoc Networks Working Group S. Ratliff Mobile Ad hoc Networks Working Group S. Ratliff
Internet-Draft VT iDirect Internet-Draft VT iDirect
Intended status: Standards Track October 31, 2016 Intended status: Standards Track October 31, 2016
Expires: May 4, 2017 Expires: May 4, 2017
Credit Windowing extension for DLEP Credit Windowing extension for DLEP
draft-ietf-manet-credit-window-05 draft-ietf-manet-credit-window-06
Abstract Abstract
This draft describes an extension to the DLEP protocol to provide a This draft describes an extension to the DLEP protocol to provide a
credit-windowing scheme analogous to that in RFC5578 for destination- credit-windowing scheme for destination-specific flow control.
specific flow control.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6. DLEP Messages for Credit-Window Extension . . . . . . . . . . 5 6. DLEP Messages for Credit-Window Extension . . . . . . . . . . 5
7. DLEP Status Codes for Credit-Window Extension . . . . . . . . 5 7. DLEP Status Codes for Credit-Window Extension . . . . . . . . 5
8. DLEP Data Items for Credit-Window Extension . . . . . . . . . 5 8. DLEP Data Items for Credit-Window Extension . . . . . . . . . 5
8.1. DLEP Destination Up Message . . . . . . . . . . . . . . . 6 9. Credit Window Data Item Definitions . . . . . . . . . . . . . 6
8.2. DLEP Destination Announce Message . . . . . . . . . . . . 6 9.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 6
8.3. DLEP Destination Up Response Message . . . . . . . . . . 6 9.2. Credit Window Status . . . . . . . . . . . . . . . . . . 7
8.4. DLEP Destination Announce Response Message . . . . . . . 7 9.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 8
8.5. DLEP Destination Update Message . . . . . . . . . . . . . 8 9.4. DLEP Destination Up Message . . . . . . . . . . . . . . . 9
8.6. DLEP Link Characteristics Request Message . . . . . . . . 8 9.5. DLEP Destination Announce Message . . . . . . . . . . . . 9
9. Credit Window Data Item Definitions . . . . . . . . . . . . . 8 9.6. DLEP Destination Up Response Message . . . . . . . . . . 9
9.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 8 9.7. DLEP Destination Announce Response Message . . . . . . . 10
9.2. Credit Window Status . . . . . . . . . . . . . . . . . . 9 9.8. DLEP Destination Update Message . . . . . . . . . . . . . 11
9.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 11 9.9. DLEP Link Characteristics Request Message . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 12 11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. Normative References . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
In the world of radio-based networking, there are modems that need In the world of radio-based networking, there are modems that need
fine-grained flow control over traffic ingressing from a LAN fine-grained flow control over traffic ingressing from a LAN
connection, bound for transmission over a Radio Frequency (RF) link. connection, bound for transmission over a Radio Frequency (RF) link.
The need for such fine-grained control can exist for multiple The need for such fine-grained control can exist for multiple
reasons. For example, radio devices are typically connected to the reasons. For example, radio devices are typically connected to the
network by Ethernet. The capacity of an Ethernet link is normally network by Ethernet. The capacity of an Ethernet link is normally
skipping to change at page 3, line 4 skipping to change at page 2, line 51
possibility of overruns and dropped traffic. This is exacerbated by possibility of overruns and dropped traffic. This is exacerbated by
the fact that RF link capacity can vary from moment to moment, for an the fact that RF link capacity can vary from moment to moment, for an
indeterminate amount of time. Additionally, the capacity of the link indeterminate amount of time. Additionally, the capacity of the link
can vary greatly depending on the destination, due to factors such as can vary greatly depending on the destination, due to factors such as
obstructions or multipath fading. obstructions or multipath fading.
These challenges motivate the requirement for a fine-grained flow These challenges motivate the requirement for a fine-grained flow
control in radio-based communications - one that can support control in radio-based communications - one that can support
different window sizes for each destination accessed across the RF different window sizes for each destination accessed across the RF
network. To address this requirement, this document describes an network. To address this requirement, this document describes an
extension to the Dynamic Link Event Protocol ([DLEP]), allowing for a extension to the Dynamic Link Exchange Protocol ([DLEP]), allowing
Credit windowing scheme to be implemented on a destination-by- for a Credit windowing scheme to be implemented on a destination-by-
destination basis. destination basis.
2. Requirements 2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [RFC2119]. 14, RFC 2119 [RFC2119].
3. Overview 3. Overview
This protocol extension to DLEP describes a credit windowing scheme This protocol extension to DLEP describes a credit windowing scheme
analogous to the one documented in [RFC5578]. In this scheme, data for flow control of data over the RF network. In this scheme, data
plane traffic flowing between the router and modem is controlled by plane traffic flowing between the router and modem is controlled by
the availability of credits. Credits are expressed as if two the availability of credits. Credits are expressed as if two
unidirectional windows exist between the modem and router. This unidirectional windows exist between the modem and router. This
document identifies these windows as the 'Modem Receive Window', or document identifies these windows as the 'Modem Receive Window', or
MRW, and the 'Router Receive Window', or RRW. The responsibility of MRW, and the 'Router Receive Window', or RRW. The responsibility of
granting credits lies with the receiver on a window - that is, on the granting credits lies with the receiver on a window - that is, on the
MRW, the modem is responsible for granting credits to the router, MRW, the modem is responsible for granting credits to the router,
allowing it (the router) to send data plane traffic to the modem. allowing it (the router) to send data plane traffic to the modem.
Likewise, the router is responsible for granting credits on the RRW, Likewise, the router is responsible for granting credits on the RRW,
which allows the modem to send data plane traffic to the router. which allows the modem to send data plane traffic to the router.
Credits represent the number of data plane octets, or an increment in 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 the number of data plane octets, that can be sent on a given window
at the MAC layer to the receiver. at the MAC layer to the receiver.
4. Terminology 4. Terminology
In general, the draft uses the same terminology as specified in the In general, the document uses the same terminology as specified in
core DLEP draft [DLEP]. In addition, the draft uses the following the core DLEP document [DLEP]. In addition, the document uses the
terms: following terms:
o Modem Receive Window, or MRW. The MRW represents a logical, o Modem Receive Window, or MRW. The MRW represents a logical,
unidirectional window for traffic flowing from the router to the unidirectional window for traffic flowing from the router to the
modem. modem.
o Router Receive Window, or RRW. The RRW represents a logical, o Router Receive Window, or RRW. The RRW represents a logical,
unidirectional window for traffic flowing from the modem to the unidirectional window for traffic flowing from the modem to the
router. router.
5. Operation 5. Operation
DLEP peers supporting this extension MUST include a DLEP 'Extensions DLEP peers supporting this extension MUST include a DLEP 'Extensions
Supported' data item, including the value TBD representing this Supported' data item, including the value TBD1 representing this
extension in the appropriate DLEP Session Initialization and Session extension in the appropriate DLEP Session Initialization and Session
Initialization Response messages. Initialization Response messages.
Credits are managed on a destination-specific basis - separate credit Credits are managed on a destination-specific basis - separate credit
counts MUST be maintained for each destination requiring the service. counts MUST be maintained for each destination requiring the service.
Credits MUST NOT be applied to the DLEP session that exists between Credits MUST NOT be applied to the DLEP session that exists between
routers and modems; they are applied only to the data plane traffic. routers and modems; they are applied only to the data plane traffic.
There are no default values for either the initial credit window or There are no default values for either the initial credit window or
the credit increments. the credit increments.
skipping to change at page 5, line 36 skipping to change at page 5, line 31
7. DLEP Status Codes for Credit-Window Extension 7. DLEP Status Codes for Credit-Window Extension
The credit-windowing extension introduces two additional DLEP status The credit-windowing extension introduces two additional DLEP status
code: code:
+------------+--------+-------------+-------------------------------+ +------------+--------+-------------+-------------------------------+
| Status | Value | Failure | Reason | | Status | Value | Failure | Reason |
| Code | | Mode | | | Code | | Mode | |
+------------+--------+-------------+-------------------------------+ +------------+--------+-------------+-------------------------------+
| Credit | TBD | Continue | Credit counts are out-of-sync | | Credit | TBD2 | Continue | Credit counts are out-of-sync |
| Window Out | | | between sender and receiver | | Window Out | | | between sender and receiver |
| of Sync | | | on the destination. | | of Sync | | | on the destination. |
| Credit Use | TBD | Continue | Credit counts cannot be used | | Credit Use | TBD3 | Continue | Credit counts cannot be used |
| Rejected | | | for the destination. | | Rejected | | | for the destination. |
+------------+--------+-------------+-------------------------------+ +------------+--------+-------------+-------------------------------+
8. DLEP Data Items for Credit-Window Extension 8. DLEP Data Items for Credit-Window Extension
The extension introduces 3 DLEP data items: The extension introduces 3 DLEP data items:
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Type Code | Description | | Type Code | Description |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| TBD | Credit Grant (Section 9.1) | | TBD4 | Credit Grant (Section 9.1) |
| TBD | Credit Window Status (Section 9.2) | | TBD5 | Credit Window Status (Section 9.2) |
| TBD | Credit Request (Section 9.3) | | 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 Credit Grant (Section 9.1)
data item. The value of the credit increment is at the discretion of
the implementation. If use of credits is accepted by the receiver,
the value in the Credit Grant data item in the Destination Up message
MUST be used as the initial value for the appropriate window.
If the Destination Up message does not contain the Credit Grant data
item, credits MUST NOT be used for that destination.
8.2. DLEP Destination Announce Message
If use of credits is required for the destination, then the
Destination Announce message MUST contain one Credit Grant
(Section 9.1) data item. The value of the credit increment is at the
discretion of the implementation. The receiver of the Destination
Announce message MUST use the value in Credit Grant as the initial
value for the appropriate window.
If the Destination Announce message does not contain the Credit Grant
data item, credits MUST NOT be used for that destination.
8.3. DLEP Destination Up Response Message
If the corresponding Destination Up message contained a Credit Grant
(Section 9.1) data item, the Destination Up Response message MUST
contain either:
o a Credit Grant (Section 9.1) data item, to initialize the
receiver's window, or
o a Status Data Item, containing the 'Credit Use Rejected' status
code. Optional text MAY be included with the Status Data Item to
further clarify the reason for the rejection.
Likewise, if the corresponding Destination Up message did not contain
a Credit Grant (Section 9.1) data item, the receiver MUST conclude
that credits are NOT to be used for the destination, and therefore,
the Destination Up Response message MUST NOT contain a Credit Grant
(Section 9.1) data item.
The receiver of Destination Up Response MUST use the received Credit
Grant value to initialize the appropriate window (e.g., the MRW value
for routers, the RRW value for modems).
When an implementation detects a mismatch in the presence or absence
of credit window data items between the DLEP Destination Up and
Destination Up Response messages (e.g, the Destination Up message was
sent using credits but the received Destination Up Response message
does NOT include credits), the implementation detecting the credit-
use mismatch MUST terminate the destination by issuing a Destination
Down message with a status code of 'Credit Window Out of Sync', and
continue processing on other DLEP destinations.
8.4. DLEP Destination Announce Response Message
If the corresponding Destination Announce message contained a Credit
Grant (Section 9.1) data item, the Destination Announce Response
message MUST contain either:
o a Credit Grant (Section 9.1) data item, to initialize the
receiver's window, or
o a Status Data Item, containing the 'Credit Use Rejected' status
code. Optional text MAY be included with the Status Data Item to
further clarify the reason for the rejection
Likewise, if the corresponding Destination Announce message did not
contain a Credit Grant (Section 9.1) data item, the receiver MUST
conclude that credits are NOT to be used for the destination, and
therefore, the Destination Announce Response message MUST NOT contain
a Credit Grant (Section 9.1) data item.
The receiver of Destination Announce Response MUST use the received
Credit Grant value to initialize the appropriate window (e.g., the
MRW value for routers, the RRW value for modems).
When an implementation detects a mismatch in the presence or absence
of credit window data items between the DLEP Destination Announce and
Destination Announce Response messages (e.g, the Destination Announce
message was sent using credits but the received Destination Up
Response message does NOT include credits), the implementation
detecting the credit-use mismatch MUST terminate the destination by
issuing a Destination Down message with a status code of 'Credit
Window Out of Sync', and continue processing on other DLEP
destinations.
8.5. DLEP Destination Update Message
If the corresponding Destination Up or Destination Announce message
contained the Credit Grant data item, the Destination Update message
MAY contain one of each of the following data items:
o Credit Grant (Section 9.1)
o Credit Window Status (Section 9.2)
o Credit Request (Section 9.3)
DLEP peers supporting the extension MAY format and send a DLEP
Destination Update message solely for the purposes of maintaining the
credit windows. In cases where a peer already has information
requiring a Destination Update message, (e.g., a change in Latency on
the link), the credit data items MAY be included in addition to that
information.
8.6. DLEP Link Characteristics Request Message
If the corresponding Destination Up or Destination Announce message
contained the credit Grant data item, the Link Characteristics
Request message MAY contain the following data item:
o Credit Request (Section 9.3)
DLEP peers supporting the extension MAY format and send a DLEP Link
Characteristics Request message solely for the purposes of
maintaining the credit windows. In cases where a peer already has
information requiring a Link Characteristics Request message, the
Credit Request data MAY be included in addition to that information.
9. Credit Window Data Item Definitions 9. Credit Window Data Item Definitions
9.1. Credit Grant 9.1. Credit Grant
The Credit Grant data item is sent from a DLEP participant to grant The Credit Grant data item is sent from a DLEP participant to grant
an increment to credits on a window. The value in a Credit Grant an increment to credits on a window. The value in a Credit Grant
Data Item represents an increment to be added to any existing credits Data Item represents an increment to be added to any existing credits
available on the window. available on the window.
If credits are to used on a destination, the sender of the DLEP If credits are to used on a destination, the sender of the DLEP
skipping to change at page 9, line 27 skipping to change at page 6, line 39
The Credit Grant data item contains the following fields: The Credit Grant data item contains the following fields:
0 1 2 3 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 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment | | Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment | | Credit Increment (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD4
Length: 8 Length: 8
Credit Increment: A 64-bit unsigned integer representing the Credit Increment: A 64-bit unsigned integer representing the
additional credits, in octets, to be assigned to the credit additional credits, in octets, to be assigned to the credit
window. window.
Since credits can only be granted by the receiver on a window, the 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 applicable credit window (either the MRW or the RRW) is derived from
the sender of the grant. The Credit Increment MUST NOT cause the the sender of the grant. The Credit Increment MUST NOT cause the
skipping to change at page 10, line 39 skipping to change at page 7, line 50
Implementations issuing Destinaton Down due to credit count Implementations issuing Destinaton Down due to credit count
mismatches MUST supply a DLEP Status item, with the status code of mismatches MUST supply a DLEP Status item, with the status code of
'Credit Window Out of Sync', as defined in this document. 'Credit Window Out of Sync', as defined in this document.
If a DLEP message contains both the Credit Grant (Section 9.1) data If a DLEP message contains both the Credit Grant (Section 9.1) data
item and the Credit Window Status (Section 9.2) data item, item and the Credit Window Status (Section 9.2) data item,
implementations MUST first apply the Credit Grant (Section 9.1) data implementations MUST first apply the Credit Grant (Section 9.1) data
item before comparing the credit counts contained in Credit Window item before comparing the credit counts contained in Credit Window
Status (Section 9.2). Status (Section 9.2).
It is recommended that implementations issue a DLEP Destination It is RECOMMENDED that implementations issue a DLEP Destination
Update with a Credit Window Status data item at a configurable Update with a Credit Window Status data item at a configurable
multiple of the DLEP Heartbeat timer, to serve as a continuing check multiple of the DLEP Heartbeat timer, to serve as a continuing check
on synchronization of the credit windows for a destination. on synchronization of the credit windows for a destination.
The Credit Window Status data item contains the following fields: The Credit Window Status data item contains the following fields:
0 1 2 3 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 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modem Receive Window Value : | Modem Receive Window Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Modem Receive Window Value | : Modem Receive Window Value (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Receive Window Value : | Router Receive Window Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Router Receive Window Value | : Router Receive Window Value (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD5
Length: 16 Length: 16
Modem Receive Window Value: A 64-bit unsigned integer, indicating Modem Receive Window Value: A 64-bit unsigned integer, indicating
the current number of credits, in octets, available on the Modem the current number of credits, in octets, available on the Modem
Receive Window, for the destination referred to by the message. Receive Window, for the destination referred to by the message.
Router Receive Window Value: A 64-bit unsigned integer, indicating Router Receive Window Value: A 64-bit unsigned integer, indicating
the current number of credits, in octets, available on the Router the current number of credits, in octets, available on the Router
Receive Window, for the destination referred to by the message. Receive Window, for the destination referred to by the message.
skipping to change at page 11, line 41 skipping to change at page 8, line 45
9.3. Credit Request 9.3. Credit Request
The Credit Request data item MAY be sent from either DLEP The Credit Request data item MAY be sent from either DLEP
participant, as a data item in a DLEP Destination Update message, or participant, as a data item in a DLEP Destination Update message, or
a Link Characteristics Request message, to indicate the desire for a Link Characteristics Request message, to indicate the desire for
the partner to grant additional credits in order for data transfer to the partner to grant additional credits in order for data transfer to
proceed on the session. If the corresponding DLEP Destination Up or proceed on the session. If the corresponding DLEP Destination Up or
Destination Announce message for this session did not contain a Destination Announce message for this session did not contain a
Credit Grant data item, indicating that credits are to be used on the Credit Grant data item, indicating that credits are to be used on the
session, then receipt of the Credit Request data item MUST be session, then receipt of the Credit Request data item MUST be
considered as an error by the receiver, requiring termination of the considered as an error by the receiver, requiring a response message
DLEP peer session. that includes a Status Data Item with the code set to "Credit Window
out of Sync'.
If credits are supported on the destination, then the receiver of a
Credit Request Data Item SHOULD issue a Destination Update message,
with a Credit Grant Data Item, giving the peer an increment of
credits for the destination.
The Credit Request data item contains the following fields: The Credit Request data item contains the following fields:
0 1 2 3 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 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD Data Item Type: TBD6
Length: 0 Length: 0
The credit-windowing data items are inserted into DLEP messages as
follows:
9.4. DLEP Destination Up Message
If use of credits is desired for the destination, then the
Destination Up message MUST contain one Credit Grant (Section 9.1)
data item. The value of the credit increment is at the discretion of
the implementation. If use of credits is accepted by the receiver,
the value in the Credit Grant data item in the Destination Up message
MUST be used as the initial value for the appropriate window.
If the Destination Up message does not contain the Credit Grant data
item, credits MUST NOT be used for that destination.
9.5. DLEP Destination Announce Message
If use of credits is required for the destination, then the
Destination Announce message MUST contain one Credit Grant
(Section 9.1) data item. The value of the credit increment is at the
discretion of the implementation. The receiver of the Destination
Announce message MUST use the value in Credit Grant as the initial
value for the appropriate window.
If the Destination Announce message does not contain the Credit Grant
data item, credits MUST NOT be used for that destination.
9.6. DLEP Destination Up Response Message
If the corresponding Destination Up message contained a Credit Grant
(Section 9.1) data item, the Destination Up Response message MUST
contain either:
o a Credit Grant (Section 9.1) data item, to initialize the
receiver's window, or
o a Status Data Item, containing the 'Credit Use Rejected' status
code. Optional text MAY be included with the Status Data Item to
further clarify the reason for the rejection.
Likewise, if the corresponding Destination Up message did not contain
a Credit Grant (Section 9.1) data item, the receiver MUST conclude
that credits are NOT to be used for the destination, and therefore,
the Destination Up Response message MUST NOT contain a Credit Grant
(Section 9.1) data item.
The receiver of Destination Up Response MUST use the received Credit
Grant value to initialize the appropriate window (e.g., the MRW value
for routers, the RRW value for modems).
When an implementation detects a mismatch in the presence or absence
of credit window data items between the DLEP Destination Up and
Destination Up Response messages (e.g, the Destination Up message was
sent using credits but the received Destination Up Response message
does NOT include credits), the implementation detecting the credit-
use mismatch MUST terminate the destination by issuing a Destination
Down message with a status code of 'Credit Window Out of Sync', and
continue processing on other DLEP destinations.
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
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 Announce and
Destination Announce Response messages (e.g, the Destination Announce
message was sent using credits but the received Destination Up
Response message does NOT include credits), the implementation
detecting the credit-use mismatch MUST terminate the destination by
issuing a Destination Down message with a status code of 'Credit
Window Out of Sync', and continue processing on other DLEP
destinations.
9.8. DLEP Destination Update Message
If the corresponding Destination Up or Destination Announce message
contained the Credit Grant data item, the Destination Update message
MAY contain one of each of the following data items:
o Credit Grant (Section 9.1)
o Credit Window Status (Section 9.2)
o Credit Request (Section 9.3)
DLEP peers supporting the extension MAY format and send a DLEP
Destination Update message solely for the purposes of maintaining the
credit windows. In cases where a peer already has information
requiring a Destination Update message, (e.g., a change in Latency on
the link), the credit data items MAY be included in addition to that
information.
9.9. DLEP Link Characteristics Request Message
If the corresponding Destination Up or Destination Announce message
contained the credit Grant data item, the Link Characteristics
Request message MAY contain the following data item:
o Credit Request (Section 9.3)
DLEP peers supporting the extension MAY format and send a DLEP Link
Characteristics Request message solely for the purposes of
maintaining the credit windows. In cases where a peer already has
information requiring a Link Characteristics Request message, the
Credit Request data MAY be included in addition to that information.
10. Security Considerations 10. Security Considerations
The extension introduces a mechanims for destination-specific flow The extension introduces a mechanims for destination-specific flow
control between a router and modem supporting the DLEP protocol. The control between a router and modem supporting the DLEP protocol. The
extension does not introduce any additional threats above thos extension does not introduce any additional threats above those
documented in [DLEP]. The mitigation strategy described in that documented in [DLEP]. The approach taken to security in that
document is sufficient to secure operation of this extension. document applies when implementing this extension.
11. IANA Considerations 11. IANA Considerations
This section specifies requests to IANA. This section specifies requests to IANA.
11.1. Registrations 11.1. Registrations
This specification defines three (3) new entries in the repository This specification defines three (3) new entries in the repository
entitled "Data Item Type Values for the Dynamic Link Event Protocol entitled "Data Item Type Values for the Dynamic Link Exchange
(DLEP)". Assignments from that registry are requested for: Protocol (DLEP)". Assignments from that registry are requested for:
o Credit Grant o Credit Grant
o Credit Request o Credit Request
o Credit Window Status o Credit Window Status
The specification also defines an extension to the DLEP protocol. An The specification also defines an extension to the DLEP protocol. An
assignment from the repository entitled "Extension Type Values for assignment from the repository entitled "Extension Type Values for
the Dynamic Link Event Protocol (DLEP)" is requested for: the Dynamic Link Exchange Protocol (DLEP)" is requested for:
o Credit Windowing o Credit Windowing
In addition, the specification defines two (2) new DLEP status codes. In addition, the specification defines two (2) new DLEP status codes.
Assignments from the repository entitled "Status Code Values for the Assignments from the repository entitled "Status Code Values for the
Dynamic Link Event Protocol (DLEP)" are requested for: Dynamic Link Exchange Protocol (DLEP)" are requested for:
o Credit Window Out of Sync o Credit Window Out of Sync
o Credit Use Rejected o Credit Use Rejected
12. Acknowledgements 12. Acknowledgements
The author would like to acknowledge and thank the members of the The author would like to acknowledge and thank the members of the
MANET working group, who have provided valuable insight. MANET working group, who have provided valuable insight.
Specifically, the author would like to thank Lou Berger, David Specifically, the author would like to thank Lou Berger, David
Wiggins, Justin Dean, Brian Amundson, Rick Taylor, John Dowdell, Wiggins, Justin Dean, Brian Amundson, Rick Taylor, John Dowdell,
Shawn Jury, and Darryl Satterwhite. Shawn Jury, and Darryl Satterwhite.
13. References 13. Normative References
13.1. Normative References
[DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. [DLEP] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", draft- Berry, "Dynamic Link Exchange Protocol (DLEP)", draft-
ietf-manet-dlep-25 IETF draft, October 2016. ietf-manet-dlep-25 IETF draft, October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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 Author's Address
Stan Ratliff Stan Ratliff
VT iDirect VT iDirect
13861 Sunrise Valley Drive, Suite 300 13861 Sunrise Valley Drive, Suite 300
Herndon, VA 20171 Herndon, VA 20171
USA USA
Email: sratliff@idirect.net Email: sratliff@idirect.net
 End of changes. 28 change blocks. 
181 lines changed or deleted 176 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/