From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8651.txt | 577 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 577 insertions(+) create mode 100644 doc/rfc/rfc8651.txt (limited to 'doc/rfc/rfc8651.txt') diff --git a/doc/rfc/rfc8651.txt b/doc/rfc/rfc8651.txt new file mode 100644 index 0000000..ca05ee6 --- /dev/null +++ b/doc/rfc/rfc8651.txt @@ -0,0 +1,577 @@ + + + + +Internet Engineering Task Force (IETF) B. Cheng +Request for Comments: 8651 D. Wiggins +Category: Standards Track MIT Lincoln Laboratory +ISSN: 2070-1721 L. Berger, Ed. + LabN Consulting, L.L.C. + October 2019 + + + Dynamic Link Exchange Protocol (DLEP) + Control-Plane-Based Pause Extension + +Abstract + + 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8651. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 + + The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. + 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 + [RFC5578]. The extension also optionally supports DSCP-aware flow + control ("DSCP" stands for "Differentiated Services Code Point") for + use by Diffserv-aware modems. (For general background on + Differentiated Services, see [RFC2475].) This functionality is very + similar to that provided by Ethernet priority-based flow control; see + [IEEE.802.1Q_2014]. The extension defined in this document is + referred to as "Control-Plane-Based Pause". Other flow-control + methods are possible with DLEP; for example, see [DLEP-DIFFSERV] and + [DLEP-CREDIT]. + + 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 subnetwork 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 that is used to + indicate the use of the extension; see Section 2. Three new DLEP + Data Items are defined 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 interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Extension Usage and Identification + + The use of the Control-Plane-Based Pause Extension SHOULD be + configurable. To indicate that the implementation supports the 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 [RFC8175]. + + The Control-Plane-Based Pause Extension Type Value is 2; see + Section 5. + +3. Extension Data Items + + 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. + +3.1. Queue Parameters + + The Queue Parameters Data Item is sent by a modem 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" field. 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. Queue Index fields are numbered sequentially from zero, + where queue index zero is a special case covering DSCPs that are not + otherwise associated with a Queue Index field. + + An implementation that does not support DSCPs would indicate one + queue with zero 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: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: + 23 + + Length: + Variable + + Per [RFC8175], Length is the number of octets in the Data Item, + excluding the Type and Length fields. + + Num Queues: + An 8-bit unsigned integer indicating 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 indicating the scale used in the Queue + Size Qn field. The valid values are: + + +-------+--------------------------+ + | 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 + + Reserved: A 20-bit field that MUST be set to zero (0) by the sender + (a modem) and ignored by the receiver (a router). + +3.1.1. Queue Parameter Sub-Data Item + + 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 format for + the DLEP Data Item; see [RFC8175], 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: + + 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 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 suppression is when output queues are + shared across all destinations. Destination-specific suppression + 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 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. + + While there is no restriction on the number of messages containing + Pause Data Items that may be sent by a modem, 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 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: + + 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 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 + 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. The extension + 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. + + 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 + + IANA has created a new DLEP registry named "Queue Parameter Sub-Data + Item Type Values". + + Table 4 provides initial registry values and the registration + policies [RFC8126] that apply: + + +-------------+------------------------+ + | 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 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. + Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, + DOI 10.17487/RFC8175, June 2017, + . + +6.2. Informative References + + [DLEP-CREDIT] + Cheng, B., Wiggins, D., Berger, L., and S. Ratliff, "DLEP + Credit-Based Flow Control Messages and Data Items", Work + in Progress, Internet-Draft, draft-ietf-manet-dlep-credit- + flow-control-04, 6 March 2019, + . + + [DLEP-DIFFSERV] + Cheng, B., Wiggins, D., and L. Berger, "DLEP DiffServ + Aware Credit Window Extension", Work in Progress, + Internet-Draft, draft-ietf-manet-dlep-da-credit-extension- + 07, 6 March 2019, + . + + [IEEE.802.1Q_2014] + IEEE, "IEEE Standard for Local and metropolitan area + networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, + . + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + DOI 10.17487/RFC2474, December 1998, + . + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, + . + + [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and + M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit + Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, + February 2010, . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + +Acknowledgments + + The format for the Sub-Data Item was inspired by Rick Taylor's "Data + Item Containers" idea. + +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 -- cgit v1.2.3