| rfc9893v2.txt | rfc9893.txt | |||
|---|---|---|---|---|
| skipping to change at line 20 ¶ | skipping to change at line 20 ¶ | |||
| LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
| November 2025 | November 2025 | |||
| Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages | Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages | |||
| and Data Items | and Data Items | |||
| Abstract | Abstract | |||
| This document defines new Dynamic Link Exchange Protocol (DLEP) Data | This document defines new Dynamic Link Exchange Protocol (DLEP) Data | |||
| Items that are used to support credit-based flow control. Credit | Items that are used to support credit-based flow control. Credit | |||
| window control is used to regulate when data may be sent to an | window flow control is used to regulate when data may be sent to an | |||
| associated virtual or physical queue. These Data Items are | associated virtual or physical queue. These Data Items are | |||
| extensible and reusable. | extensible and reusable. | |||
| Status of This Memo | Status of This Memo | |||
| This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
| This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
| (IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
| received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
| skipping to change at line 57 ¶ | skipping to change at line 57 ¶ | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Revised BSD License text as described in Section 4.e of the | include Revised BSD License text as described in Section 4.e of the | |||
| Trust Legal Provisions and are provided without warranty as described | Trust Legal Provisions and are provided without warranty as described | |||
| in the Revised BSD License. | in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction | 1. Introduction | |||
| 1.1. Key Words | 1.1. Key Words | |||
| 2. Credit Window Control | 2. Credit Window Flow Control | |||
| 2.1. Data Plane Considerations | 2.1. Data Plane Considerations | |||
| 2.2. Credit Window Messages | 2.2. Credit Window Messages | |||
| 2.2.1. Credit Control Message | 2.2.1. Credit Control Message | |||
| 2.2.2. Credit Control Response Message | 2.2.2. Credit Control Response Message | |||
| 2.3. Credit Window Control Data Items | 2.3. Data Items for the Control of Credit Windows | |||
| 2.3.1. Credit Window Initialization | 2.3.1. Credit Window Initialization | |||
| 2.3.2. Credit Window Association | 2.3.2. Credit Window Association | |||
| 2.3.3. Credit Window Grant | 2.3.3. Credit Window Grant | |||
| 2.3.4. Credit Window Status | 2.3.4. Credit Window Status | |||
| 2.3.5. Credit Window Request | 2.3.5. Credit Window Request | |||
| 2.4. Management Considerations | 2.4. Management Considerations | |||
| 3. Compatibility | 3. Compatibility | |||
| 4. Security Considerations | 4. Security Considerations | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| 5.1. Message Type Values | 5.1. Message Type Values | |||
| skipping to change at line 154 ¶ | skipping to change at line 154 ¶ | |||
| basis. The Data Items are structured to allow for the reuse of the | basis. The Data Items are structured to allow for the reuse of the | |||
| defined credit-window-based flow control with different traffic | defined credit-window-based flow control with different traffic | |||
| classification techniques. A router logically consumes credits for | classification techniques. A router logically consumes credits for | |||
| each credit window matching packet sent. | each credit window matching packet sent. | |||
| Note that this document defines common messages, Data Items, and | Note that this document defines common messages, Data Items, and | |||
| mechanisms that are reusable. They are expected to be required by | mechanisms that are reusable. They are expected to be required by | |||
| DLEP extensions defined in other documents, such as the extension | DLEP extensions defined in other documents, such as the extension | |||
| defined in [RFC9894]. | defined in [RFC9894]. | |||
| This document introduces support for credit window control by | This document introduces support for credit window flow control by | |||
| defining two new DLEP messages (Section 2.2) and five new DLEP Data | defining two new DLEP messages (Section 2.2) and five new DLEP Data | |||
| Items (Section 2.3). | Items (Section 2.3). | |||
| Various conditions described in this document cause a message to be | Various conditions described in this document cause a message to be | |||
| logged. In all cases, the log message results from the contents of a | logged. In all cases, the log message results from the contents of a | |||
| received Data Item defined here. No messages are logged in response | received Data Item defined here. No messages are logged in response | |||
| to activity in the data plane. | to activity in the data plane. | |||
| 1.1. Key Words | 1.1. Key Words | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Credit Window Control | 2. Credit Window Flow Control | |||
| This section defines additions to DLEP used in credit-based flow | This section defines additions to DLEP used in credit-based flow | |||
| control. The use of credit window control impacts the data plane. | control. The additions provide the DLEP mechanisms to control | |||
| credits. Routers then use this information to regulate when data is | ||||
| sent to a modem. | ||||
| The credit window control mechanisms defined in this document support | The credit window flow control mechanisms defined in this document | |||
| credit-based flow control of traffic sent from a router to a modem. | support credit-based flow control of traffic sent from a router to a | |||
| The mapping of specific flows to a particular credit window is based | modem. The mapping of specific flows to a particular credit window | |||
| on the Traffic Classification Data Item defined in [RFC9892]. Both | is based on the Traffic Classification Data Item defined in | |||
| types of DLEP peers -- router and modem -- negotiate the use of an | [RFC9892]. Both types of DLEP peers -- router and modem -- negotiate | |||
| extension employing this mechanism during session initialization as | the use of an extension employing this mechanism during session | |||
| required; for example, see [RFC9894]. When using credit windows, | initialization as required; for example, see [RFC9894]. When using | |||
| data traffic is only allowed to be sent by the router to the modem | credit windows, data traffic is only allowed to be sent by the router | |||
| when there are credits available. | to the modem when there are credits available. | |||
| Credits are managed on a 'per logical "Credit Window"' basis. Each | Credits are managed on a 'per logical "Credit Window"' basis. Each | |||
| credit window can be thought of as corresponding to a queue within a | credit window can be thought of as corresponding to a queue within a | |||
| modem. Credit windows may be shared across, or dedicated to, | modem. Credit windows may be shared across, or dedicated to, | |||
| destinations and data plane identifiers -- for example, DSCPs -- at a | destinations and data plane identifiers -- for example, DSCPs -- at a | |||
| granularity that is appropriate for a modem's implementation and its | granularity that is appropriate for a modem's implementation and its | |||
| attached transmission technology. As specified in Section 2.3.1, | attached transmission technology. As specified in Section 2.3.1, | |||
| there is a direct one-to-one mapping of credit windows to flows as | there is a direct one-to-one mapping of credit windows to flows as | |||
| identified by Flow Identifiers (FIDs) carried within the Traffic | identified by Flow Identifiers (FIDs) carried within the Traffic | |||
| Classification Data Item. Modems pass to the router information on | Classification Data Item. Modems pass to the router information on | |||
| their credit windows and FIDs prior to a router being able to send | their credit windows and FIDs prior to a router being able to send | |||
| data when an extension requiring the use of credit window control is | data when an extension requiring the use of credit window flow | |||
| used. Note that Traffic Classification Identifier (TID) values and | control is used. Note that Traffic Classification Identifier (TID) | |||
| FID values are significant only to the issuing modem. There is no | values and FID values are significant only to the issuing modem. | |||
| relationship implied by the same TID or FID value being issued by | There is no relationship implied by the same TID or FID value being | |||
| more than one modem. In addition to the traffic classification | issued by more than one modem. In addition to the traffic | |||
| information associated with a FID, modems provide an initial credit | classification information associated with a FID, modems provide an | |||
| window size, as well as the maximum size of the logical queue | initial credit window size, as well as the maximum size of the | |||
| associated with each credit window. The maximum size is included for | logical queue associated with each credit window. The maximum size | |||
| informative and potential future uses. | is included for informative and potential future uses. | |||
| Modems provide an initial credit window size at the time of "Credit | Modems provide an initial credit window size at the time of "Credit | |||
| Window Initialization". Such initialization can take place during | Window Initialization". Such initialization can take place during | |||
| session initiation or any point thereafter. It can also take place | session initiation or any point thereafter. It can also take place | |||
| when rate information changes. An increment to a credit window size, | when rate information changes. An increment to a credit window size, | |||
| specified in a Credit Grant Data Item, is provided in a Destination | specified in a Credit Grant Data Item, is provided in a Destination | |||
| Up Message (Section 2.3.2) or Credit Control Message (Section 2.2.1). | Up Message (Section 2.3.2) or Credit Control Message (Section 2.2.1). | |||
| A router provides its view of the Credit Window, which is known as | A router provides its view of the Credit Window, which is known as | |||
| "Status", in Destination Up Response Messages (Section 2.3.3) and | "Status", in Destination Up Response Messages (Section 2.3.3) and | |||
| Credit Control Response Messages (Section 2.2.2). Routers can also | Credit Control Response Messages (Section 2.2.2). Routers can also | |||
| skipping to change at line 255 ¶ | skipping to change at line 257 ¶ | |||
| support router traffic classification, based on the FIDs contained in | support router traffic classification, based on the FIDs contained in | |||
| the TID; see [RFC9892]. As defined, each credit window has a | the TID; see [RFC9892]. As defined, each credit window has a | |||
| corresponding FID, so traffic is mapped to a credit window by | corresponding FID, so traffic is mapped to a credit window by | |||
| locating a matching FID that is contained in the TID that is | locating a matching FID that is contained in the TID that is | |||
| associated with the traffic's destination. This means that the use | associated with the traffic's destination. This means that the use | |||
| of FIDs and TIDs, and the association of a TID to a DLEP destination, | of FIDs and TIDs, and the association of a TID to a DLEP destination, | |||
| enable a modem to share or dedicate resources as needed to match the | enable a modem to share or dedicate resources as needed to match the | |||
| specifics of its implementation and its attached transmission | specifics of its implementation and its attached transmission | |||
| technology. | technology. | |||
| Credit window control as defined in this document has objectives | Credit window flow control as defined in this document has objectives | |||
| similar to the control technique described in | similar to the control technique described in | |||
| [Credit-Window-Extension]. One notable difference from that type of | [Credit-Window-Extension]. One notable difference from that type of | |||
| credit control is that in this document, credits are never provided | credit control is that in this document, credits are never provided | |||
| by the router to the modem. | by the router to the modem. | |||
| 2.1. Data Plane Considerations | 2.1. Data Plane Considerations | |||
| When credit windowing is used, a router MUST NOT send data traffic to | When credit windowing is used, a router MUST NOT send data traffic to | |||
| a modem for forwarding if there is no matching classifier. If a | a modem for forwarding if there is no matching classifier. If a | |||
| matching classifier is found, a router MUST NOT send data traffic to | matching classifier is found, a router MUST NOT send data traffic to | |||
| skipping to change at line 284 ¶ | skipping to change at line 286 ¶ | |||
| document defines credit windows in octets, and the credit window is | document defines credit windows in octets, and the credit window is | |||
| decremented by the number of sent octets. | decremented by the number of sent octets. | |||
| A router MUST identify the credit window associated with traffic to | A router MUST identify the credit window associated with traffic to | |||
| be sent to a modem based on the traffic classification information | be sent to a modem based on the traffic classification information | |||
| provided in the Data Items defined in this document. | provided in the Data Items defined in this document. | |||
| 2.2. Credit Window Messages | 2.2. Credit Window Messages | |||
| This document defines two new messages that support credit window | This document defines two new messages that support credit window | |||
| control: Credit Control Messages and Credit Control Response | flow control: Credit Control Messages and Credit Control Response | |||
| Messages. Sending and receiving both message types is REQUIRED to | Messages. Sending and receiving both message types is REQUIRED to | |||
| support the credit window control mechanisms defined in this | support the credit window flow control mechanisms defined in this | |||
| document. | document. | |||
| 2.2.1. Credit Control Message | 2.2.1. Credit Control Message | |||
| Credit Control Messages are sent by modems and routers. Each sender | Credit Control Messages are sent by modems and routers. Each sender | |||
| is only permitted to have one message outstanding at one time. That | is only permitted to have one message outstanding at one time. That | |||
| is, a sender (either modem or router) MUST NOT send a subsequent | is, a sender (either modem or router) MUST NOT send a subsequent | |||
| Credit Control Message until a Credit Control Response Message has | Credit Control Message until a Credit Control Response Message has | |||
| been received from its peer. | been received from its peer. | |||
| skipping to change at line 349 ¶ | skipping to change at line 351 ¶ | |||
| more Credit Window Grant Data Items. A Data Item for every Credit | more Credit Window Grant Data Items. A Data Item for every Credit | |||
| Window Request Data Item contained in the corresponding Credit | Window Request Data Item contained in the corresponding Credit | |||
| Control Message received by the modem MUST be included. Each Credit | Control Message received by the modem MUST be included. Each Credit | |||
| Grant Data Item MAY provide zero or more additional credits based on | Grant Data Item MAY provide zero or more additional credits based on | |||
| the modem's transmission or local queue availability. Specific | the modem's transmission or local queue availability. Specific | |||
| receive processing associated with each Grant Data Item is provided | receive processing associated with each Grant Data Item is provided | |||
| in Section 2.3.3. | in Section 2.3.3. | |||
| The Message Type value in the DLEP Message Header is set to 18. | The Message Type value in the DLEP Message Header is set to 18. | |||
| 2.3. Credit Window Control Data Items | 2.3. Data Items for the Control of Credit Windows | |||
| Five new Data Items are defined to support credit window control: | Five new Data Items are defined to support the control of credit | |||
| windows: | ||||
| * The Credit Window Initialization Data Item (Section 2.3.1) is used | * The Credit Window Initialization Data Item (Section 2.3.1) is used | |||
| by a modem to identify a credit window and set its size. | by a modem to identify a credit window and set its size. | |||
| * The Credit Window Association Data Item (Section 2.3.2) is used by | * The Credit Window Association Data Item (Section 2.3.2) is used by | |||
| a modem to identify which TIDs (flows) should be used when sending | a modem to identify which TIDs (flows) should be used when sending | |||
| traffic to a particular DLEP-identified destination. | traffic to a particular DLEP-identified destination. | |||
| * The Credit Window Grant Data Item (Section 2.3.3) is used by a | * The Credit Window Grant Data Item (Section 2.3.3) is used by a | |||
| modem to provide additional credits to a router. | modem to provide additional credits to a router. | |||
| skipping to change at line 502 ¶ | skipping to change at line 505 ¶ | |||
| The Credit Window Association Data Item is used by a modem to | The Credit Window Association Data Item is used by a modem to | |||
| associate traffic classification information with a destination. The | associate traffic classification information with a destination. The | |||
| traffic classification information is identified using a TID value | traffic classification information is identified using a TID value | |||
| that has been previously sent by the modem or is listed in a Traffic | that has been previously sent by the modem or is listed in a Traffic | |||
| Classification Data Item carried in the same message as the Credit | Classification Data Item carried in the same message as the Credit | |||
| Window Association Data Item. TIDs in different credit windows must | Window Association Data Item. TIDs in different credit windows must | |||
| not overlap. | not overlap. | |||
| A single Credit Window Association Data Item MUST be included in | A single Credit Window Association Data Item MUST be included in | |||
| every Destination Up and Destination Update Message sent by a modem | every Destination Up and Destination Update Message sent by a modem | |||
| when a credit window control mechanism defined in this document is | when a credit window flow control mechanism defined in this document | |||
| used. Note that a TID will not be used unless it is listed in a | is used. Note that a TID will not be used unless it is listed in a | |||
| Credit Window Association Data Item. | Credit Window Association Data Item. | |||
| The format of the Credit Window Association Data Item is as follows: | The format of the Credit Window Association Data Item is as follows: | |||
| 0 1 2 3 | 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 | 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 (2) | | | Data Item Type | Length (2) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |Traffic Class. Identifier (TID)| | |Traffic Class. Identifier (TID)| | |||
| skipping to change at line 759 ¶ | skipping to change at line 762 ¶ | |||
| increment for the indicated credit windows via Credit Window Grant | increment for the indicated credit windows via Credit Window Grant | |||
| Data Items carried in a new Credit Control Message. Multiple values | Data Items carried in a new Credit Control Message. Multiple values | |||
| and queue indexes SHOULD be combined into a single Credit Control | and queue indexes SHOULD be combined into a single Credit Control | |||
| Message when possible. Unknown FID values SHOULD be logged and then | Message when possible. Unknown FID values SHOULD be logged and then | |||
| ignored by the modem. The method of logging is left to the modem | ignored by the modem. The method of logging is left to the modem | |||
| implementation. | implementation. | |||
| 2.4. Management Considerations | 2.4. Management Considerations | |||
| This section provides several network management guidelines for | This section provides several network management guidelines for | |||
| implementations supporting the credit window mechanisms defined in | implementations supporting the credit window flow control mechanisms | |||
| this document. | defined in this document. | |||
| Modems MAY support the configuration of the number of credit windows | Modems MAY support the configuration of the number of credit windows | |||
| (queues) to advertise to a router. | (queues) to advertise to a router. | |||
| Routers may have limits on the number of queues that they can | Routers may have limits on the number of queues that they can | |||
| support. They may even have limits on supported credit window | support. They may even have limits on supported credit window | |||
| combinations. For example, per-destination queues may not be | combinations. For example, per-destination queues may not be | |||
| supported at all. When credit window information provided by a modem | supported at all. When credit window information provided by a modem | |||
| exceeds the capabilities of a router, the router SHOULD use a subset | exceeds the capabilities of a router, the router SHOULD use a subset | |||
| of the provided credit windows. Alternatively, a router MAY reset | of the provided credit windows. Alternatively, a router MAY reset | |||
| skipping to change at line 790 ¶ | skipping to change at line 793 ¶ | |||
| The messages and Data Items defined in this document will only be | The messages and Data Items defined in this document will only be | |||
| used when extensions require their use. | used when extensions require their use. | |||
| The DLEP specification [RFC8175] defines the handling of unexpected | The DLEP specification [RFC8175] defines the handling of unexpected | |||
| appearances of any Data Items, including those defined in this | appearances of any Data Items, including those defined in this | |||
| document. | document. | |||
| 4. Security Considerations | 4. Security Considerations | |||
| This document introduces credit window control and flow mechanisms | This document introduces credit window flow control mechanisms for | |||
| for DLEP. These mechanisms expose vulnerabilities similar to | DLEP. These mechanisms expose vulnerabilities similar to existing | |||
| existing DLEP messages. An example of a threat to which flow control | DLEP messages. An example of a threat to which flow control might be | |||
| might be susceptible is where a malicious actor masquerading as a | susceptible is where a malicious actor masquerading as a DLEP peer | |||
| DLEP peer could inject a Credit Window Initialization Data Item that | could inject a Credit Window Initialization Data Item that resizes a | |||
| resizes a credit window to a value that results in a denial of | credit window to a value that results in a denial of service. Other | |||
| service. Other possible threats are discussed in the Security | possible threats are discussed in the Security Considerations section | |||
| Considerations section of [RFC8175] and are also applicable, but not | of [RFC8175] and are also applicable, but not specific, to flow | |||
| specific, to flow control. The transport-layer security mechanisms | control. The transport-layer security mechanisms documented in | |||
| documented in [RFC8175], with some updated references to external | [RFC8175], with some updated references to external documents listed | |||
| documents listed below, can be applied to this document. | below, can be applied to this document. Implementations following | |||
| Implementations following the "networked deployment" model described | the "networked deployment" model described in Section 4 | |||
| in Section 4 ("Implementation Scenarios") of [RFC8175] SHOULD refer | ("Implementation Scenarios") of [RFC8175] SHOULD refer to [BCP195] | |||
| to [BCP195] for additional details. The Layer 2 security mechanisms | for additional details. The Layer 2 security mechanisms documented | |||
| documented in [RFC8175] can also, with some updates, be applied to | in [RFC8175] can also, with some updates, be applied to the | |||
| the mechanisms defined in this document. Examples of technologies | mechanisms defined in this document. Examples of technologies that | |||
| that can be deployed to secure the Layer 2 link include | can be deployed to secure the Layer 2 link include [IEEE-802.1AE] and | |||
| [IEEE-802.1AE] and [IEEE-8802-1X]. | [IEEE-8802-1X]. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| 5.1. Message Type Values | 5.1. Message Type Values | |||
| IANA has assigned two new values from the "Specification Required" | IANA has assigned two new values from the "Specification Required" | |||
| range [RFC8126] in the DLEP "Message Type Values" registry: | range [RFC8126] in the DLEP "Message Type Values" registry: | |||
| +===========+=========================+ | +===========+=========================+ | |||
| | Type Code | Description | | | Type Code | Description | | |||
| End of changes. 16 change blocks. | ||||
| 51 lines changed or deleted | 54 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||