RFC 8651

Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension

📅 published October 2019, from ietf

okay bestie, this one is all about pausing traffic 🦋 Here's the lineup:

  • Number: RFC 8651
  • Authors: B. Cheng and D. Wiggins (MIT Lincoln Laboratory), with L. Berger, Ed. (LabN Consulting, L.L.C.)
  • Category: Standards Track 🎀
  • ISSN: 2070-1721
  • Date: October 2019
  • Obsoletes / Updates: nothing listed in the title block

Abstract ✨

okay so this extension lets a modem use DLEP messages to pause and resume the data traffic coming from its peer router 🫶

Status of This Memo

this is an Internet Standards Track document 💅

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841 📚

all the info about this doc's current status, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8651 🌸

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the publication date. please actually read these, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
  1.1.  Key Words
2.  Extension Usage and Identification
3.  Extension Data Items
  3.1.  Queue Parameters
    3.1.1.  Queue Parameter Sub-Data Item
  3.2.  Pause
  3.3.  Restart
4.  Security Considerations
5.  IANA Considerations
  5.1.  Extension Type Value
  5.2.  Data Item Values
  5.3.  Queue Parameter Sub-Data Item Values
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

okay so DLEP is defined in [RFC8175] 🌈 It's how a modem and a router swap link-related control info. DLEP has a base set of mechanisms plus room for extensions, and this doc is one of those extensions 💅

the base DLEP spec has no data-plane flow control at all 😭 This extension fixes that. The modem sends explicit DLEP messages to tell the router when to hold off sending traffic and when it's cleared to resume 🦋 It's basically the same vibe as the flow control in PPP over Ethernet (PPPoE), per [RFC5578] 💖 It can also optionally do DSCP-aware flow control for Diffserv-aware modems (DSCP = "Differentiated Services Code Point") 🎀 For general Diffserv background, see [RFC2475] 📚 This is super similar to Ethernet priority-based flow control, see [IEEE.802.1Q_2014] 🫶 The extension in this doc is called "Control-Plane-Based Pause" 👑 Other flow-control methods are possible with DLEP too. For example, see [DLEP-DIFFSERV] and [DLEP-CREDIT] 🧚

quick but important: this mechanism only applies to traffic going out on the modem's attached data channel. It does not apply to the DLEP control messages themselves 🙈 It also only covers the single subnetwork that connects a modem and a router, and only traffic sent from a router to a modem 🍓

this doc defines a new DLEP Extension Type Value to signal that the extension is in use (see Section 2) 💜 It also defines three new DLEP Data Items in Section 3 ✨

1.1. Key Words 🔥

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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in ALL CAPITALS, exactly as shown here 💅

2. Extension Usage and Identification 🎀

the Control-Plane-Based Pause Extension SHOULD be configurable 🌸 To say that an implementation supports it, the implementation MUST include the Control-Plane-Based Pause Extension Type Value in its Extensions Supported Data Item 🫶 That Data Item is sent and processed according to [RFC8175] 💖

the Control-Plane-Based Pause Extension Type Value is 2. See Section 5 for more on that 👑

3. Extension Data Items 🦋

three Data Items come with this extension ✨ The Queue Parameters Data Item is how a modem tells the router about the DSCPs it uses when forwarding 💅 The Pause Data Item is how a modem says when a router should stop sending packets 🙈 And the Restart Data Item is how a modem says when a router is allowed to start sending packets again 🌈

3.1. Queue Parameters 💜

the Queue Parameters Data Item is sent by a modem to a router to list DSCP values that may be paused independently 🧚 This Data Item MUST be included in a Session Initialization Response Message that also has the Control-Plane-Based Pause Extension Type Value in its Extensions Supported Data Item 🔥 A modem MAY send updates to these parameters by including the Data Item in Session Update Messages 🎀

this Data Item groups DSCPs into logical queues, and each queue is identified by a "Queue Index" field 🍓 The number of logical queues can vary, and so can the number of DSCPs in each queue ✨ A queue size (in bytes) is included for informational purposes only 🌸 Queue Index fields are numbered sequentially starting at zero. Queue index zero is a special case: it covers DSCPs that aren't otherwise tied to a Queue Index field 👑

