DLEP Control Plane Based Pause
ExtensionMIT Lincoln LaboratoryMassachusetts Institute of Technology244 Wood StreetLexingtonMA02421-6426bcheng@ll.mit.eduMIT Lincoln 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 Dynamic Link Exchange Protocol (DLEP) that enables a
modem to use DLEP messages to pause and resume data traffic coming
from its peer router.
The Dynamic Link Exchange Protocol (DLEP) is defined in . It provides the exchange of link
related control information between 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 data plane flow
control capability. The extension defined in this document supports
flow control of data traffic based on explicit messages sent via DLEP
by a modem to indicate when a router should hold off sending traffic,
and when it should resume. This functionality parallels the flow
control mechanism found in PPP over Ethernet (PPPoE) per
. The extension also optionally
supports DSCP (differentiated services codepoint) aware flow control
for use by DiffServ-aware modems. (For
general background on Differentiated Services see .)
This functionality is very similar to that provided by Ethernet
Priority flow control, see .
The extension defined in this document is referred
to as "Control Plane Based Pause". Other flow control methods are
possible with DLEP, e.g., see and .
Note that
this mechanism only applies to traffic that is to be transmitted on the
modem's attached data channel and not to DLEP control messages
themselves. Furthermore it applies only to the single sub-network
that is used to connect a modem and a router, and for traffic sent
from a router to a modem.
This document defines a new DLEP Extension Type Value in which is used to indicate the use of the
extension, and three 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 when, and
only when, they appear in all capitals, as shown here.
The use of the Control Plane Based Pause Extension SHOULD be configurable.
To indicate that the implementation supports use of the Control Plane Based Pause Extension, an
implementation MUST include the Control Plane Based Pause Extension Type
Value in the Extensions Supported Data Item. The Extensions Supported
Data Item is sent and processed according to .
The Control Plane Based Pause Extension Type Value is TBA1, see .
Three data items are defined by this extension. The Queue Parameters
Data Item is used by a modem to provide information about the DSCPs it
uses in forwarding. The Pause Data Item is used by a modem to
indicate when a router should cease sending packets and the Restart
Data Item is used by a modem to indicate when a router can resume
sending packets.
The Queue Parameters Data Item is sent by a modem to to a router to indicate DSCP
values that may be independently paused. This data item MUST be
included in a Session Initialization Response Message that also
contains the Control Plane Based Pause 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 groups DSCPs into
logical queues, each of which is identified by a "Queue Index". The
number of logical queues, or queue indexes, is variable as is the
number of DSCPs associated with each queue. A queue size (in bytes)
is provided for informational purposes. Queue Indexes are numbered
sequentially from zero, where queue index zero is a special case
covering DSCPs which are not otherwise associated with a Queue Index.
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. Additional logical queues are represented in a
variable series of Queue Parameter sub data items.
The format of the Queue Parameters Data Item is:
TBA2Variable
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), and is equal to one greater than the number of
included Queue Parameter Sub Data Items.
A 4-bit unsigned integer indicating the scale used in the Queue
Size fields. The valid values are:
A 20-bit field that MUST be set to zero by the sender (a modem) and ignored by the
receiver (a router).
Queue Parameter Sub Data Items are an unordered list composed of
sub data items with a common format. The format of the Queue Parameter Sub
Data Item is patterned after the standard DLEP data item format,
see Section 11.3. Any errors
or inconsistencies encountered in parsing Sub Data Items are
handled in the same fashion as any other Data Item parsing error
encountered in DLEP.
In particular, the receiving implementation MUST issue a
Session Termination Message containing a Status Data Item with
status code set to 130 'Invalid Data' and transition to the
Session Termination state.
The format of the Queue Parameter Sub Data Item is:
and Value has the format:
A 16-bit unsigned integer that indicates the type and
corresponding format of the Sub Data Item's Value field. Sub Data
Item Types are scoped within the Data Item in which they are
carried, i.e., the Sub Data Item Type field MUST be used together
with the Queue Parameters Data Item Type to identify the format of the Sub Data
Item. This field MUST be set to one (1) for the Queue Parameter
Sub Data Item.
Variable
Length
is the number of octets in the sub data item, excluding the Type and
Length fields.
An 8-bit field indicating the queue index of the queue
parameter represented in the sub data item. Only the first
instance of a particular Queue Index value is meaningful.
Subsequent sub data items containing the same Queue Index values,
if present, MAY be logged via a management interface and MUST
otherwise be ignored. Note that the value 255 is reserved and MUST
NOT be used in this field.
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.
An 8-bit unsigned integer indicating the number of DSCPs
associated with the queue index associated with the sub data item.
This field MUST contain a value of at least one (1).
The data item contains a sequence of 8 bit DS Fields. The
number of DS Fields present MUST equal the sum of all
Num DSCPs field values.
The DS Field structure is the same as .
The Pause Data Item is sent by a modem to a router to indicate to its peer that
traffic is to be suppressed, i.e., paused.
The motivating use case for this data item is when a modem's
internal queue length exceeds a particular threshold. Other use cases
are possible, e.g., when there are non queue related congestion points
within a modem. Such cases are not explicitly described in this
document.
A modem can indicate that traffic is to be suppressed on a device-wide
or destination-specific basis. An example of when a modem might use
device wide indications is when output queues are shared across all
destinations, and destination specific might be used when per
destination queuing is used. To indicate that suppression applies to
all destinations, a modem MUST send the Pause Data Item in a Session
Update Message. To indicate that suppression applies to a particular
destination a modem MUST send the Pause Data Item in a Destination
Update Message.
Each Pause Data Item identifies the traffic to be suppressed by the
Queue Index defined by , which in turn
indicates a set of traffic identified by DSCPs. The special value of
255 is used to indicate that all traffic is to be suppressed.
While there is no restriction on the number of Messages containing
Pause Data Item that may be sent by a modem, a modem SHOULD include
multiple queue indexes in the same message when possible.
A router which receives the Pause Data Item MUST cease sending
the identified traffic to the modem. This may of course translate into
the router's queues exceeding their own thresholds.
If a received Pause Data Item contains a Queue Index value other than
255 or a queue index established by a Session Initialization or
Session Update Message, the router MUST terminate the session with a
Status Data Item indicating Invalid Data.
The format of the Pause Data Item is:
TBA3Variable
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.
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
all traffic is to be suppressed to the modem, when the data item
is carried in a Session Update Message, or is to be suppressed to a destination, when the
data item is carried in Destination Update Message.
The Restart Data Item is sent by a modem to a router to indicate to its peer that
transmission of previously suppressed traffic may be resumed. An
example of when a modem might send this data item is when an internal
queue length drops below a particular threshold.
The sending of this data item parallels the Pause Data Item, see the
previous section, and follows the same rules. As above, to
indicate that transmission can resume to all destinations, a modem MUST
send the Restart Data Item in a Session Update Message. It also
includes that to indicate that transmission can resume to a particular
destination a modem MUST send the Pause Restart Item in a Destination
Update Message. Finally, queue indexes are interpreted in the same
way as in the Pause Data Item..
A router which receives the Restart Data Item SHOULD resume
transmission of the identified traffic to the modem.
The format of the Restart Data Item matches the Pause Data Item and is:
TBA4See .See .
The extension introduces a new mechanism for flow control between a
router and modem using DLEP. The
extension does not inherently introduce any additional vulnerabilities
above those documented in .
The approach taken to Security in that document applies equally
when running the extension defined in this document.
Implementations of the extension defined in this document MUST support
configuration of TLS usage, as describe in ,
in order to protect configurations where injection attacks are
possible, i.e., when the link between a modem and router is not
otherwise protected.
Note that this extension does allow a compromised or impersonating
modem to suppress transmission by the router or a switch that
interconnects the modem and router. Similar attacks are
generally possible base DLEP, for example an impersonating modem may
cause a session reset or a compromised modem simply can
drop all traffic destined to, or sent by a router. defines the use of TLS to protect against the
impersonating attacker.
This document requests the assignment of 4 values 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:
CodeDescriptionTBA1Control Plane Based Pause
This document requests 3 new assignments to the DLEP Data Item
Registry named "Data Item Type Values" in the range with the "Specification
Required" policy. The requested values are as follows:
Type CodeDescriptionTBA2Queue ParametersTBA3PauseTBA4Restart
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "Queue Parameters Sub Data Item Type Values".
The following table provides initial registry values and the defined policies that should apply to the registry:
Type CodeDescription/Policy0Reserved1Queue Parameter2-65407Specification Required65408-65534Private Use65535Reserved
The sub data item format was inspired by Rick Taylor's "Data Item
Containers" idea.