draft-ietf-manet-dlep-da-credit-extension-01.txt | draft-ietf-manet-dlep-da-credit-extension-02.txt | |||
---|---|---|---|---|
Network Working Group B. Cheng | Network Working Group B. Cheng | |||
Internet-Draft D. Wiggins | Internet-Draft D. Wiggins | |||
Intended status: Standards Track Lincoln Laboratory | Intended status: Standards Track Lincoln Laboratory | |||
Expires: September 14, 2017 L. Berger | Expires: May 3, 2018 L. Berger | |||
LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
March 13, 2017 | October 30, 2017 | |||
DLEP DiffServ Aware Credit Windowing Extension | DLEP DiffServ Aware Credit Windowing Extension | |||
draft-ietf-manet-dlep-da-credit-extension-01 | draft-ietf-manet-dlep-da-credit-extension-02 | |||
Abstract | Abstract | |||
This document defines an extension to the DLEP protocol that enables | This document defines an extension to the DLEP protocol that enables | |||
a DiffServ aware credit-windowing scheme for destination-specific | a DiffServ aware credit-windowing scheme for destination-specific and | |||
flow control. | shared flow control. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 14, 2017. | This Internet-Draft will expire on May 3, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
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 Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 | 2. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Extension Usage and Identification . . . . . . . . . . . . . 4 | 3. Extension Usage and Identification . . . . . . . . . . . . . 5 | |||
4. Data Plane Considerations . . . . . . . . . . . . . . . . . . 4 | 4. Data Plane Considerations . . . . . . . . . . . . . . . . . . 5 | |||
5. Extension Messages . . . . . . . . . . . . . . . . . . . . . 4 | 5. Extension Messages . . . . . . . . . . . . . . . . . . . . . 5 | |||
5.1. Credit Control Message . . . . . . . . . . . . . . . . . 4 | 5.1. Credit Control Message . . . . . . . . . . . . . . . . . 5 | |||
5.2. Credit Control Response Message . . . . . . . . . . . . . 5 | 5.2. Credit Control Response Message . . . . . . . . . . . . . 6 | |||
6. Extension Data Items . . . . . . . . . . . . . . . . . . . . 5 | 6. Extension Data Items . . . . . . . . . . . . . . . . . . . . 6 | |||
6.1. Queue Parameters . . . . . . . . . . . . . . . . . . . . 6 | 6.1. Credit Window Initialization . . . . . . . . . . . . . . 7 | |||
6.2. DiffServ Aware (DA) Credit Grant . . . . . . . . . . . . 8 | 6.2. Credit Window Traffic Classification . . . . . . . . . . 9 | |||
6.3. DiffServ Aware (DA) Credit Window Status . . . . . . . . 10 | 6.2.1. Traffic Classification Sub Data Item . . . . . . . . 11 | |||
6.4. DiffServ Aware (DA) Credit Request . . . . . . . . . . . 12 | 6.2.2. DiffServ Traffic Classification Sub Data Item . . . . 11 | |||
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6.3. Credit Window Associate . . . . . . . . . . . . . . . . . 13 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 6.4. Credit Window Credit Grant . . . . . . . . . . . . . . . 14 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 6.5. Credit Window Status . . . . . . . . . . . . . . . . . . 15 | |||
9.1. Extension Type Value . . . . . . . . . . . . . . . . . . 13 | 6.6. Credit Window Request . . . . . . . . . . . . . . . . . . 17 | |||
9.2. Message Values . . . . . . . . . . . . . . . . . . . . . 14 | 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.3. Data Item Values . . . . . . . . . . . . . . . . . . . . 14 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 9.1. Extension Type Value . . . . . . . . . . . . . . . . . . 18 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 15 | 9.2. Message Values . . . . . . . . . . . . . . . . . . . . . 19 | |||
Appendix A. Open and Resolved Issues . . . . . . . . . . . . . . 15 | 9.3. Data Item Values . . . . . . . . . . . . . . . . . . . . 19 | |||
A.1. Merge with [I-D.ietf-manet-credit-window] . . . . . . . . 15 | 9.4. DLEP Sub Data Item Registry . . . . . . . . . . . . . . . 20 | |||
A.2. Credit Windows Shared Across Destinations . . . . . . . . 16 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
A.3. Supporting Router Limits . . . . . . . . . . . . . . . . 16 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 | |||
A.4. Absolute vs Increment . . . . . . . . . . . . . . . . . . 16 | 10.2. Informative References . . . . . . . . . . . . . . . . . 21 | |||
A.5. Alternate Format Encoding . . . . . . . . . . . . . . . . 16 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 21 | |||
A.6. Bidirectional Flow | Appendix B. Open and Resolved Issues . . . . . . . . . . . . . . 21 | |||
Control (closed) . . . . . . . . . . . . . . . . . . . . 17 | B.1. Merge with [I-D.ietf-manet-credit-window] . . . . . . . . 21 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | B.2. Supporting Router Limits . . . . . . . . . . . . . . . . 22 | |||
B.3. Absolute vs Increment . . . . . . . . . . . . . . . . . . 22 | ||||
B.4. Bidirectional Flow | ||||
Control (closed) . . . . . . . . . . . . . . . . . . . . 22 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
1. Introduction | 1. Introduction | |||
The Dynamic Link Event Protocol (DLEP) is defined in | The Dynamic Link Event Protocol (DLEP) is defined in [RFC8175]. It | |||
[I-D.ietf-manet-dlep]. It provides the exchange of link related | provides the exchange of link related control information between | |||
control information between DLEP peers. DLEP peers are comprised of | DLEP peers. DLEP peers are comprised of a modem and a router. DLEP | |||
a modem and a router. DLEP defines a base set of mechanisms as well | defines a base set of mechanisms as well as support for possible | |||
as support for possible extensions. This document defines one such | extensions. This document defines one such extension. | |||
extension. | ||||
The base DLEP specification does not include any flow control | The base DLEP specification does not include any flow control | |||
capability. There are various flow control theoretically possible | capability. There are various flow control theoretically possible | |||
with DLEP. For example, a credit-windowing scheme for destination- | with DLEP. For example, a credit-windowing scheme for destination- | |||
specific flow control which provides aggregate flow control for both | specific flow control which provides aggregate flow control for both | |||
modem and routers has been proposed in | modem and routers has been proposed in | |||
[I-D.ietf-manet-credit-window]. | [I-D.ietf-manet-credit-window]. | |||
This document defines a DLEP extension which provides flow control | This document defines a DLEP extension which provides an alternate | |||
for DiffServ [RFC2475] traffic sent from a router to a modem. Flow | flow control mechanism for traffic sent from a router to a modem. | |||
control is provided for multiple DSCPs (differentiated services | Flow control is provide using one or more logical "Credit Windows", | |||
codepoint), which are grouped into logical sets of logical queues. | each of which will typically be supported by an associated virtual or | |||
physical queue. Traffic sent by a router will use traffic | ||||
classification information provided by the modem to identify which | ||||
traffic is associated with each credit window. (For general | ||||
background on traffic classification see [RFC2475] Section 2.3.) | ||||
This document supports traffic classification based on DLEP | ||||
destination and DiffServ [RFC2475] DSCPs (differentiated services | ||||
codepoints). Credit windows may be shared or dedicated on a per | ||||
{destination, DSCP} tuple basis. Said another way, the defined | ||||
mechanism allows for credit windows to be shared across traffic sent | ||||
to multiple DLEP destinations and DSCPs, or used exclusively for | ||||
traffic sent to a particular destination and/or DSCP. The extension | ||||
also supports the "wildcard" matching of any DSCP. | ||||
The extension defined in this document is referred to as "DiffServ | The extension defined in this document is referred to as "DiffServ | |||
Aware Credit Windowing" or, more simply, the "DA Credit" extension. | Aware Credit Windowing" or, more simply, the "DA Credit" extension. | |||
The extension is structured to allow for reuse of the defined credit | ||||
window based flow control with traffic classification techniques | ||||
other than DiffServ, e.g., IEEE 802.1 Q priority code points or even | ||||
5-tuple IP flows. | ||||
This document defines a new DLEP Extension Type Value in Section 3 | This document defines a new DLEP Extension Type Value in Section 3 | |||
which is used to indicate the use of the extension. Two new messages | which is used to indicate the use of the extension. Two new messages | |||
are defined in Section 5, and four new DLEP Data Items in Section 6. | are defined in Section 5, and six new DLEP Data Items in Section 6. | |||
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 BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14, RFC 2119 [RFC2119]. | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | ||||
2. Extension Overview | 2. Extension Overview | |||
The DA Credit extension can be used to support credit based flow | The DA Credit extension can be used to support credit based flow | |||
control of traffic sent from a router to a modem. The extension can | control of traffic sent from a router to a modem. The extension can | |||
be used to support DiffServ and non-DiffServ based flow control. | be used to support DiffServ and non-DiffServ based flow control. | |||
Both types of DLEP endpoints, i.e., a router and a modem, negotiate | Both types of DLEP endpoints, i.e., a router and a modem, negotiate | |||
the use of extension during session initialization, see Section 5.2 | the use of extension during session initialization, see Section 5.2 | |||
[I-D.ietf-manet-dlep]. When using this extension, data is allowed to | ||||
be sent by the router to the modem only when there are credits | ||||
available. | ||||
When the extension is to be used, a modem passes to a router its | [RFC8175]. When using this extension, data is allowed to be sent by | |||
known DSCPs, if any. DSCPs are grouped by logical queues, each of | the router to the modem only when there are credits available. | |||
which are given a logical queue index. The queue index zero (0) is | ||||
special and is used for any DSCP value, including 0, which is not | ||||
otherwise identified by the modem. The modem also provides a size, | ||||
in bytes, of the logical queue for informative and, potential, future | ||||
uses. Currently, only DSCP to logical queue index value mapping is | ||||
used in flow control operation. | ||||
The DA Credit extension supports credit based flow control on a per | Credits are managed on a per logical "Credit Windows" basis. Each | |||
MAC address destination, per queue index basis. Modems provide the | credit window can be thought of as corresponding to a queue within a | |||
initial size of the associated "Credit Window", i.e., the amount in | modem. Modems pass to the router information on its credit windows | |||
octets (bytes) that may be sent by the router to the modem, when a | and identify each via a "Credit Window Identifier", or "CID". In | |||
MAC destination becomes reachable and, optionally, when its rate | addition to the CID, credit window information includes an initial | |||
information changes. "Credit Increments", i.e., increases in a | credit window size, as well as the maximum size of the logical queue | |||
Credit Window size, are provided using new "Credit Control" messages. | associated with each CID. The maximum size is included for | |||
informative and, potential, future uses. | ||||
A router provides its view of the Credit Window, which is known as | As mentioned above, traffic classification supported by this document | |||
"status", in Destination Up Response and the new "Credit Control | is performed on a per {destination, DSCP} tuple basis. This means | |||
Response" messages. Routers can also request credits using the new | that, routers need the combination of the DLEP identified destination | |||
"Credit Control" message. | and DSCP associated with a CID in order to match traffic it sends to | |||
specific credit windows. Modems provide the mapping of DSCPs to CIDs | ||||
in sets, each of which is identified via a "Traffic Classification | ||||
Identifier" or "TID". When a destination becomes reachable, a modem | ||||
"Associates" (identifies) the TID to be used for traffic sent by the | ||||
router to that destination. This use of CIDs, TIDs and association | ||||
of a TID to a DLEP destination enables modem to share or dedicate | ||||
resources as needed to match the specifics of its implementation and | ||||
its attached transmission technology. | ||||
Credit information, both grants and status, is provided in new credit | Modems provide an initial credit window size at the time of "Credit | |||
grant related data items. Each data item contains a single credit | Window Initialization". Such initialization can take place during | |||
value that applies to one or more queue indexes. Different (grant | session initiation or any point thereafter. It can also take place | |||
and status) values for different queue indexes can be provided in a | when rate information changes. Additional "Credit Grants", i.e., | |||
single message by including multiple grant data items. The values | increments to Credit Window size, are provided using a Destination Up | |||
indicate a number of octets (bytes), including MAC headers on the | or the new "Credit Control" Message. A router provides its view of | |||
router to modem link, that may be sent. | the Credit Window, which is known as "Status", in Destination Up | |||
Response and the new "Credit Control Response" Messages. Routers can | ||||
also request credits using the new "Credit Control" Message. | ||||
Note that credit information related to different destination MAC | When modems provide credits to a router, they will need to take into | |||
addresses is always passed in different DLEP messages. | account any overhead of their attached transmission technology and | |||
map it into the credit semantics defined in this document. In | ||||
particular, the credit window is defined below to include per frame | ||||
(packet) MAC headers and this may not match the actual overhead of | ||||
the modem attached transmission technology. In that case a direct | ||||
mapping or an approximation will need to be made by the modem to | ||||
provide appropriate credit values. | ||||
3. Extension Usage and Identification | 3. Extension Usage and Identification | |||
The use of the extension defined in this document SHOULD be | The use of the extension defined in this document SHOULD be | |||
configurable. To indicate that the DiffServ Aware Credit Windowing | configurable. To indicate that the DiffServ Aware Credit Windowing | |||
Extension is to be used, an implementation MUST include the DiffServ | Extension is to be used, an implementation MUST include the DiffServ | |||
Aware Credit Windowing Type Value in the Extensions Supported Data | Aware Credit Windowing Type Value in the Extensions Supported Data | |||
Item. The Extensions Supported Data Item is sent and processed | Item. The Extensions Supported Data Item is sent and processed | |||
according to [I-D.ietf-manet-dlep]. | according to [RFC8175]. | |||
The DiffServ Aware Credit Windowing Extension Type Value is TBA1, see | The DiffServ Aware Credit Windowing Extension Type Value is TBA1, see | |||
Section 9. | Section 9. | |||
4. Data Plane Considerations | 4. Data Plane Considerations | |||
When the use of the extension defined in this document is agreed upon | When the use of the extension defined in this document is agreed upon | |||
per standard DLEP processing, see Section 3, a router MUST NOT send | per standard DLEP processing, see Section 3, a router MUST NOT send | |||
data to a modem for forwarding when there are no credits available in | data to a modem for forwarding when there are no credits available in | |||
the associated Credit Window. | the associated Credit Window. This document defines credit windows | |||
in octets. A credit window value MUST be larger than the number of | ||||
octets contained in a packet, including any MAC headers used between | ||||
the router and the modem, in order for the router to send the packet | ||||
to a modem for forwarding. The credit window is decremented by the | ||||
number of sent octets. | ||||
A router MUST identify the credit window associated with traffic sent | ||||
to a modem based on the traffic classification information provided | ||||
in the data items defined in this document. The definitions support | ||||
identification based on DLEP destination and, at the modem's | ||||
discretion, DSCPs. Note that routers will typically view a DLEP | ||||
destination as the next hop. | ||||
5. Extension Messages | 5. Extension Messages | |||
Two new messages are defined by this extension: the Credit Control | Two new messages are defined by this extension: the Credit Control | |||
and the Credit Control Response message. Sending and receiving both | and the Credit Control Response Message. Sending and receiving both | |||
message types MUST be supported by any implementation that advertises | message types MUST be supported by any implementation that advertises | |||
use of this extension per Section 3. | use of this extension per Section 3. | |||
5.1. Credit Control Message | 5.1. Credit Control Message | |||
Credit Control Messages are sent by modems to provide Credit | Credit Control Messages are sent by modems to provide credit window | |||
Increments. For messages sent by modems, only one message per MAC | increases. For messages sent by modems, only one message can be | |||
address can be outstanding at one time. That is, a modem MUST NOT | outstanding at one time. That is, a modem MUST NOT send a second (or | |||
send a second (or any subsequent) message containing the same MAC | any subsequent) Credit Control Message until a Credit Control | |||
Address until a Credit Control Response message is received from its | Response Message is received from its peer router. | |||
peer router with that MAC address. | ||||
Credit Control Messages MAY be sent by routers, e.g., to request | Credit Control Messages MAY be sent by routers, e.g., to request | |||
credits or provide window status. No specific response message is | credits or provide window status. No specific response message is | |||
required from a message transaction perspective. | required from a modem from a message transaction perspective. There | |||
is no restriction on when a router can send a Credit Control Message. | ||||
[TBD: Should anything be said about sending, or limiting, multiple | [TBD: Should anything be said about sending, or limiting, multiple | |||
credit requests?] | credit requests?] | |||
The Message Type value in the DLEP Message Header is set to TBA2. | The Message Type value in the DLEP Message Header is set to TBA2. | |||
The message MUST contain a DLEP MAC Address Data Item. | A message sent by a modem, MUST contain one or more Credit Window | |||
Grant Data Items as defined below in Section 6.4. A router receiving | ||||
A message sent by a modem, MUST contain one or more DiffServ Aware | this message MUST respond with a Credit Control Response Message. | |||
Credit Grant data items as defined below in Section 6.2. A router | ||||
receiving this message MUST respond with a Credit Control Response | ||||
Message. | ||||
A message sent by a router, MUST contain the DiffServ Aware Credit | A message sent by a router, MUST contain the Credit Window Request | |||
Request data item defined below in Section 6.4. A modem receiving | Data Item defined below in Section 6.6. A modem receiving this | |||
this message MUST provide a Credit Increment for the indicated MAC | message MUST process the received message and data item as defined | |||
address and queue indexes via a new Credit Control Message. | below, which will result in credit window increments being provided | |||
via Credit Window Grant Data Items carried in one more more new | ||||
Credit Control Message. | ||||
Specific processing associated with each Credit data item is provided | Specific processing associated with each Credit Data Item is provided | |||
below. | below. | |||
5.2. Credit Control Response Message | 5.2. Credit Control Response Message | |||
Credit Control Response Messages are sent by routers to report the | Credit Control Response Messages are sent by routers to report the | |||
current Credit Window for a destination. | current Credit Window for a destination. | |||
The Message Type value in the DLEP Message Header is set to TBA3. | The Message Type value in the DLEP Message Header is set to TBA3. | |||
The message MUST contain a DLEP MAC Address Data Item. | A message sent by a router, MUST contain one or more Credit Window | |||
Status data items as defined below in Section 6.5. | ||||
A message sent by a router, MUST contain one or more DiffServ Aware | ||||
Credit Window Status data items as defined below in Section 6.3. | ||||
Specific processing associated with the DA Credit Window Status data | Specific processing associated with the Credit Window Window Status | |||
item is provided below. | Data Item is provided below. | |||
6. Extension Data Items | 6. Extension Data Items | |||
Four data items are defined by this extension. The Queue Parameters | Six data items are defined by this extension. The Credit Window | |||
Data Item is used by a modem to provide information on the DSCPs it | Initialization Data Item is used by a modem to identify a credit | |||
uses in forwarding. The DA Credit Grant is used by a modem to | window and set its size. The Credit Window Traffic Classification | |||
provide credits to a router. The DA Credit Request is used by a | Data Item is used by a modem to identify a set which identifies which | |||
router to request additional credits. The DA Credit Window Status is | DSCPs are mapped to a credit window. The Credit Window Association | |||
used to advertise the sender's view of number of available credits | Data Item is used by a modem to identify which traffic classification | |||
for synchronization purposes. | set should be used when sending traffic to a particular DLEP | |||
identified destination. The Credit Window Grant is used by a modem | ||||
to provide additional credits to a router. The Credit Request is | ||||
used by a router to request additional credits. The Credit Window | ||||
Status is used to advertise the sender's view of number of available | ||||
credits for state synchronization purposes. | ||||
The defined data items and operations are similar to those found in | Any errors or inconsistencies encountered in parsing data items are | |||
[I-D.ietf-manet-credit-window]. One notable difference from this | handled in the same fashion as any other Data Item parsing error | |||
extension is that in this document credits are never provided by the | encountered in DLEP, see [RFC8175]. In particular, the node parsing | |||
router to the modem. | the data item MUST terminate the session with a Status Data Item | |||
indicating Invalid Data. | ||||
6.1. Queue Parameters | The defined data items and operations have similar objectives as | |||
those found in [I-D.ietf-manet-credit-window]. One notable | ||||
difference from this extension is that in this document credits are | ||||
never provided by the router to the modem. | ||||
The Queue Parameters Data Item is used by a modem to indicate DSCP | 6.1. Credit Window Initialization | |||
values that may be independently controlled. This data item MUST be | ||||
included in a Session Initialization Response Message that also | The Credit Window Initialization Data Item is used by a modem to | |||
identify a credit window and set its size. This data item SHOULD be | ||||
included in any Session Initialization Response Message that also | ||||
contains the DiffServ Aware Credit Windowing Extension Type Value in | contains the DiffServ Aware Credit Windowing Extension Type Value in | |||
the Extensions Supported Data Item. Updates to these parameters MAY | the Extensions Supported Data Item. Updates to previously identified | |||
be sent by a modem by including the data item in Session Update | credit windows or new credit windows MAY be sent by a modem by | |||
Messages. | including the data item in Session Update Messages. More than one | |||
data item MAY be included in a message to provide information on | ||||
multiple credit windows. | ||||
The Queue Parameters Data Item identifies DSCPs based on groups of | The Credit Window Initialization Data Item identifies a credit window | |||
logical queues. The number of logical queues is variable as is the | using a Credit Window Identifier, or CID. It also provides the size | |||
number of DSCPs associated with each queue. A queue size (in bytes) | of the identified credit window. Finally, a queue size (in bytes) is | |||
is provided for informational purposes. An implementation that does | provided for informational purposes. Note that to be used, a CID | |||
not support DSCPs would indicate 1 queue with 0 DSCPs, and the number | must be listed in a Credit Window Traffic Classification Data Item. | |||
of bytes that may be in its associated link transmit queue. | ||||
The format of the Queue Parameters Data Item is: | The format of the Credit Window Initialization Data Item is: | |||
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 | | | Data Item Type | Length (16) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Num Queues | Scale | Reserved | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|Num DSCPs Q0(0)| Queue Size Q0 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Num DSCPs Q1 | Queue Size Q1 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Num DSCPs Q2 | Queue Size Q2 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: ... : | | Credit Window Identifier (CID)| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Num DSCPs Qn | Queue Size Qn | | | Credit Value : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| DS Field Q1 | DS Field Q1 | DS Field Q1 | DS Field Q2 | | : Credit Value | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: ... | DS Field Qn | | | Scale | Credit Window Size | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBA4 | Data Item Type: TBA4 | |||
Length: Variable | Length: 16 | |||
Per [I-D.ietf-manet-dlep] Length is the number of octets in the | Per [RFC8175] Length is the number of octets in the data item, | |||
data item, excluding the Type and Length fields. | excluding the Type and Length fields. | |||
Num Queues: | Credit Window Identifier (CID): | |||
An 8-bit unsigned integer indicating the number of queues | A 16-bit unsigned integer identifying a credit window. The value | |||
represented in the data item. This field MUST contain a value of | of 0xFFFFFFFF is reserved and MUST not be used in this Data Item. | |||
at least one (1). Note that this number is one larger than the | There is no other restriction on values used by a modem, and there | |||
largest queue index value included in the data item. | is no requirement for sequential or ordered values. | |||
Reserved: | ||||
MUST be set to zero by the sender (a modem) and ignored by the | ||||
receiver (a router). | ||||
Credit Value: | ||||
A 64-bit unsigned integer representing the credits, in octets, to | ||||
be applied to the Credit Window. This value includes MAC headers | ||||
as seen on the link between the modem and router. | ||||
Scale: | Scale: | |||
An 4-bit unsigned integer indicating the scale used in the Queue | An 8-bit unsigned integer indicating the scale used in the Credit | |||
Size fields. The valid values are: | Window Size fields. The valid values are: | |||
Value Scale | Value Scale | |||
------------ | ------------ | |||
0 B - Bytes (Octets) | 0 B - Bytes (Octets) | |||
1 KB - Kilobytes (B/1024) | 1 KB - Kilobytes (B/1024) | |||
2 MB - Megabytes (KB/1024) | 2 MB - Megabytes (KB/1024) | |||
3 GB - Gigabytes (MB/1024) | 3 GB - Gigabytes (MB/1024) | |||
Credit Window Size: | ||||
A 24-bit unsigned integer representing the maximum size, in the | ||||
octet scale indicated by the Scale field, of the associated credit | ||||
window. | ||||
A router that receives a Credit Window Initialization Data Item MUST | ||||
locate the credit window that is associated with the CID indicated in | ||||
each received Data Item. If no associated credit window is found, | ||||
the router MUST initialize a new credit window using the values | ||||
carried in the Data Item. When an associated credit window is found, | ||||
the router MUST update the credit window using the values carried in | ||||
the Data Item. It is worth noting, that such updates can result in a | ||||
credit window size being reduced, for example, due to a transmission | ||||
rate change on the modem. | ||||
6.2. Credit Window Traffic Classification | ||||
The Credit Window Traffic Classification Data Item is used by a modem | ||||
to provide information to enable router to identify the credit window | ||||
associated with traffic the router sends. Each data item includes a | ||||
set of credit windows and provides traffic classification for each | ||||
window. The data item is defined to support classification based on | ||||
DSCPs, but is designed to be extensible for future traffic | ||||
classification types. The data item is not required to provide full | ||||
traffic classification information. In the context of the definition | ||||
included in this document, the DLEP destination address needed to | ||||
complete the traffic classification information is provided by a | ||||
modem when it identifies the traffic classification set in a | ||||
Destination Up message using the Credit Window Associate Data Item | ||||
defined below. | ||||
The Credit Window Traffic Classification Data Item SHOULD be included | ||||
by a modem in any Session Initialization Response Message that also | ||||
contains the DiffServ Aware Credit Windowing Extension Type Value in | ||||
the Extensions Supported Data Item. Updates to previously provided | ||||
traffic classifications or new traffic classifications MAY be sent by | ||||
a modem by including the data item in Session Update Messages. More | ||||
than one data item MAY be included in a message to provide | ||||
information on multiple traffic classifiers. | ||||
The set of traffic classification information provided in the data | ||||
item is identified using a Traffic Classification Identifier, or TID. | ||||
Addition information, e.g., the list DSCPs associated with a credit | ||||
window, is provided in a variable series of Queue Parameter sub-data | ||||
items. Note that to be used, a TID must be listed in a Credit Window | ||||
Associate Data Item. | ||||
The format of the Credit Window Traffic Classification 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 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|Traffic Class. Identifier (TID)| Num SDIs | Reserved | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Traffic Classification Sub Data Item 1 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
: ... : | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Traffic Classification Sub Data Item n | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Data Item Type: TBA5 | ||||
Length: Variable | ||||
Per [RFC8175] Length is the number of octets in the data item, | ||||
excluding the Type and Length fields. | ||||
Traffic Classification Identifier (TID): | ||||
A 16-bit unsigned integer identifying a traffic classification | ||||
set. There is no restriction on values used by a modem, and there | ||||
is no requirement for sequential or ordered values. | ||||
Num SDIs: | ||||
An 8-bit unsigned integer indicating the number of Traffic | ||||
Classification Sub Data Items included in the data item. A value | ||||
of zero (0) is allowed and indicates that no traffic should be | ||||
matched against this TID. | ||||
Reserved: | Reserved: | |||
MUST be set to zero by the sender (a modem) and ignored by the | MUST be set to zero by the sender (a modem) and ignored by the | |||
receiver (a router). | receiver (a router). | |||
Num DSCPs Qn: | Traffic Classification Sub Data Item: | |||
An 8-bit unsigned integer indicating the number of DSCPs | Zero or more Traffic Classification Sub Data Items of the format | |||
associated with the indexed queue. Other than the special case | defined below MAY be included. The number MUST match the value | |||
covered in the next paragraph, this field MUST contain a value of | carried in the Num SDIs field. | |||
at least one (1). Queue indexes start at zero (0) and the maximum | ||||
queue index "Qn" is one less than the value carried in the Num | ||||
Queues field. Queue indexes are implicit in the position in the | ||||
data item. | ||||
Queue index zero "Q0" is a special case. It is used for any | A router receiving the Traffic Classification Data Item MUST locate | |||
traffic that does not carry a DSCP value represented in the data | the traffic classification information that is associated with the | |||
item. Therefore the value of the Queue index zero field, "Num | TID indicated in each received Data Item. If no associated traffic | |||
DSCPs Q0", field MUST be zero (0). | classification information is found, the router MUST initialize a new | |||
information set using the values carried in the Data Item. When | ||||
associated traffic classification information is found, the router | ||||
MUST update the information using the values carried in the Data | ||||
Item. In both cases, a router MUST also ensure that any data plane | ||||
state, see Section 4, that is associated with the TID is updated as | ||||
needed. | ||||
Queue Size Qn: | 6.2.1. Traffic Classification Sub Data Item | |||
A 24-bit unsigned integer representing the size, in the octet | All Traffic Classification Sub Data Items share a common format that | |||
scale indicated by the Scale field, of the queue supporting | is patterned after the standard DLEP data item format, see [RFC8175] | |||
traffic with the DSCPs associated with the queue index. | Section 11.3. There is no requirement on, or meaning to Sub Data | |||
Item ordering. 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. | ||||
DS Field Qn: | The format of the Traffic Classification Sub Data Item is: | |||
The data item contains a sequence of 8 bit DS Fields. The | 0 1 2 3 | |||
position in the sequence identifies the associated queue index. | 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 | |||
The number of DS Fields present should equal the sum of all Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
DSCPs field values. | | Sub Data Item Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Value... : | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The DS Field structure is the same as [RFC2474]. | Sub Data Item Type: | |||
0 1 2 3 4 5 6 7 | A 16-bit unsigned integer that indicates the type and | |||
+---+---+---+---+---+---+---+---+ | corresponding format of the data item's Value field. Sub Data | |||
| DSCP | CU | | Item Types are managed according to the IANA registry described in | |||
+---+---+---+---+---+---+---+---+ | Section 9.4. | |||
DSCP: differentiated services codepoint | Length: Variable | |||
CU: currently unused, MUST be zero | ||||
6.2. DiffServ Aware (DA) Credit Grant | Copying [RFC8175], Length a 16-bit unsigned integer that is the | |||
number of octets in the sub data item, excluding the Type and | ||||
Length fields. | ||||
The DiffServ Aware, or DA, Credit Grant data item is used by a modem | 6.2.2. DiffServ Traffic Classification Sub Data Item | |||
to provide credits to a router. One or more DA Credit Grant data | ||||
items MAY be carried in the DLEP Destination Up, Destination Announce | ||||
Response, Destination Update, and Credit Control messages. Multiple | ||||
DA Credit Grant data items in a single message are used to indicated | ||||
different credit values for different logical queues. | ||||
In Destination type messages, this data item provides the total | The DiffServ Traffic Classification Sub Data Item is used to identify | |||
number of octets available in the Credit Window to the destination | the DSCPs associated with a specific credit window. Credit windows | |||
indicated in the message for the specified logical queues. In the | are identified using CID values that have been previously been sent | |||
Credit Control message, this data item provides an additional number | by the modem or are listed in a Credit Window Initialization Data | |||
of octets to be added to the Credit Window to the destination | Item carried in the same messages as the sub data item. DSCPs are | |||
indicated in the message for the specified logical queues. | identified in a list of DiffServ fields. An implementation that does | |||
not support DSCPs, and wants to use credit window flow control for | ||||
all traffic to a destination or destinations, would indicate with 0 | ||||
DSCPs. | ||||
Logical queues are identified using a Queue Index as defined above in | The format of the DiffServ Traffic Classification Sub Data Item is: | |||
Section 6.1. Multiple Queue Indexes MAY be present to allow for the | ||||
case where same credit information applies to multiple queues. As | ||||
mentioned above, multiple DA Credit Grant Data Items MAY be present | ||||
to provide different queue-specific credit information in one | ||||
message. The special Queue Index value of 255 is used to indicate | ||||
that the credit information applies to all queues. | ||||
The format of the DA Credit Grant 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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Must be two (2) | Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Credit Window Identifier (CID)| Num DSCPs | DS Field 1 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| DS Field 2 | ... | DS Field n | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Length: Variable | ||||
Length is the number of octets in the sub data item. It is equal | ||||
to seven (7) plus the value of the Num DSCPs field. | ||||
Credit Window Identifier (CID): | ||||
A 16-bit unsigned integer identifying a credit window that has | ||||
been identified in a Credit Window Initialization Data Item, see | ||||
Section 6.1. Unknown CID values SHOULD be reported and result in | ||||
associated traffic being dropped. | ||||
Num DSCPs: | ||||
An 8-bit unsigned integer indicating the number of DSCPs carried | ||||
in the sub data item. A zero (0) indicates a (wildcard) match | ||||
against any DSCP value. | ||||
DS Field: | ||||
Each DS Field is an 8-bit whose definition is the same as | ||||
[RFC2474]. | ||||
0 1 2 3 4 5 6 7 | ||||
+---+---+---+---+---+---+---+---+ | ||||
| DSCP | CU | | ||||
+---+---+---+---+---+---+---+---+ | ||||
DSCP: differentiated services codepoint | ||||
CU: currently unused, MUST be zero | ||||
A router receiving the DiffServ Traffic Classification Sub Data Item | ||||
MUST validate the information on receipt prior to the information and | ||||
data plan update described earlier in this section. The credit | ||||
window associated with the CID indicated in each Data Item must be | ||||
located. It is important to note that the CID value may be present | ||||
in a Credit Window Initialization Data Item carried in the same | ||||
message as the Sub Data Item. If the CID is not located, the it MUST | ||||
be treated as an error as described above. | ||||
In the case there are no unknown CIDs, the receiver MUST ensure that | ||||
each DS Field value is listed only once across the whole Credit | ||||
Window Traffic Classification Data Item. Note, this check is across | ||||
the Data Item and not the individual Sub Data Item. If the same DS | ||||
Field value is listed more than once within the same Credit Window | ||||
Traffic Classification Data Item, the Data Item MUST be treated as an | ||||
error as described above. | ||||
6.3. Credit Window Associate | ||||
The Credit Window Associate Data Item is used by a modem to associate | ||||
traffic classification information with a destination. The traffic | ||||
classification information is identified using a TID value that has | ||||
been previously been sent by the modem or is listed in a Credit | ||||
Window Traffic Classification Data Item carried in the same message | ||||
as the data item. | ||||
A single Credit Window Associate Data Item MUST be included in all | ||||
Destination Up and Destination Update Messages sent by a modem when | ||||
the use of the extension defined in this document is agreed upon, see | ||||
Section 3. | ||||
The format of the Credit Window Traffic Classification 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 (2) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|Traffic Class. Identifier (TID)| | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Data Item Type: TBA6 | ||||
Length: 2 | ||||
Per [RFC8175] Length is the number of octets in the data item, | ||||
excluding the Type and Length fields. | ||||
Traffic Classification Identifier (TID): | ||||
A 16-bit unsigned integer identifying a traffic classification set | ||||
that has been identified in a Credit Window Traffic Classification | ||||
Data Item, see Section 6.2. Unknown TID values SHOULD be reported | ||||
and result in associated traffic being dropped. | ||||
A router that receives the Credit Window Associate Data Item MUST | ||||
locate the traffic classification information indicated by the | ||||
received TID. If no corresponding information can be located, the | ||||
Data Item MUST be treated as an error as described above. Once the | ||||
traffic classification information is located, it MUST be associated | ||||
with the destination and the router MUST ensure that any data plane | ||||
state, see Section 4, that is associated with the TID is updated as | ||||
needed. | ||||
6.4. Credit Window Credit Grant | ||||
The Credit Window Credit Grant data item is used by a modem to | ||||
provide credits to a router. One or more Credit Window Grant Data | ||||
Items MAY be carried in the DLEP Destination Up, Destination Announce | ||||
Response, Destination Update, and Credit Control Messages. Multiple | ||||
Credit Window Grant Data Items in a single message are used to | ||||
indicate different credit values for different credit windows. In | ||||
all message types, this data item provides an additional number of | ||||
octets to be added to the indicated credit window. Credit window are | ||||
identified via using using CID values that have been previously been | ||||
sent by the modem or are listed in a Credit Window Initialization | ||||
Data Item carried in the same messages as the Data Item. | ||||
The format of the Credit Window Grant Data Item is: | ||||
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 | | | Data Item Type | Length (12) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Credit Value | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Credit value | | | Credit Window Identifier (CID)| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Queue Index | ... : | | Additional Credits : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: ... | Queue Index | | : Additional Credits | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBA5 | Data Item Type: TBA7 | |||
Length: Variable | ||||
Per [I-D.ietf-manet-dlep], Length is the number of octets in the | Length: 12 | |||
data item, excluding the Type and Length fields. It will equal 8 | Per [RFC8175], Length is the number of octets in the data item, | |||
plus the number of Queue Index fields carried in the data item and | excluding the Type and Length fields. It will equal 8 plus the | |||
MUST be at least 9. | number of CID fields carried in the data item and MUST be at least | |||
9. | ||||
Credit Value: | Credit Window Identifier (CID): | |||
A 64-bit unsigned integer representing the credits, in octets, to | A 16-bit unsigned integer identifying a credit window that has | |||
be applied to the Credit Window. This value includes MAC headers | been identified in a Credit Window Initialization Data Item, see | |||
as seen on the link between the modem and router. | Section 6.1. Unknown CID values SHOULD be reported and ignored. | |||
Queue Index: | Additional Credit: | |||
One or more 8-bit fields used to indicate a queue index defined by | A 64-bit unsigned integer representing the credits, in octets, to | |||
a Queue Parameters Data Item. The special value of 255 indicates | be added to the Credit Window. This value includes MAC headers as | |||
that the information in the data item applies to all queue | seen on the link between the modem and router. | |||
indexes. | ||||
Receive processing of this data item is based on the message in which | When receiving this data item, a router MUST identify the credit | |||
it is carried. When this data item is received in a Destination type | window indicated by the CID. If the CID is not known to the router, | |||
message, the Credit Window of the indicated destination MAC address | it SHOULD report or log this information and discard the Data Item. | |||
and indicated queue indexes MUST be set to the value contained in the | It is important to note that while this data item can be received in | |||
Credit Value field. | a destination specific message, credit windows are managed | |||
independently from the destination identified in the message carrying | ||||
this Data Item, and the indicated CID MAY even be disjoint from the | ||||
identified destination. | ||||
When this data item is received in a Credit Control message, the | Once the credit window is identified, the credit window size MUST be | |||
Credit Window of the indicated destination MAC address and indicated | increased by the value contained in the Additional Credits field. If | |||
queue indexes MUST be increased by the value contained in the Credit | the increase results in a window overflow, i.e., the size of the | |||
Value field. If the increase results in a window overflow, i.e., the | credit window after the increase is smaller than the original credit | |||
Credit Window resulting after the increase is smaller than the | window size, the Credit Window must be set to its maximum | |||
original Credit Window, the Credit Window must be set to its maximum | ||||
(0xFFFFFFFFFFFFFFFF). | (0xFFFFFFFFFFFFFFFF). | |||
Independent of the received message, the receiving router MUST send a | Independent of the received message, the receiving router MUST send a | |||
DA Credit Window Status data item or items reflecting the resulting | Credit Window Window Status data item or items reflecting the | |||
Credit Window value of each modified queue index. When the Credit | resulting Credit Window value of the updated credit window. When the | |||
Grant data item is received in a Destination Up message, the DA | Credit Grant data item is received in a Destination Up Message, the | |||
Credit Window Status data item(s) MUST be sent in the corresponding | Credit Window Window Status data item(s) MUST be sent in the | |||
Destination Up Response message. In all other cases, the a Credit | corresponding Destination Up Response Message. In all other cases, a | |||
Control message MUST be sent. | Credit Control Message MUST be sent. | |||
6.3. DiffServ Aware (DA) Credit Window Status | ||||
The DiffServ Aware, or DA, Credit Window Status data item is used by | 6.5. Credit Window Status | |||
a router to report the current Credit Window to its peer modem. One | ||||
or more DA Credit Window Status data items MAY be carried in a | ||||
Destination Up Response message or a Credit Control Response message. | ||||
As discussed above, the Destination Up Response message is used when | ||||
the data item is sent in response to a Destination Up message, and | ||||
the Credit Control Response message is sent in response to a Credit | ||||
Control message. Multiple DA Credit Window Status data items in a | ||||
single message are used to indicated different credit window values | ||||
for different logical queues. | ||||
Similar to the DA Credit Grant, logical queues are identified using a | The Credit Window Status data item is used by a router to report the | |||
Queue Index as defined above in Section 6.1. Multiple Queue Indexes | current credit window size to its peer modem. One or more Credit | |||
MAY be present to allow for the case where same credit information | Window Status data items MAY be carried in a Destination Up Response | |||
applies to multiple queues. Multiple DA Credit Window Status Data | Message or a Credit Control Response Message. As discussed above, | |||
Items are used to provide different queue-specific credit window | the Destination Up Response Message is used when the data item is | |||
information in one message. The special Queue Index value of 255 is | sent in response to a Destination Up Message, and the Credit Control | |||
used to indicate that the Credit Window information applies to all | Response Message is sent in response to a Credit Control Message. | |||
queues. | Multiple Credit Window Window Status data items in a single message | |||
are used to indicated different sizes of different credit windows. | ||||
Similar to the Credit Window Grant, credit windows are identified | ||||
using CID values that have been previously been sent by the modem. | ||||
The format of the DA Credit Window Status Data Item is: | The format of the Credit Window Window Status Data Item is: | |||
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 | | | Data Item Type | Length (12) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Credit Window : | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: Credit Window | | | Credit Window Identifier (CID)| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Queue Index | ... : | | Credit Window Size : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: ... | Queue Index | | : Credit Window Size | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBA6 | Data Item Type: TBA8 | |||
Length: Variable | Length: 12 | |||
Per [I-D.ietf-manet-dlep] Length is the number of octets in the | Per [RFC8175] Length is the number of octets in the data item, | |||
data item, excluding the Type and Length fields. It will equal 8 | excluding the Type and Length fields. It will equal 8 plus the | |||
plus the number of Queue Index fields carried in the data item and | number of CID fields carried in the data item and MUST be at least | |||
MUST be at least 9. | 9. | |||
Credit Window: | Credit Window Identifier (CID): | |||
A 16-bit unsigned integer identifying a credit window that has | ||||
been identified in a Credit Window Initialization Data Item, see | ||||
Section 6.1. | ||||
Credit Window Size: | ||||
A 64-bit unsigned integer, indicating the current number of | A 64-bit unsigned integer, indicating the current number of | |||
credits, in octets, available for the router to send to the modem. | credits, in octets, available for the router to send to the modem. | |||
This is referred to as the Modem Receive Window in | This is referred to as the Modem Receive Window in | |||
[I-D.ietf-manet-credit-window]. | [I-D.ietf-manet-credit-window]. | |||
Queue Index: | When receiving this data item, a modem MUST identify the credit | |||
window indicated by the CID. If the CID is not known to the modem, | ||||
One or more 8-bit fields used to indicate a queue index defined by | it SHOULD report or log this information and discard the Data Item. | |||
a Queue Parameters Data Item. The special value of 255 indicates | As with the Credit Window Grant Data Item, the CID MAY be unrelated | |||
that the information in the data item applies to all queue | to the Destination indicated in the message carrying the Data Item. | |||
indexes. | ||||
The receiving modem SHOULD check the received Credit Window value | Once the credit window is identified, the modem SHOULD check the | |||
against the outstanding credits available at the time the last Credit | received Credit Window Size field value against the outstanding | |||
Increment associated with the indicated MAC address and Queue Indexes | credit window's available credits at the time the most Credit Window | |||
were sent. If the values significantly differ, i.e., greater than | Initialization or Grant data item associated with the indicated CID | |||
can be accounted for based on observed data frames, then the modem | was sent. If the values significantly differ, i.e., greater than can | |||
SHOULD send a Destination Update message carrying a DA Credit Grant | be accounted for based on observed data frames, then the modem SHOULD | |||
data item to reset the associated Credit Window(s) to the data item | send a Credit Window Initialization Data Item to reset the associated | |||
indicated value. Multiple values and queue indexes SHOULD be | credit window size to the modem's current view of the available | |||
combined into a single Destination Update Control message when | credits. As defined above, Credit Window Initialization Data Items | |||
are sent in Session Update Messages. When multiple data items need | ||||
to be sent, they SHOULD be combined into a single message when | ||||
possible. Alternatively, and also in cases where there are small | possible. Alternatively, and also in cases where there are small | |||
differences, the modem MAY adjust the values sent in DA Credit Grant | differences, the modem MAY adjust the values sent in Credit Window | |||
data items to account for the reported Credit Window. | Grant data items to account for the reported Credit Window. | |||
6.4. DiffServ Aware (DA) Credit Request | 6.6. Credit Window Request | |||
The DiffServ Aware, or DA, Credit Request Data Item data item is used | The Credit Window Request Data Item data item is used by a router to | |||
by a router to request additional credits for a specific destination | request additional credits for particular credit windows. Credit | |||
and Queue Index associated Credit window. DA Credit Request data | Window Request Data Items are carried in Credit Control Messages, and | |||
items are carried in Credit Control messages, and only one DA Credit | only one Credit Window Request data item SHOULD be present in a | |||
Request data item SHOULD be present in a message. | message. | |||
Logical queues are identified using a Queue Index as defined above in | Credit windows identified using a CID as defined above in | |||
Section 6.1. Multiple Queue Indexes MAY be present to allow for the | Section 6.1. Multiple CIDs MAY be present to allow for the case | |||
case where the credit request applies to multiple queues. The | where the router identifies that credits are needed in multiple | |||
special Queue Index value of 255 is used to indicate that a credit | credit windows. The special CID value of 0xFFFFFFFF is used to | |||
request is being made across all queues. | indicate that a credit request is being made across all queues. | |||
The format of the DA Credit Request Data Item is: | The format of the Credit Window Request Data Item is: | |||
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 | | | Data Item Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Queue Index | ... : | | Credit Window Identifier (CID)| ... : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: ... | Queue Index | | : ... | Credit Window Identifier (CID)| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
[LB note: a list of Queue Indexes is now supported as is special | [LB note: a list of CIDs is now supported as is special value 255.] | |||
value 255.] | ||||
Data Item Type: TBA7 | Data Item Type: TBA9 | |||
Length: Variable | 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 | ||||
CID fields carried in the data item and MUST be at least 1. | ||||
Per [I-D.ietf-manet-dlep] Length is the number of octets in the | Credit Window Identifier (CID): | |||
data item, excluding the Type and Length fields. It will equal | ||||
the number of Queue Index fields carried in the data item and MUST | ||||
be at least 1. | ||||
Queue Index: | ||||
One or more 8-bit fields used to indicate a queue index defined by | One or more 16-bit fields used to indicate a credit window that | |||
a Queue Parameters Data Item. The special value of 255 indicates | has been identified in a Credit Window Initialization Data Item, | |||
that the request applies to all queue indexes. | see Section 6.1. The special value of 0xFFFFFFFF indicates that | |||
the request applies to all CIDs. | ||||
A modem receiving this data item MUST provide a Credit Increment for | A modem receiving this data item MUST provide a Credit Increment for | |||
the indicated MAC address and queue indexes via a DA Credit Grant | the indicated credit windows via Credit Window Grant Data Items | |||
carried in a new Credit Control Message. Multiple values and queue | carried in a new Credit Control Message. Multiple values and queue | |||
indexes SHOULD be combined into a single Credit Control message when | indexes SHOULD be combined into a single Credit Control Message when | |||
possible. | possible. Unknown CID values SHOULD be reported or logged and then | |||
ignored by the modem. | ||||
7. Compatibility | 7. Compatibility | |||
Sessions established with both peers identified as supporting the | Sessions established with both peers identified as supporting the | |||
DiffServ Aware Credit Windowing Extension Type, see Section 3, SHOULD | DiffServ Aware Credit Windowing Extension Type, see Section 3, MUST | |||
NOT use the [I-D.ietf-manet-credit-window] defined Credit data items. | NOT use the [I-D.ietf-manet-credit-window] defined Credit data items. | |||
If a node supporting the extension defined in this document, receives | If a node supporting the extension defined in this document, receives | |||
a [I-D.ietf-manet-credit-window] defined data item, the recipient | a [I-D.ietf-manet-credit-window] defined data item, the recipient | |||
MUST treat the received credit information as applying to Queue Index | MUST ignore the received information. | |||
zero (0). | ||||
8. Security Considerations | 8. Security Considerations | |||
The extension introduces a DiffServ awareness to the mechanisms | The extension introduces a DiffServ awareness to the mechanisms | |||
defined in [I-D.ietf-manet-credit-window]. The extension does not | defined in [I-D.ietf-manet-credit-window]. The extension does not | |||
inherently introduce any additional threats above those documented in | inherently introduce any additional threats above those documented in | |||
[I-D.ietf-manet-dlep]. The approach taken to Security in that | [RFC8175]. The approach taken to Security in that document and | |||
document and [I-D.ietf-manet-credit-window] apply equally when | [I-D.ietf-manet-credit-window] apply equally when running the | |||
running the extension defined in this document. | extension defined in this document. | |||
9. IANA Considerations | 9. IANA Considerations | |||
This document requests the assignment of 5 values by IANA. All | This document requests the assignment of 5 values by IANA. All | |||
assignments are to registries defined by [I-D.ietf-manet-dlep]. | assignments are to registries defined by [RFC8175]. | |||
9.1. Extension Type Value | 9.1. Extension Type Value | |||
This document requests 1 new assignment to the DLEP Extensions | This document requests 1 new assignment to the DLEP Extensions | |||
Registry named "Extension Tyoe Values" in the range with the | Registry named "Extension Type Values" in the range with the | |||
"Specification Required" policy. The requested value is as follows: | "Specification Required" policy. The requested value is as follows: | |||
+------+---------------------------------+ | +------+---------------------------------+ | |||
| Code | Description | | | Code | Description | | |||
+------+---------------------------------+ | +------+---------------------------------+ | |||
| TBA1 | DiffServ Aware Credit Windowing | | | TBA1 | DiffServ Aware Credit Windowing | | |||
+------+---------------------------------+ | +------+---------------------------------+ | |||
Table 1: Requested Extension Type Value | Table 1: Requested Extension Type Value | |||
skipping to change at page 14, line 31 ¶ | skipping to change at page 19, line 31 ¶ | |||
+-----------+-------------------------+ | +-----------+-------------------------+ | |||
| TBA2 | Credit Control | | | TBA2 | Credit Control | | |||
| | | | | | | | |||
| TBA3 | Credit Control Response | | | TBA3 | Credit Control Response | | |||
+-----------+-------------------------+ | +-----------+-------------------------+ | |||
Table 2: Requested Message Values | Table 2: Requested Message Values | |||
9.3. Data Item Values | 9.3. Data Item Values | |||
This document requests 4 new assignments to the DLEP Data Item | This document requests the following new assignments to the DLEP Data | |||
Registry named "Data Item Values" in the range with the | Item Registry named "Data Item Values" in the range with the | |||
"Specification Required" policy. The requested values are as | "Specification Required" policy. The requested values are as | |||
follows: | follows: | |||
+-----------+-------------------------+ | +-----------+--------------------------------------+ | |||
| Type Code | Description | | | Type Code | Description | | |||
+-----------+-------------------------+ | +-----------+--------------------------------------+ | |||
| TBA4 | Queue Parameters | | | TBA4 | Credit Window Initialization | | |||
| | | | | | | | |||
| TBA5 | DA Credit Grant | | | TBA5 | Credit Window Traffic Classification | | |||
| | | | | | | | |||
| TBA6 | DA Credit Window Status | | | TBA6 | Credit Window Association | | |||
| | | | | | | | |||
| TBA7 | DA Credit Request | | | TBA7 | Credit Window Grant | | |||
+-----------+-------------------------+ | | | | | |||
| TBA8 | Credit Window Status | | ||||
| | | | ||||
| TBA9 | Credit Window Request | | ||||
+-----------+--------------------------------------+ | ||||
Table 3: Requested Data Item Values | Table 3: Requested Data Item Values | |||
9.4. DLEP Sub Data Item Registry | ||||
Upon approval of this document, IANA is requested to create a new | ||||
DLEP registry, named "Sub Data Item Type Values". The registry shall | ||||
identify the type code value, the Data Item which may use the value, | ||||
and a description of the value. While the same value may be reused | ||||
in different data items, this is not recommended at this time. | ||||
The following table provides initial registry values and the | ||||
[RFC8126] defined policies that should apply to the registry: | ||||
+-------------+-----------------------------+-----------------------+ | ||||
| Type Code | Valid Data Items | Description | | ||||
+-------------+-----------------------------+-----------------------+ | ||||
| 0 | N/A | Reserved | | ||||
| | | | | ||||
| 1 | N/A | Reserved (for pause | | ||||
| | | sub-DI) | | ||||
| | | | | ||||
| 2 | (TBD4) Credit Window | DiffServ Traffic | | ||||
| | Traffic Classification | Classification | | ||||
| | | | | ||||
| 2-65407 | | Specification | | ||||
| | | Required | | ||||
| | | | | ||||
| 65408-65534 | | Private Use | | ||||
| | | | | ||||
| 65535 | | Reserved | | ||||
+-------------+-----------------------------+-----------------------+ | ||||
Table 4: Initial Registry Values | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[I-D.ietf-manet-dlep] | ||||
Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. | ||||
Berry, "Dynamic Link Exchange Protocol (DLEP)", draft- | ||||
ietf-manet-dlep-28 (work in progress), March 2017. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
[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, | ||||
<https://www.rfc-editor.org/info/rfc8175>. | ||||
10.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-manet-credit-window] | [I-D.ietf-manet-credit-window] | |||
Ratliff, S., "Credit Windowing extension for DLEP", draft- | Ratliff, S., "Credit Windowing extension for DLEP", draft- | |||
ietf-manet-credit-window-07 (work in progress), November | ietf-manet-credit-window-07 (work in progress), November | |||
2016. | 2016. | |||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
DOI 10.17487/RFC2474, December 1998, | DOI 10.17487/RFC2474, December 1998, | |||
<http://www.rfc-editor.org/info/rfc2474>. | <https://www.rfc-editor.org/info/rfc2474>. | |||
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |||
and W. Weiss, "An Architecture for Differentiated | and W. Weiss, "An Architecture for Differentiated | |||
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, | Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, | |||
<http://www.rfc-editor.org/info/rfc2475>. | <https://www.rfc-editor.org/info/rfc2475>. | |||
Appendix A. Open and Resolved Issues | [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, | ||||
<https://www.rfc-editor.org/info/rfc8126>. | ||||
Appendix A. Acknowledgments | ||||
The sub data item format was inspired by Rick Taylor's "Data Item | ||||
Containers". He also proposed the separation of credit windows from | ||||
traffic classification at IETF98. | ||||
Appendix B. Open and Resolved Issues | ||||
This section captures issues that are open or have been addressed | This section captures issues that are open or have been addressed | |||
since the document has become a WG draft. This section will be | since the document has become a WG draft. This section will be | |||
removed before submission for publication. | removed before submission for publication. | |||
A.1. Merge with [I-D.ietf-manet-credit-window] | B.1. Merge with [I-D.ietf-manet-credit-window] | |||
There has been discussion within the WG that this document should be | There has been discussion within the WG that this document should be | |||
merged with [I-D.ietf-manet-credit-window]. The timing of this is | merged with [I-D.ietf-manet-credit-window]. The timing of this is | |||
TBD. The authors would like to reach closure on some of the | TBD. The authors would like to reach closure on some of the | |||
remaining open issues before embarking on this merge, but are open to | remaining open issues before embarking on this merge, but are open to | |||
discussion with the WG and other authors. | discussion with the WG and other authors. | |||
A.2. Credit Windows Shared Across Destinations | B.2. Supporting Router Limits | |||
The DA Credit Extension supports credit windows per mac destination. | ||||
Some media technologies share queues across all, or even some set of, | ||||
destinations and supporting an associated set of credit windows isn't | ||||
currently supported. | ||||
Supporting credit windows per modem, i.e., for a single transmit | ||||
channel, is clearly required and needs to be supported. | ||||
Credit windows for sets of mac addresses should also be considered | ||||
and discussed within the working group, both from a requirements and | ||||
support perspective. | ||||
This issue was reported by Stan Ratliff <ratliffstan@gmail.com>. | ||||
A.3. Supporting Router Limits | ||||
Routers may have limits on the number of queues that they can support | Routers may have limits on the number of queues that they can support | |||
and, perhaps, if per destination queues can even be supported at all. | and, perhaps, if per destination queues can even be supported at all. | |||
There is no current way for a router to communicate these limits to a | There is no current way for a router to communicate these limits to a | |||
modem or for a router to indicate that the identified queue | modem or for a router to indicate that the identified queue | |||
information cannot be supported. Support for these cases clearly | information cannot be supported. Support for these cases clearly | |||
needs to be addressed. | needs to be addressed. | |||
This issue was reported by Stan Ratliff <ratliffstan@gmail.com>. | This issue was reported by Stan Ratliff <ratliffstan@gmail.com>. | |||
A.4. Absolute vs Increment | B.3. Absolute vs Increment | |||
Stan Ratliff <ratliffstan@gmail.com> suggested an approach to | Stan Ratliff <ratliffstan@gmail.com> suggested an approach to | |||
simplify credit synchronization and re-synchronization by always | simplify credit synchronization and re-synchronization by always | |||
passing the credit window size rather than credit window increments. | passing the credit window size rather than credit window increments. | |||
This is an interesting idea that needs to be explored and perhaps | This is an interesting idea that needs to be explored and perhaps | |||
experimented with. | experimented with. | |||
A.5. Alternate Format Encoding | B.4. Bidirectional Flow Control (closed) | |||
The format of the Queue Parameters Data Item is a bit cumbersome and | ||||
there has been some discussion of a possible better way of encoding | ||||
lists and optional information elements within Data Items. There has | ||||
been some discussion of developing a generic mechanisms for use by | ||||
DLEP and future DLEP Data Items. Such a definition is beyond the | ||||
scope of this document, but if such becomes available there is every | ||||
reason for this document to leverage this improved encoding. This | ||||
issue will remain open until such a time as there is a such a | ||||
definition within the WG or this document is otherwise ready for | ||||
publication. | ||||
This issue was independently raised by both David Wiggins (co-author) | ||||
and Rick Taylor <rick@tropicalstormsoftware.com>. | ||||
A.6. Bidirectional Flow Control (closed) | ||||
One of the key differences between this draft and | One of the key differences between this draft and | |||
[I-D.ietf-manet-credit-window] is that this document only supports | [I-D.ietf-manet-credit-window] is that this document only supports | |||
flow control in one direction, i.e., for traffic sent from a router | flow control in one direction, i.e., for traffic sent from a router | |||
to a modem, while the other credit-window draft supports it in both | to a modem, while the other credit-window draft supports it in both | |||
directions. | directions. | |||
This was a conscious choice, made out of the desire to keep the | This was a conscious choice, made out of the desire to keep the | |||
extension as simple as possible and to provide what is really | extension as simple as possible and to provide what is really | |||
expected to be used. Clearly the reason for being able to control | expected to be used. Clearly the reason for being able to control | |||
skipping to change at page 17, line 30 ¶ | skipping to change at page 23, line 4 ¶ | |||
easily understood. Also, while bidirectional flow control existed in | easily understood. Also, while bidirectional flow control existed in | |||
pre-dlep solutions, it wasn't really used. There is also no reason | pre-dlep solutions, it wasn't really used. There is also no reason | |||
why router to modem flow control can't be defined at a later time - | why router to modem flow control can't be defined at a later time - | |||
once there is an actual need. | once there is an actual need. | |||
Based on a brief discussion on the WG list, and the absence of any | Based on a brief discussion on the WG list, and the absence of any | |||
advocates for bidirectional flow control, there is no current plan to | advocates for bidirectional flow control, there is no current plan to | |||
add bidirectional flow control to this document. | add bidirectional flow control to this document. | |||
Authors' Addresses | Authors' Addresses | |||
Bow-Nan Cheng | Bow-Nan Cheng | |||
Lincoln Laboratory | Lincoln Laboratory | |||
Massachusetts Institute of Technology | Massachusetts Institute of Technology | |||
244 Wood Street | 244 Wood Street | |||
Lexington, MA 02420-9108 | Lexington, MA 02421-6426 | |||
Email: bcheng@ll.mit.edu | Email: bcheng@ll.mit.edu | |||
David Wiggins | David Wiggins | |||
Lincoln Laboratory | Lincoln Laboratory | |||
Massachusetts Institute of Technology | Massachusetts Institute of Technology | |||
244 Wood Street | 244 Wood Street | |||
Lexington, MA 02420-9108 | Lexington, MA 02421-6426 | |||
Email: David.Wiggins@ll.mit.edu | Email: David.Wiggins@ll.mit.edu | |||
Lou Berger | Lou Berger | |||
LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
Email: lberger@labn.net | Email: lberger@labn.net | |||
End of changes. 122 change blocks. | ||||
391 lines changed or deleted | 659 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |