DLEP IEEE 802.1Q Aware Credit Window
Extension
MIT Lincoln Laboratory
Massachusetts Institute of Technology
244 Wood Street
Lexington
MA
02421-6426
David.Wiggins@ll.mit.edu
LabN Consulting, L.L.C.
lberger@labn.net
This document defines an extension to the DLEP protocol that
enables a Ethernet IEEE 802.1Q aware credit-window scheme for
destination-specific and shared flow control.
The Dynamic Link Exchange 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 techniques
theoretically possible with DLEP.
This document defines a DLEP extension which provides an Ethernet-based flow
control mechanism for traffic sent from a router to a
modem. Flow control is provided using one or more logical
"Credit Windows", each of which will typically be supported by
an associated virtual or physical queue. Traffic sent by a
router will use traffic flow classification information provided
by the modem to identify which traffic is associated with each
credit window.
Credit windows may be shared or dedicated on a per flow
basis.
See for a
DiffServ-based version of credit window flow control.
This document uses the traffic classification and credit window
control mechanisms defined in and to provided credit
window based flow control based on on DLEP destination and
Ethernet VLANs and Priority Code Points. Ethernet Priority Code
Point support is defined as part of the IEEE 802.1Q tag format and includes a 3 bit
"PCP" field. The tag format also includes a 12 bit VLAN
identifier (VID) field. The defined mechanism allows for credit
windows to be shared across traffic sent to multiple DLEP
destinations VLANs, and PCPs, or used exclusively for traffic
sent to a particular destination and/or VLAN and/or PCP. The
extension also supports the "wildcard" matching of any PCP or
VID.
The extension defined in this document is referred to as "IEEE
802.1Q Aware Credit Window" or, more simply, the "Ethernet
Credit" extension. The reader should be familiar with both the
traffic classification and credit window control mechanisms
defined in and .
This document defines a new DLEP Extension Type Value in which is used to indicate support for
the extension.
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
when, and only when, they appear in
all capitals, as shown here.
The extension defined in this document is composed of the
mechanisms and processing defined in and . To indicate that
the IEEE 802.1Q Aware Credit Window Extension is to be used, an
implementation MUST include the IEEE 802.1Q Aware Credit Window
Type Value in the Extensions Supported Data Item. The
Extensions Supported Data Item is sent and processed according
to . Any implementation that indicates
use of the IEEE 802.1Q Aware Credit Window Extension MUST
support all Messages, Data Items, the Ethernet Traffic
Classification Sub Data Item, and all related processing defined
in and .
The IEEE 802.1Q Aware Credit Window Extension Type Value is
TBA1, see .
This section provides several network management guidelines to
implementations supporting the IEEE 802.1Q Aware Credit Window
Extension.
The use of the extension defined in this document SHOULD be
configurable on both modems and routers.
Modems SHOULD support the configuration of PCP to credit window
(queue) mapping.
Modems MAY support the configuration of PCP to credit window
(queue) mapping on a per VLAN basis. Note that VID value of zero
(0) is used by to indicate that
VID is ignored and any VID value is used in traffic
classification.
When VLANs are supported by a modem without support from PCPs,
the modem SHOULD support the configuration of VLAN to credit window
(queue) mapping.
Modems MAY support the configuration of the number of credit
windows (queues) to advertise to a router.
Routers may have limits on the number of queues that they can
support and, perhaps, even limits in supported credit window
combinations, e.g., if per destination queues can even be
supported at all. When modem-provided credit window information
exceeds the capabilities of a router, the router MAY use a
subset of the provided credit windows. Alternatively, a router
MAY reset the session and indicate that the extension is not
supported. In either case, the mismatch of capabilities SHOULD
be reported to the user via normal network management
mechanisms, e.g., user interface or error logging.
This document defines a DLEP extension that uses base DLEP
mechanisms and the credit window control and flow mechanisms
defined in and .
The use of those mechanisms, and the introduction of a new
extension, do not inherently introduce any additional threats
above those documented in . The
approach taken to Security in that document applies equally to
the mechanism defined in this document.
This document requests one assignment by IANA. All assignments
are to registries defined by .
This document requests 1 new assignment to the DLEP Extensions
Registry named "Extension Type Values" in the range with the
"Specification Required" policy. The requested value is as
follows:
Code Description
TBA1 IEEE 802.1Q Aware Credit Window
IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks
IEEE
This standard specifies how the Media Access Control (MAC)
Service is supported by Bridged Networks, the principles
of operation of those networks, and the operation of MAC
Bridges and VLAN Bridges, including management, protocols,
and algorithms
DLEP Traffic Classification Data Item
MIT Lincoln Laboratory
Massachusetts Institute of Technology
244 Wood Street
Lexington
MA
02421-6426
bcheng@ll.mit.edu
MIT Lincoln Laboratory
Massachusetts Institute of Technology
244 Wood Street
Lexington
MA
02421-6426
David.Wiggins@ll.mit.edu
LabN Consulting, L.L.C.
lberger@labn.net
The document was motivated by discussions in the MANET working
group. Many useful comments were received from contributors to
the MANET working group.