DLEP DiffServ Aware Credit Windowing
ExtensionLincoln LaboratoryMassachusetts Institute of Technology244 Wood StreetLexingtonMA02420-9108bcheng@ll.mit.eduLincoln LaboratoryMassachusetts Institute of Technology244 Wood StreetLexingtonMA02420-9108David.Wiggins@ll.mit.eduLabN Consulting, L.L.C.lberger@labn.net
This document defines an extension to the DLEP protocol that enables a
DiffServ aware credit-windowing scheme for destination-specific flow
control.
The Dynamic Link Event Protocol (DLEP) is defined in . It provides the exchange of link
related control information between DLEP peers. DLEP peers are
comprised of a modem and a router. DLEP defines a base set of
mechanisms as well as support for possible extensions. This
document defines one such extension.
The base DLEP specification does not include any flow control
capability. There are various flow control theoretically possible
with DLEP. For example, a credit-windowing scheme for
destination-specific flow control which provides aggregate flow
control for both modem and routers has been proposed in .
This document defines a DLEP extension which provides flow control for
DiffServ traffic sent from a router to a
modem. Flow control is provided for multiple DSCPs (differentiated
services codepoint), which are grouped into logical sets of logical
queues. The extension defined in this document is referred to as
"DiffServ Aware Credit Windowing" or, more simply, the "DA Credit"
extension.
This document defines a new DLEP Extension Type Value in which is used to indicate the use of the
extension. Two new messages are defined in , and four new DLEP Data Items in .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 .
The DA Credit extension can be used to support credit based flow
control of traffic sent from a router to a modem. The extension can
be used to support DiffServ and non-DiffServ based flow control.
Both types of DLEP endpoints, i.e., a router and a modem, negotiate
the use of extension during session initialization, see Section 5.2
. When using this extension,
data is allowed to be sent by the router to the modem only when
there are credits available.
When the extension is to be used, a modem passes to a router its
known DSCPs, if any. DSCPs are grouped by logical queues, each of
which are given a logical queue index. The queue index zero (0) is
special and is used for any DSCP value, including 0, which is not
otherwise identified by the modem. The modem also provides a size,
in bytes, of the logical queue for informative and, potential,
future uses. Currently, only DSCP to logical queue index value
mapping is used in flow control operation.
The DA Credit extension supports credit based flow control on a per
MAC address destination, per queue index basis. Modems provide the
initial size of the associated "Credit Window", i.e., the amount in
octets (bytes) that may be sent by the router to the modem, when a
MAC destination becomes reachable and, optionally, when its rate
information changes. "Credit Increments", i.e., increases in a
Credit Window size, are provided using new "Credit Control"
messages. A router provides its view of the Credit Window, which is
known as "status", in Destination Up Response and the new "Credit
Control Response" messages. Routers can also request credits using
the new "Credit Control" message.
Credit information, both grants and status, is provided in new
credit grant related data items. Each data item contains a single
credit value that applies to one or more queue indexes. Different
(grant and status) values for different queue indexes can be
provided in a single message by including multiple grant data items.
The values indicate a number of octets (bytes), including MAC
headers on the router to modem link, that may be sent.
Note that credit information related to different destination MAC
addresses is always passed in different DLEP messages.
The use of the extension defined in this document SHOULD be
configurable. To indicate that the DiffServ Aware Credit Windowing
Extension is to be used, an implementation MUST include the DiffServ
Aware Credit Windowing Type Value in the Extensions Supported Data
Item. The Extensions Supported Data Item is sent and processed
according to .
The DiffServ Aware Credit Windowing Extension Type Value is TBA1, see
.
When the use of the extension defined in this document is agreed upon
per standard DLEP processing, see ,
a router MUST NOT send data to a modem for forwarding when there are
no credits available in the associated Credit Window.
Two new messages are defined by this extension: the Credit Control
and the Credit Control Response message. Sending and receiving both
message types MUST be supported by any implementation that
advertises use of this extension per .
Credit Control Messages are sent by modems to provide Credit
Increments. For messages sent by modems, only one message per MAC
address can be outstanding at one time. That is, a modem MUST
NOT send a second (or any subsequent) message containing the same
MAC Address until a Credit Control Response message is received
from its peer router with that MAC address.
Credit Control Messages MAY be sent by routers, e.g., to request
credits or provide window status. No specific response message is
required from a message transaction perspective.
[TBD: Should anything be said about sending, or limiting, multiple
credit requests?]
The Message Type value in the DLEP Message Header is set to TBA2.
The message MUST contain a DLEP MAC Address Data Item.
A message sent by a modem, MUST contain one or more DiffServ Aware
Credit Grant data items as defined below in . A router receiving this message MUST
respond with a Credit Control Response Message.
A message sent by a router, MUST contain the DiffServ Aware Credit
Request data item defined below in . A modem receiving this message MUST
provide a Credit Increment for the indicated MAC address and queue
indexes via a new Credit Control Message.
Specific processing associated with each Credit data item is
provided below.
Credit Control Response Messages are sent by
routers to report the current Credit Window for a destination.
The Message Type value in the DLEP Message Header is set to TBA3.
The message MUST contain a DLEP MAC Address Data Item.
A message sent by a router, MUST contain one or more DiffServ
Aware Credit Window Status data items as defined below in .
Specific processing associated with the DA Credit Window Status
data item is provided below.
Four data items are defined by this extension. The Queue Parameters
Data Item is used by a modem to provide information on the DSCPs it
uses in forwarding.
The DA Credit Grant is used by a modem to provide credits
to a router.
The DA Credit Request is used by a router to request additional
credits.
The DA Credit Window Status is used to advertise the sender's view of
number of available credits for synchronization purposes.
The defined data items and operations are similar to those found in
. One notable difference
from this extension is that in this document credits are never
provided by the router to the modem.
The Queue Parameters Data Item is used by a modem to indicate DSCP
values that may be independently controlled. This data item MUST be
included in a Session Initialization Response Message that also
contains the DiffServ Aware Credit Windowing Extension Type Value in
the Extensions Supported Data Item. Updates to these parameters MAY
be sent by a modem by including the data item in Session Update
Messages.
The Queue Parameters Data Item identifies DSCPs based on groups of
logical queues. The number of logical queues is variable as is the
number of DSCPs associated with each queue. A queue size (in bytes)
is provided for informational purposes. An implementation that does
not support DSCPs would indicate 1 queue with 0 DSCPs, and the number
of bytes that may be in its associated link transmit queue.
The format of the Queue Parameters Data Item is:
TBA4Variable
Per Length
is the number of octets in the data item, excluding the Type and
Length fields.
An 8-bit unsigned integer indicating the number of queues
represented in the data item. This field MUST contain a value of
at least one (1). Note that this number is one
larger than the largest queue index value included in the data
item.
An 4-bit unsigned integer indicating the scale used in the Queue
Size fields. The valid values are:
MUST be set to zero by the sender (a modem) and ignored by the
receiver (a router).
An 8-bit unsigned integer indicating the number of DSCPs
associated with the indexed queue. Other than the special case
covered in the next paragraph, this field MUST contain a value of
at least one (1). Queue indexes start at zero (0) and the maximum
queue index "Qn" is one less than the value carried in the Num
Queues field. Queue indexes are implicit in the position in the
data item.
Queue index zero "Q0" is a special case. It is used for any
traffic that does not carry a DSCP value represented in the data
item. Therefore the value of the Queue index zero field, "Num
DSCPs Q0", field MUST be zero (0).
A 24-bit unsigned integer representing the size, in the octet
scale indicated by the Scale field, of the queue supporting
traffic with the DSCPs associated with the queue index.
The data item contains a sequence of 8 bit DS Fields. The
position in the sequence identifies the associated queue
index. The number of DS Fields present should equal the sum of all
Num DSCPs field values.
The DS Field structure is the same as .
The DiffServ Aware, or DA, Credit Grant data item is used by a modem
to provide credits to a router. One or more DA Credit Grant data
items MAY be carried in the DLEP Destination Up, Destination Announce
Response, Destination Update, and Credit Control messages. Multiple
DA Credit Grant data items in a single message are used to indicated
different credit values for different logical queues.
In Destination type messages, this data item provides the total
number of octets available in the Credit Window to the destination
indicated in the message for the specified logical queues. In the
Credit Control message, this data item provides an additional number
of octets to be added to the Credit Window to the destination
indicated in the message for the specified logical queues.
Logical queues are identified using a Queue Index as defined above in
. Multiple Queue Indexes MAY be present to
allow for the case where same credit information applies to multiple
queues. As mentioned above, multiple DA Credit Grant Data Items MAY
be present to provide different queue-specific credit information in
one message. The special Queue Index value of 255 is used to indicate
that the credit information applies to all queues.
The format of the DA Credit Grant Data Item is:
TBA5Variable
Per , Length
is the number of octets in the data item, excluding the Type and
Length fields. It will equal 8 plus the number of Queue Index
fields carried in the data item and MUST be at least 9.
A 64-bit unsigned integer representing the credits, in octets, to
be applied to the Credit Window. This value includes MAC
headers as seen on the link between the modem and router.
One or more 8-bit fields used to indicate a queue index defined by
a Queue Parameters Data Item. The special value of 255 indicates
that the information in the data item applies to all queue indexes.
Receive processing of this data item is based on the message in which
it is carried. When this data item is received in a Destination type
message, the Credit Window of the indicated destination MAC address
and indicated queue indexes MUST be set to the value contained in the
Credit Value field.
When this data item is received in a Credit Control message, the
Credit Window of the indicated destination MAC address and indicated
queue indexes MUST be increased by the value contained in the Credit
Value field. If the increase results in a window overflow, i.e., the
Credit Window resulting after the increase is smaller than the
original Credit Window, the Credit Window must be set to its maximum
(0xFFFFFFFFFFFFFFFF).
Independent of the received message, the receiving router MUST send a
DA Credit Window Status data item or items reflecting the resulting
Credit Window value of each modified queue index. When the Credit
Grant data item is received in a Destination Up message, the DA Credit
Window Status data item(s) MUST be sent in the corresponding
Destination Up Response message. In all other cases, the a Credit
Control message MUST be sent.
The DiffServ Aware, or DA, Credit Window Status data item is used by
a router to report the current Credit Window to its peer modem. One
or more DA Credit Window Status data items MAY be carried in a
Destination Up Response message or a Credit Control Response message.
As discussed above, the Destination Up Response message is used when
the data item is sent in response to a Destination Up message, and
the Credit Control Response message is sent in response to a Credit
Control message. Multiple DA Credit Window Status data items in a
single message are used to indicated different credit window values
for different logical queues.
Similar to the DA Credit Grant, logical queues are identified using a
Queue Index as defined above in . Multiple
Queue Indexes MAY be present to allow for the case where same credit
information applies to multiple queues. Multiple DA Credit Window
Status Data Items are used to provide different queue-specific credit
window information in one message. The special Queue Index value of
255 is used to indicate that the Credit Window information applies to
all queues.
The format of the DA Credit Window Status Data Item is:
TBA6Variable
Per Length
is the number of octets in the data item, excluding the Type and
Length fields. It will equal 8 plus the number of Queue Index
fields carried in the data item and MUST be at least 9.
A 64-bit unsigned integer, indicating
the current number of credits, in octets, available for the
router to send to the modem. This is referred to as the
Modem Receive Window in .
One or more 8-bit fields used to indicate a queue index defined by
a Queue Parameters Data Item. The special value of 255 indicates
that the information in the data item applies to all queue indexes.
The receiving modem SHOULD check the received Credit Window value
against the outstanding credits available at the time the last Credit
Increment associated with the indicated MAC address and Queue Indexes
were sent. If the values significantly differ, i.e., greater than can
be accounted for based on observed data frames, then the modem SHOULD
send a Destination Update message carrying a DA Credit Grant data item
to reset the associated Credit Window(s) to the data item indicated
value. Multiple values and queue indexes SHOULD be combined into a
single Destination Update Control message when possible.
Alternatively, and also in cases where there are small differences,
the modem MAY adjust the values sent in DA Credit Grant data items to
account for the reported Credit Window.
The DiffServ Aware, or DA, Credit Request Data Item data item is used
by a router to request additional credits for a specific destination
and Queue Index associated Credit window. DA Credit Request data
items are carried in Credit Control messages, and only one DA Credit
Request data item SHOULD be present in a message.
Logical queues are identified using a Queue Index as defined above in
. Multiple Queue Indexes MAY be present to
allow for the case where the credit request applies to multiple
queues. The special Queue Index value of 255 is used to indicate
that a credit request is being made across all queues.
The format of the DA Credit Request Data Item is:
[LB note: a list of Queue Indexes is now supported as is special value
255.]
TBA7Variable
Per Length
is the number of octets in the data item, excluding the Type and
Length fields. It will equal the number of Queue Index
fields carried in the data item and MUST be at least 1.
One or more 8-bit fields used to indicate a queue index defined by
a Queue Parameters Data Item. The special value of 255 indicates
that the request applies to all queue indexes.
A modem receiving this data item MUST provide a Credit Increment for
the indicated MAC address and queue indexes via a DA Credit Grant
carried in a new Credit Control Message. Multiple values and queue
indexes SHOULD be combined into a single Credit Control message when
possible.
Sessions established with both peers identified as supporting the
DiffServ Aware Credit Windowing Extension Type, see , SHOULD NOT use the defined Credit data items.
If a node supporting the extension defined in this document, receives a
defined data item,
the recipient MUST treat the received credit information as
applying to Queue Index zero (0).
The extension introduces a DiffServ awareness to the mechanisms
defined in . The
extension does not inherently introduce any additional threats above
those documented in . The
approach taken to Security in that document and apply equally when running
the extension defined in this document.
This document requests the assignment of 5 values by IANA. All
assignments are to registries defined by .
This document requests 1 new assignment to the DLEP Extensions
Registry named "Extension Tyoe Values" in the range with the
"Specification Required" policy. The requested value is as follows:
CodeDescriptionTBA1DiffServ Aware Credit Windowing
This document requests 2 new assignments to the DLEP Message Registry
named "Message Values" in the range with the "Specification Required"
policy. The requested values are as follows:
Type CodeDescriptionTBA2Credit ControlTBA3Credit Control Response
This document requests 4 new assignments to the DLEP Data Item
Registry named "Data Item Values" in the range with the "Specification
Required" policy. The requested values are as follows:
Type CodeDescriptionTBA4Queue ParametersTBA5DA Credit GrantTBA6DA Credit Window StatusTBA7DA Credit Request
This section captures issues that are open or have been addressed
since the document has become a WG draft. This section will be
removed before submission for publication.
There has been discussion within the WG that this document should
be merged with .
The timing of this is TBD. The authors would like to reach
closure on some of the remaining open issues before embarking on
this merge, but are open to discussion with the WG and other authors.
The DA Credit Extension supports credit windows per mac
destination. Some media technologies share queues across all, or
even some set of, destinations and supporting an associated set of
credit windows isn't currently supported.
Supporting credit windows per modem, i.e., for a single transmit
channel, is clearly required and needs to be supported.
Credit windows for sets of mac addresses should also be
considered and discussed within the working group, both from a
requirements and support perspective.
This issue was reported by Stan Ratliff <ratliffstan@gmail.com>.
Routers may have limits on the number of queues that they can
support and, perhaps, if per destination queues can even be
supported at all. There is no current way for a router to
communicate these limits to a modem or for a router to indicate
that the identified queue information cannot be supported.
Support for these cases clearly needs to be addressed.
This issue was reported by Stan Ratliff <ratliffstan@gmail.com>.
Stan Ratliff <ratliffstan@gmail.com> suggested an approach to
simplify credit synchronization and re-synchronization by always
passing the credit window size rather than credit window
increments. This is an interesting idea that needs to be explored
and perhaps experimented with.
The format of the Queue Parameters Data Item is a bit cumbersome
and there has been some discussion of a possible better way of
encoding lists and optional information elements within Data
Items. There has been some discussion of developing a generic
mechanisms for use by DLEP and future DLEP Data Items. Such a
definition is beyond the scope of this document, but if such
becomes available there is every reason for this document to
leverage this improved encoding. This issue will remain open
until such a time as there is a such a definition within the WG or
this document is otherwise ready for publication.
This issue was independently raised by both David Wiggins
(co-author) and Rick Taylor <rick@tropicalstormsoftware.com>.
One of the key differences between this draft and is that this document only
supports flow control in one direction, i.e., for traffic sent
from a router to a modem, while the other credit-window draft
supports it in both directions.
This was a conscious choice, made out of the desire to keep the
extension as simple as possible and to provide what is really
expected to be used.
Clearly the reason for being able to control traffic that is sent from
the router to the modem/radio is pretty easily understood. Also, while
bidirectional flow control existed in pre-dlep solutions, it wasn't
really used. There is also no reason why router to modem flow
control can't be defined at a later time - once there is an actual
need.
Based on a brief discussion on the WG list, and the absence of any
advocates for bidirectional flow control, there is no current plan
to add bidirectional flow control to this document.