draft-ietf-manet-credit-window-04.txt   draft-ietf-manet-credit-window-05.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 April 10, 2016 Intended status: Standards Track October 31, 2016
Expires: October 12, 2016 Expires: May 4, 2017
Credit Windowing extension for DLEP Credit Windowing extension for DLEP
draft-ietf-manet-credit-window-04 draft-ietf-manet-credit-window-05
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 analogous to that in RFC5578 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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2016. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 5 8.1. DLEP Destination Up Message . . . . . . . . . . . . . . . 6
8.2. DLEP Destination Announce Message . . . . . . . . . . . . 6 8.2. DLEP Destination Announce Message . . . . . . . . . . . . 6
8.3. DLEP Destination Up Response Message . . . . . . . . . . 6 8.3. DLEP Destination Up Response Message . . . . . . . . . . 6
8.4. DLEP Destination Announce Response Message . . . . . . . 7 8.4. DLEP Destination Announce Response Message . . . . . . . 7
8.5. DLEP Destination Update Message . . . . . . . . . . . . . 7 8.5. DLEP Destination Update Message . . . . . . . . . . . . . 8
8.6. DLEP Link Characteristics Request Message . . . . . . . . 7 8.6. DLEP Link Characteristics Request Message . . . . . . . . 8
9. Credit Window Data Item Definitions . . . . . . . . . . . . . 8 9. Credit Window Data Item Definitions . . . . . . . . . . . . . 8
9.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Credit Grant . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Credit Window Status . . . . . . . . . . . . . . . . . . 9 9.2. Credit Window Status . . . . . . . . . . . . . . . . . . 9
9.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 10 9.3. Credit Request . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 11 11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 12 13.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 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 the RF. The need for such connection, bound for transmission over a Radio Frequency (RF) link.
fine-grained control can exist for multiple reasons. For example, The need for such fine-grained control can exist for multiple
radio devices are typically connected to the network by Ethernet. reasons. For example, radio devices are typically connected to the
The capacity of an Ethernet link is normally far superior to that of network by Ethernet. The capacity of an Ethernet link is normally
the RF, leading to the possibility of overruns and dropped traffic. far superior to that of the wireless medium, leading to the
This is exacerbated by the fact that RF link capacity can vary from possibility of overruns and dropped traffic. This is exacerbated by
moment to moment, for an indeterminate amount of time. Additionally, the fact that RF link capacity can vary from moment to moment, for an
the capacity of the link can vary greatly depending on the indeterminate amount of time. Additionally, the capacity of the link
destination, due to factors such as obstructions or multipath fading. 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 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 Event Protocol ([DLEP]), allowing for a
Credit windowing scheme to be implemented on a destination-by- Credit windowing scheme to be implemented on a destination-by-
destination basis. destination basis.
2. Requirements 2. Requirements
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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.
When DLEP peers desire to employ the credit-windowing extension, the When DLEP peers desire to employ the credit-windowing extension, the
peer originating the Destination Up or Destination Announce message peer originating the Destination Up or Destination Announce message
MUST supply a Credit Grant data item with an initial, non-zero value 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 as the increment of the window the originator controls (i.e., the
MRW, or RRW). 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 When receiving a Credit Grant data item on a Destination Up or
Destination Announce message, the receiver MUST take one of the Destination Announce message, the receiver MUST take one of the
following actions: following actions:
1. Reject the use of credits for this destination, via the 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 Destination Up Response or Destination Announce Response message
containing a Status data item with a status code of 'Credit Use containing a Status data item with a status code of 'Credit Use
Rejected', or Rejected'. The reasons that a device might reject use of credits
are proprietary in nature, but could include situations like
2. Initialize the appropriate window value of zero, then apply the conflict with existing quality of service algorithms already in
increment specified in the Credit Grant data item. use, or perceived infrequency of traffic to the destination, such
that the credit scheme induces more overhead than is desired.
If the initialization completes successfully, the receiver MUST 2. If the receiver supports use of credits for the destination, it
respond to the Destination Up/Destination Announce message with a MUST initialize the appropriate window value to zero, then apply
response message that contains a Credit Grant data item, initializing the increment specified in the Credit Grant data item. The
its receive window. 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.
Data plane traffic would then flow between the DLEP peers, with said If credit-windowing initialization is successfully completed, Data
peers accounting for the traffic sent/received by decrementing the plane traffic would then flow between the DLEP peers, with said peers
accounting for the traffic sent/received by decrementing the
appropriate credit counts. appropriate credit counts.
The number of credits needed for a given transmission is the length 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 of the data portion of the packet at the MAC layer. When sending
data to a credit enabled peer, the sender MUST decrement the data to a credit enabled peer, the sender MUST decrement the
appropriate window by the size of the data being sent, prior to appropriate window by the size of the data being sent, prior to
encapsulation at the MAC layer. When traffic is received, the encapsulation at the MAC layer. When traffic is received, the
receiver MUST decrement its own window after decapsulation at the MAC receiver MUST decrement its own window after decapsulation at the MAC
layer. layer.
skipping to change at page 5, line 19 skipping to change at page 5, line 32
6. DLEP Messages for Credit-Window Extension 6. DLEP Messages for Credit-Window Extension
The credit-windowing extension does not introduce any additional DLEP The credit-windowing extension does not introduce any additional DLEP
signals or messages. signals or messages.
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 Code | Value | Failure | Reason | | Status | Value | Failure | Reason |
| | | Mode | | | Code | | Mode | |
+--------------+----------+------------+----------------------------+ +------------+--------+-------------+-------------------------------+
| Credit | TBD | Continue | Credit counts are out-of- | | Credit | TBD | Continue | Credit counts are out-of-sync |
| Window Out | | | sync between sender and | | Window Out | | | between sender and receiver |
| of Sync | | | receiver on the | | of Sync | | | on the destination. |
| | | | destination. | | Credit Use | TBD | Continue | Credit counts cannot be used |
| Credit Use | TBD | Continue | Credit counts cannot be | | Rejected | | | for the destination. |
| Rejected | | | used 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) | | TBD | Credit Grant (Section 9.1) |
| TBD | Credit Window Status (Section 9.2) | | TBD | Credit Window Status (Section 9.2) |
| TBD | Credit Request (Section 9.3) | | TBD | Credit Request (Section 9.3) |
+------------+-------------------------------------+ +------------+------------------------------------------------------+
Descriptions of the data items are included below. The credit- Descriptions of the data items are included below. The credit-
windowing data items are inserted into DLEP messages as follows: windowing data items are inserted into DLEP messages as follows:
8.1. DLEP Destination Up Message 8.1. DLEP Destination Up Message
If use of credits is required for the destination, then the
If use of credits is desired for the destination, then the
Destination Up message MUST contain one Credit Grant (Section 9.1) Destination Up message MUST contain one Credit Grant (Section 9.1)
data item. The value of the credit increment is at the discretion of data item. The value of the credit increment is at the discretion of
the implementation. The receiver of the Destination Up message MUST the implementation. If use of credits is accepted by the receiver,
use the value in Credit Grant as the initial value for the the value in the Credit Grant data item in the Destination Up message
appropriate window. MUST be used as the initial value for the appropriate window.
If the Destination Up message does not contain the Credit Grant data If the Destination Up message does not contain the Credit Grant data
item, credits MUST NOT be used for that destination. item, credits MUST NOT be used for that destination.
8.2. DLEP Destination Announce Message 8.2. DLEP Destination Announce Message
If use of credits is required for the destination, then the If use of credits is required for the destination, then the
Destination Announce message MUST contain one Credit Grant Destination Announce message MUST contain one Credit Grant
(Section 9.1) data item. The value of the credit increment is at the (Section 9.1) data item. The value of the credit increment is at the
discretion of the implementation. The receiver of the Destination discretion of the implementation. The receiver of the Destination
Announce message MUST use the value in Credit Grant as the initial Announce message MUST use the value in Credit Grant as the initial
value for the appropriate window. value for the appropriate window.
If the Destination Announce message does not contain the Credit Grant If the Destination Announce message does not contain the Credit Grant
data item, credits MUST NOT be used for that destination. data item, credits MUST NOT be used for that destination.
8.3. DLEP Destination Up Response Message 8.3. DLEP Destination Up Response Message
If the corresponding Destination Up message contained a Credit Grant If the corresponding Destination Up message contained a Credit Grant
(Section 9.1) data item, the Destination Up Response message MUST (Section 9.1) data item, the Destination Up Response message MUST
also contain a Credit Grant (Section 9.1) data item. 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 Likewise, if the corresponding Destination Up message did not contain
a Credit Grant (Section 9.1) data item, the Destination Up Response a Credit Grant (Section 9.1) data item, the receiver MUST conclude
message MUST NOT contain a Credit Grant (Section 9.1) data item. 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 The receiver of Destination Up Response MUST use the received Credit
Grant value to initialize the appropriate window (e.g., the MRW value Grant value to initialize the appropriate window (e.g., the MRW value
for routers, the RRW value for modems). for routers, the RRW value for modems).
When an implementation detects a mismatch in the presence or absence When an implementation detects a mismatch in the presence or absence
of credit window data items between the DLEP Destination Up and of credit window data items between the DLEP Destination Up and
Destination Up Response messages, the implementation detecting the Destination Up Response messages (e.g, the Destination Up message was
mismatch MUST terminate the session by issuing a Peer Termination sent using credits but the received Destination Up Response message
message with a status code of 'Credit Window Out of Sync', and does NOT include credits), the implementation detecting the credit-
transition to the Session Termination state. 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 8.4. DLEP Destination Announce Response Message
If the corresponding Destination Announce message contained a Credit If the corresponding Destination Announce message contained a Credit
Grant (Section 9.1) data item, the Destination Announce Response Grant (Section 9.1) data item, the Destination Announce Response
message MUST also contain a Credit Grant (Section 9.1) data item. 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 Likewise, if the corresponding Destination Announce message did not
contain a Credit Grant (Section 9.1) data item, the Destination contain a Credit Grant (Section 9.1) data item, the receiver MUST
Announce Response message MUST NOT contain a Credit Grant conclude that credits are NOT to be used for the destination, and
(Section 9.1) data item. 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 The receiver of Destination Announce Response MUST use the received
Credit Grant value to initialize the appropriate window (e.g., the Credit Grant value to initialize the appropriate window (e.g., the
MRW value for routers, the RRW value for modems). MRW value for routers, the RRW value for modems).
When an implementation detects a mismatch in the presence or absence When an implementation detects a mismatch in the presence or absence
of credit window data items between the DLEP Destination Announce and of credit window data items between the DLEP Destination Announce and
Destination Announce Response messages, the implementation detecting Destination Announce Response messages (e.g, the Destination Announce
the mismatch MUST terminate the session by issuing a Peer Termination message was sent using credits but the received Destination Up
message with a status code of 'Credit Window Out of Sync', and Response message does NOT include credits), the implementation
transition to the Session Termination state. 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 8.5. DLEP Destination Update Message
If the corresponding Destination Up or Destination Announce message If the corresponding Destination Up or Destination Announce message
contained the Credit Grant data item, the Destination Update message contained the Credit Grant data item, the Destination Update message
MAY contain one of each of the following data items: MAY contain one of each of the following data items:
o Credit Grant (Section 9.1) o Credit Grant (Section 9.1)
o Credit Window Status (Section 9.2) o Credit Window Status (Section 9.2)
skipping to change at page 8, line 15 skipping to change at page 8, line 46
Characteristics Request message solely for the purposes of Characteristics Request message solely for the purposes of
maintaining the credit windows. In cases where a peer already has maintaining the credit windows. In cases where a peer already has
information requiring a Link Characteristics Request message, the information requiring a Link Characteristics Request message, the
Credit Request data MAY be included in addition to that information. 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 Credit Grant data item MAY an increment to credits on a window. The value in a Credit Grant
appear in the DLEP Destination Up, Destination Announce, and Data Item represents an increment to be added to any existing credits
Destination Update messages. The value in a Credit Grant data item available on the window.
represents an increment to be added to any existing credits available
on the window. Upon successful receipt and processing of a Credit If credits are to used on a destination, the sender of the DLEP
Grant data item, the receiver MUST respond with a message containing Destination Up or Destination Announce messages MUST include a Credit
a Credit Window Status data item to report the updated aggregate Grant Data Item to initialize the credit window. If present in
values for synchronization purposes, and if initializing a new credit Destination Up or Destination Announce, the receiver MUST either
window, granting initial credits. place a Credit Grant Data Item in the Destination Up Response or
Destination Announce Response 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 the
updated aggregate values for synchronization purposes.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 9 skipping to change at page 9, line 49
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
window to overflow; if this condition occurs, implementations MUST window to overflow; if this condition occurs, implementations MUST
set the credit window to the maximum value contained in a 64-bit set the credit window to the maximum value contained in a 64-bit
quantity. quantity.
9.2. Credit Window Status 9.2. Credit Window Status
During normal operation, DLEP session peers may disagree about the During normal operation, DLEP session peers may disagree about the
number of available credits. Operational credit mismatches can occur number of available credits. Operational credit mismatches can occur
due to packets in transit on the wire. DLEP session peers MAY use due to packets in transit on the wire, or sequencing of sending and
the Credit Window Status data item to maintain synchronization of receiving packets (e.g. packets are sent prior to processing DLEP
credit counts. This data item is informational only; it is used to control information). DLEP session peers SHOULD make every effort to
inform the receiving peer of the current credit counts for both the keep credit counts in sync, and implementations MAY use the Credit
MRW and RRW, from the perspective of the sender. Window Status data item to maintain that synchronization. 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 Upon receipt of a Credit Window Status data item, an implementation
SHOULD compare its own credit counts with that of the originator. If SHOULD compare its own credit counts with that of the originator. If
the receiver of Credit Window Status detects that the local credit the receiver of Credit Window Status detects that the local credit
counts are not synchronized with the originator, the receiving counts are not synchronized with the originator, the receiving
implementation MAY either: o Attempt resynchronization using an implementation is free to employ various algorithms to re-establish
additional Credit Grant, if applicable, or o Issue a DLEP Destination close synchrnoization, such as:
Down message, to clear credit counts on the session.
Implementations issuing Destinaton Down MUST supply a DLEP Status o Allow the DLEP peer to completely exhaust its credits prior to re-
item, with the status code of 'Credit Window Out of Sync', as defined supplying them via a Credit Grant Data Item, or
in this document.
o Immediately attempt resynchronization using an additional Credit
Grant, if applicable, or
o Issue a DLEP Destination Down message, to clear credit counts on
the session, and then re-establish 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 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 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
skipping to change at page 10, line 38 skipping to change at page 12, line 4
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: TBD
Length: 0 Length: 0
10. Security Considerations 10. Security Considerations
The extension introduces a mechanism 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 those extension does not introduce any additional threats above thos
documented in [DLEP]. documented in [DLEP]. The mitigation strategy described in that
The mitigation strategy documented in that document is sufficient to document is sufficient to secure operation of this extension.
secure operation of 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 Event Protocol
(DLEP)". Assignments from that registry are requested for: (DLEP)". Assignments from that registry are requested for:
o Credit Grant o Credit Grant
skipping to change at page 11, line 46 skipping to change at page 13, line 11
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. References
13.1. 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-22 IETF draft, March 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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
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 13.2. Informative References
[RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and
M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578,
February 2010, <http://www.rfc-editor.org/info/rfc5578>. February 2010, <http://www.rfc-editor.org/info/rfc5578>.
Author's Address Author's Address
 End of changes. 32 change blocks. 
102 lines changed or deleted 159 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/