an implementation that doesn't support DSCPs would indicate one queue with zero DSCPs, along with the number of bytes that may be in its associated link transmit queue 🦋 Any extra logical queues show up in a variable series of Queue Parameter Sub-Data Items 💖

the layout of the Queue Parameters Data Item is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type                | Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Num Queues  | Scale |              Reserved                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Queue Parameter Sub-Data Item 1                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                ...                            :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Queue Parameter Sub-Data Item n                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

now the fields, one by one 🧁

  • Data Item Type: 23
  • Length: variable 📏 Per [RFC8175], Length is the number of octets in the Data Item, not counting the Type and Length fields.
  • Num Queues: an 8-bit unsigned integer giving the number of Queue Parameter Sub-Data Items that follow. This field MUST contain a value of at least one (1) 💅
  • Scale: a 4-bit unsigned integer giving the scale used in the Queue Size Qn field. The valid values are in Table 1 below 🌈
  • Reserved: a 20-bit field that MUST be set to zero (0) by the sender (a modem) and ignored by the receiver (a router) 🙈
+-------+--------------------------+
| Value | Scale                    |
+=======+==========================+
| 0     | B - Bytes (Octets)       |
+-------+--------------------------+
| 1     | KB - Kilobytes (1024 B)  |
+-------+--------------------------+
| 2     | MB - Megabytes (1024 KB) |
+-------+--------------------------+
| 3     | GB - Gigabytes (1024 MB) |
+-------+--------------------------+

Table 1: Queue Size Qn Field Values
ngl the Scale table is where you need to be careful, bestie 🙈 Each step up is 1024 times the one before it, so pick the right unit or your queue sizes will be totally off 💀

okay that's the first chunk of Control-Plane-Based Pause 💖 We're still in Section 3.1, so stay tuned for part 2 ✨

3.1.1. Queue Parameter Sub-Data Item

Okay bestie, so Queue Parameter Sub-Data Items are an unordered list made of Sub-Data Items that all share one common format ✨ That format is patterned after the standard DLEP Data Item, so if you already know that one, you're halfway there 💅 (see [RFC8175], Section 11.3). Any errors or inconsistencies you hit while parsing Sub-Data Items get handled the same way as any other Data Item parsing error in DLEP 🫶 So 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. Harsh but fair 😭

The format of the Queue Parameter Sub-Data Item is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sub-Data Item Type (1)        | Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and Value has the format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Queue Index  |             Queue Size Qn                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Num DSCPs Qn  |  DS Field Qn  |              ...              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                          ...                  |  DS Field Qn  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sub-Data Item Type: 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.

Length: Variable. Length is the number of octets in the Sub-Data Item, excluding the Type and Length fields.

Queue Index: 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.

Queue Size Qn: A 24-bit unsigned integer representing the size, in the octet scale indicated by the Scale field, of the queue that supports the traffic with the DSCPs associated with the queue index.

Num DSCPs Qn: An 8-bit unsigned integer indicating the number of DSCPs associated with the queue index associated with the Sub-Data Item.

DS Field Qn: The Data Item contains a sequence of 8-bit DS fields. The number of DS fields present MUST equal the Num DSCPs Qn field value.

The DS field structure is the same as the structure shown in [RFC2474].

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|         DSCP          |  CU   |
+---+---+---+---+---+---+---+---+

DSCP: Differentiated Services Code Point

CU: Currently Unused; MUST be zero

3.2. Pause

The Pause Data Item is sent by a modem to a router to tell its peer that traffic is to be suppressed, i.e., paused 🛑 The motivating use case is when a modem's internal queue length goes past a particular threshold. Other use cases are possible, e.g., when there are non-queue-related congestion points within a modem. Those cases aren't explicitly described in this document 🙈

A modem can indicate that traffic is to be suppressed on a device-wide or destination-specific basis 🎀 A modem might use device-wide suppression when output queues are shared across all destinations. Destination-specific suppression might be used when per-destination queuing is in play. 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 field (Section 3.1), which in turn indicates traffic identified by one or more DSCPs. The special value of 255 is used to indicate that all traffic is to be suppressed.

There's no restriction on the number of messages containing Pause Data Items that a modem can send, but a modem SHOULD include multiple queue indexes in the same message when possible 🍓

A router that receives the Pause Data Item MUST cease sending the identified traffic to the modem. This may of course translate into the router's own queues exceeding their 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:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type                | Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Queue Index  |               ...                             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                ...            |  Queue Index  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 24

Length: Variable. Per [RFC8175], 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.

Queue Index: 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 (1) all traffic to the modem is to be suppressed when the Data Item is carried in a Session Update Message or (2) all traffic to a particular destination is to be suppressed when the Data Item is carried in a Destination Update Message.

3.3. Restart

The Restart Data Item is sent by a modem to a router to tell 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 📉

Sending this Data Item parallels the Pause Data Item (see Section 3.2) and follows the same rules 💜 To indicate that transmission can resume to all destinations, a modem MUST send the Restart Data Item in a Session Update Message. To indicate that transmission can resume to a particular destination, a modem MUST send the Restart Data Item in a Destination Update Message. Finally, the same rules apply to queue indexes.

A router that 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:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data Item Type                | Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Queue Index  |               ...                             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                ...            |  Queue Index  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 25

Length: See Section 3.2.

Queue Index: See Section 3.2.

4. Security Considerations

The extension defined in this document introduces a new mechanism for flow control between a router and modem using DLEP 🚦 It does not introduce any vulnerabilities that are inherently different from those documented in [RFC8175]. 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 the configuration and use of TLS, as described in [RFC8175], in order to protect configurations where injection attacks are possible, i.e., when the link between a modem and router is not otherwise protected.

🚨 Okay, this part is seriously important. 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 with base DLEP. For example, an impersonating modem may cause a session reset, or a compromised modem can simply drop all traffic destined for or sent by a router. [RFC8175] defines the use of TLS to protect against such impersonating attackers 🔐

5. IANA Considerations

This document assigns four new values and creates a new subregistry in the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry 🎀

5.1. Extension Type Value

This document adds a new assignment to the DLEP extensions registry named "Extension Type Values" [RFC8175], per the "Specification Required" policy [RFC8126]. IANA has assigned the following value:

               +------+---------------------------+
               | Code | Description               |
               +======+===========================+
               | 2    | Control-Plane-Based Pause |
               +------+---------------------------+

                  Table 2: Extension Type Value

5.2. Data Item Values

This document adds three new assignments to the DLEP Data Item registry named "Data Item Type Values" [RFC8175], per the "Specification Required" policy [RFC8126]. IANA has assigned the following values:

                 +-----------+------------------+
                 | Type Code | Description      |
                 +===========+==================+
                 | 23        | Queue Parameters |
                 +-----------+------------------+
                 | 24        | Pause            |
                 +-----------+------------------+
                 | 25        | Restart          |
                 +-----------+------------------+

                    Table 3: Data Item Values

5.3. Queue Parameter Sub-Data Item Values 💅✨

okay bestie, this is where IANA gets its own little registry 🎀 They made a brand new DLEP registry called "Queue Parameter Sub-Data Item Type Values" 🦋

Table 4 has the starting values and the registration policies [RFC8126] that apply, so here's the tea 🍓

                 +-------------+------------------------+
                 | Type Code   | Description/Policy     |
                 +=============+========================+
                 | 0           | Reserved               |
                 +-------------+------------------------+
                 | 1           | Queue Parameter        |
                 +-------------+------------------------+
                 | 2-65407     | Specification Required |
                 +-------------+------------------------+
                 | 65408-65534 | Private Use            |
                 +-------------+------------------------+
                 | 65535       | Reserved               |
                 +-------------+------------------------+

Table 4: Initial Registry Values

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgments 🫶

The format for the Sub-Data Item was inspired by Rick Taylor's "Data Item Containers" idea. Huge shoutout to Rick, the real MVP of this sub-data item look ✨

Authors' Addresses 🌸

Bow-Nan Cheng
MIT Lincoln Laboratory
Massachusetts Institute of Technology
244 Wood Street
Lexington, MA 02421-6426
United States of America

Email: bcheng@ll.mit.edu
David Wiggins
MIT Lincoln Laboratory
Massachusetts Institute of Technology
244 Wood Street
Lexington, MA 02420-9108
United States of America

Email: David.Wiggins@ll.mit.edu
Lou Berger (editor)
LabN Consulting, L.L.C.

Email: lberger@labn.net

That's the whole squad 💜 Bow-Nan, David, and Lou (editor) 👑

📦 where this page comes from