draft-ietf-manet-dlep-da-credit-extension-03.txt | draft-ietf-manet-dlep-da-credit-extension-04.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: May 15, 2018 L. Berger | Expires: September 2, 2018 L. Berger | |||
LabN Consulting, L.L.C. | LabN Consulting, L.L.C. | |||
November 11, 2017 | March 1, 2018 | |||
DLEP DiffServ Aware Credit Windowing Extension | DLEP DiffServ Aware Credit Window Extension | |||
draft-ietf-manet-dlep-da-credit-extension-03 | draft-ietf-manet-dlep-da-credit-extension-04 | |||
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 and | a DiffServ aware credit-window scheme for destination-specific and | |||
shared flow control. | shared flow control. The extension is logically composed of two | |||
mechanisms. The first provides credit window control, the second | ||||
identifies how flows are identified and mapped to a credit window. | ||||
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 https://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 May 15, 2018. | This Internet-Draft will expire on September 2, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 | 2. Extension Overview . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Extension Usage and Identification . . . . . . . . . . . . . 5 | 3. Extension Usage and Identification . . . . . . . . . . . . . 5 | |||
4. Data Plane Considerations . . . . . . . . . . . . . . . . . . 5 | 4. Credit Window Control . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Extension Messages . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. Data Plane Considerations . . . . . . . . . . . . . . . . 5 | |||
5.1. Credit Control Message . . . . . . . . . . . . . . . . . 5 | 4.2. Extension Messages . . . . . . . . . . . . . . . . . . . 6 | |||
5.2. Credit Control Response Message . . . . . . . . . . . . . 6 | 4.2.1. Credit Control Message . . . . . . . . . . . . . . . 6 | |||
6. Extension Data Items . . . . . . . . . . . . . . . . . . . . 7 | 4.2.2. Credit Control Response Message . . . . . . . . . . . 7 | |||
6.1. Credit Window Initialization . . . . . . . . . . . . . . 7 | 4.3. Credit Window Control Data Items . . . . . . . . . . . . 7 | |||
6.2. Credit Window Traffic Classification . . . . . . . . . . 9 | 4.3.1. Credit Window Initialization . . . . . . . . . . . . 8 | |||
6.2.1. Traffic Classification Sub Data Item . . . . . . . . 11 | 4.3.2. Credit Window Associate . . . . . . . . . . . . . . . 10 | |||
6.2.2. DiffServ Traffic Classification Sub Data Item . . . . 12 | 4.3.3. Credit Window Grant . . . . . . . . . . . . . . . . . 11 | |||
6.3. Credit Window Associate . . . . . . . . . . . . . . . . . 13 | 4.3.4. Credit Window Status . . . . . . . . . . . . . . . . 12 | |||
6.4. Credit Window Credit Grant . . . . . . . . . . . . . . . 14 | 4.3.5. Credit Window Request . . . . . . . . . . . . . . . . 14 | |||
6.5. Credit Window Status . . . . . . . . . . . . . . . . . . 16 | 5. Traffic Classification . . . . . . . . . . . . . . . . . . . 15 | |||
6.6. Credit Window Request . . . . . . . . . . . . . . . . . . 17 | 5.1. Traffic Classification Data Item . . . . . . . . . . . . 15 | |||
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 | 5.1.1. Traffic Classification Sub Data Item . . . . . . . . 17 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | 5.2. DiffServ Credit Window Traffic Classification Sub Data | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | Item . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9.1. Extension Type Value . . . . . . . . . . . . . . . . . . 19 | 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
9.2. Message Values . . . . . . . . . . . . . . . . . . . . . 19 | 7. Management Considerations . . . . . . . . . . . . . . . . . . 19 | |||
9.3. Data Item Values . . . . . . . . . . . . . . . . . . . . 19 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
9.4. DLEP Sub Data Item Registry . . . . . . . . . . . . . . . 20 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 9.1. Extension Type Value . . . . . . . . . . . . . . . . . . 20 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 | 9.2. Message Values . . . . . . . . . . . . . . . . . . . . . 20 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 21 | 9.3. Data Item Values . . . . . . . . . . . . . . . . . . . . 21 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 | 9.4. DLEP Sub Data Item Registry . . . . . . . . . . . . . . . 21 | |||
Appendix B. Open and Resolved Issues . . . . . . . . . . . . . . 22 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
B.1. Merge with [I-D.ietf-manet-credit-window] . . . . . . . . 22 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 | |||
B.2. Supporting Router Limits . . . . . . . . . . . . . . . . 22 | 10.2. Informative References . . . . . . . . . . . . . . . . . 22 | |||
B.3. Absolute vs Increment . . . . . . . . . . . . . . . . . . 23 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 | |||
B.4. Bidirectional Flow | Appendix B. Notional Support for Ethernet Priority Code Points . 23 | |||
Control (closed) . . . . . . . . . . . . . . . . . . . . 23 | B.1. Notional Ethernet Credit Window Traffic Classification | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | Sub Data Item . . . . . . . . . . . . . . . . . . . . . . 24 | |||
B.2. Other Considerations . . . . . . . . . . . . . . . . . . 25 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | ||||
1. Introduction | 1. Introduction | |||
The Dynamic Link Event Protocol (DLEP) is defined in [RFC8175]. It | The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. | |||
provides the exchange of link related control information between | It provides the exchange of link related control information between | |||
DLEP peers. DLEP peers are comprised of a modem and a router. DLEP | DLEP peers. DLEP peers are comprised of a modem and a router. DLEP | |||
defines a base set of mechanisms as well as support for possible | defines a base set of mechanisms as well as support for possible | |||
extensions. This document defines one such extension. | extensions. This document defines one such 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 techniques theoretically | |||
with DLEP. For example, a credit-windowing scheme for destination- | possible with DLEP. For example, a credit-window scheme for | |||
specific flow control which provides aggregate flow control for both | destination-specific flow control which provides aggregate flow | |||
modem and routers has been proposed in | control for both 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 an alternate | This document defines a DLEP extension which provides a flow control | |||
flow control mechanism for traffic sent from a router to a modem. | mechanism for traffic sent from a router to a modem. Flow control is | |||
Flow control is provide using one or more logical "Credit Windows", | provided using one or more logical "Credit Windows", each of which | |||
each of which will typically be supported by an associated virtual or | will typically be supported by an associated virtual or physical | |||
physical queue. Traffic sent by a router will use traffic | queue. Traffic sent by a router will use traffic flow classification | |||
classification information provided by the modem to identify which | information provided by the modem to identify which traffic is | |||
traffic is associated with each credit window. (For general | associated with each credit window. (For general background on | |||
background on traffic classification see [RFC2475] Section 2.3.) | traffic classification see [RFC2475] Section 2.3.) Credit windows | |||
This document supports traffic classification based on DLEP | may be shared or dedicated on a per flow basis. The extension is | |||
structured to allow for reuse of the defined credit window based flow | ||||
control with different traffic classification techniques. | ||||
This document defines traffic classification based on DLEP | ||||
destination and DiffServ [RFC2475] DSCPs (differentiated services | destination and DiffServ [RFC2475] DSCPs (differentiated services | |||
codepoints). Credit windows may be shared or dedicated on a per | codepoints). The defined mechanism allows for credit windows to be | |||
{destination, DSCP} tuple basis. Said another way, the defined | shared across traffic sent to multiple DLEP destinations and DSCPs, | |||
mechanism allows for credit windows to be shared across traffic sent | or used exclusively for traffic sent to a particular destination and/ | |||
to multiple DLEP destinations and DSCPs, or used exclusively for | or DSCP. The extension also supports the "wildcard" matching of any | |||
traffic sent to a particular destination and/or DSCP. The extension | DSCP. Traffic classification information is provided such that it | |||
also supports the "wildcard" matching of any DSCP. | can be readily extended to support non-DSCP related traffic | |||
classification techniques, or be used by non-credit window related | ||||
extensions, such as [I-D.ietf-manet-dlep-pause-extension]. | ||||
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 Window" or, more simply, the "DA Credit" extension. | |||
The extension is structured to allow for reuse of the defined credit | Future extensions are expected to define traffic classification | |||
window based flow control with traffic classification techniques | techniques other than DiffServ, e.g., IEEE 802.1 Q priority code | |||
other than DiffServ, e.g., IEEE 802.1 Q priority code points or even | points or even 5-tuple IP flows. | |||
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 support for the extension. Two new | |||
are defined in Section 5, and six new DLEP Data Items in Section 6. | messages are defined in Section 4.2 and five new DLEP data items in | |||
Section 4.3 are defined to support credit window control. A single | ||||
data item is defined in Section 5.1 to support traffic classification | ||||
in general, as well as identification of flows based on DSCPs. | ||||
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 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | 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 per DLEP destination based flow | |||
Both types of DLEP endpoints, i.e., a router and a modem, negotiate | control. Both types of DLEP endpoints, i.e., a router and a modem, | |||
the use of extension during session initialization, see Section 5.2 | negotiate the use of extension during session initialization, see | |||
Section 5.2 [RFC8175]. When using this extension, data traffic is | ||||
[RFC8175]. When using this extension, data traffic is allowed to be | allowed to be sent by the router to the modem only when there are | |||
sent by the router to the modem only when there are credits | credits available. | |||
available. | ||||
Credits are managed on a per logical "Credit Windows" basis. Each | Credits are managed on a per logical "Credit Windows" 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. Modems pass to the router information on its credit windows | modem. Modems pass to the router information on their credit windows | |||
and identify each via a "Credit Window Identifier", or "CID". In | and identify each via a "Credit Window Identifier", or "CID". In | |||
addition to the CID, credit window information includes an initial | addition to the CID, credit window information includes an initial | |||
credit window size, as well as the maximum size of the logical queue | credit window size, as well as the maximum size of the logical queue | |||
associated with each CID. The maximum size is included for | associated with each CID. The maximum size is included for | |||
informative and, potential, future uses. | informative and potential future uses. | |||
As mentioned above, traffic classification supported by this document | ||||
is performed on a per {destination, DSCP} tuple basis. This means | ||||
that, routers need the combination of the DLEP identified destination | ||||
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. | ||||
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. Additional "Credit Grants", i.e., | when rate information changes. Additional "Credit Grants", i.e., | |||
increments to Credit Window size, are provided using a Destination Up | increments to Credit Window size, are provided using a Destination Up | |||
or the new "Credit Control" Message. A router provides its view of | or the new "Credit Control" Message. A router provides its view of | |||
the Credit Window, which is known as "Status", in Destination Up | the Credit Window, which is known as "Status", in Destination Up | |||
Response and the new "Credit Control Response" Messages. Routers can | Response and the new "Credit Control Response" Messages. Routers can | |||
also request credits using the new "Credit Control" Message. | also request credits using the new "Credit Control" Message. | |||
When modems provide credits to a router, they will need to take into | When modems provide credits to a router, they will need to take into | |||
account any overhead of their attached transmission technology and | account any overhead of their attached transmission technology and | |||
map it into the credit semantics defined in this document. In | map it into the credit semantics defined in this document. In | |||
particular, the credit window is defined below to include per frame | particular, the credit window is defined below to include per frame | |||
(packet) MAC headers and this may not match the actual overhead of | (packet) MAC headers and this may not match the actual overhead of | |||
the modem attached transmission technology. In that case a direct | the modem attached transmission technology. In that case a direct | |||
mapping or an approximation will need to be made by the modem to | mapping or an approximation will need to be made by the modem to | |||
provide appropriate credit values. | provide appropriate credit values. | |||
As mentioned above, traffic classification supported by this document | ||||
is performed on a per {destination, DSCP} tuple basis. (Per | ||||
destination traffic classification is also supported.) This means | ||||
that, routers need the combination of the DLEP identified destination | ||||
and one or more DSCPs associated with a CID in order to match traffic | ||||
they send 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 a modem | ||||
to share or dedicate resources as needed to match the specifics of | ||||
its implementation and its attached transmission technology. | ||||
3. Extension Usage and Identification | 3. Extension Usage and Identification | |||
The use of the extension defined in this document SHOULD be | The extension defined in this document is composed of the mechanisms | |||
configurable. To indicate that the DiffServ Aware Credit Windowing | and processing defined in Section 4 and Section 5. To indicate that | |||
Extension is to be used, an implementation MUST include the DiffServ | the DiffServ Aware Credit Window Extension is to be used, an | |||
Aware Credit Windowing Type Value in the Extensions Supported Data | implementation MUST include the DiffServ Aware Credit Window Type | |||
Item. The Extensions Supported Data Item is sent and processed | Value in the Extensions Supported Data Item. The Extensions | |||
according to [RFC8175]. | Supported Data Item is sent and processed according to [RFC8175]. | |||
The DiffServ Aware Credit Windowing Extension Type Value is TBA1, see | The DiffServ Aware Credit Window Extension Type Value is TBA1, see | |||
Section 9. | Section 9. | |||
4. Data Plane Considerations | 4. Credit Window Control | |||
This section defines additions to DLEP for the control of credit | ||||
based flow control. As mentioned above, the definition is made in | ||||
the context of credit windows which can be thought of as representing | ||||
different logical queues. Two new messages and five data items are | ||||
defined to support credit window control. Credit window control also | ||||
impacts the data plane. | ||||
4.1. 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 traffic to a modem for forwarding when there are no credits | data traffic to a modem for forwarding when there are no credits | |||
available in the associated Credit Window. This document defines | available in the associated Credit Window. This document defines | |||
credit windows in octets. A credit window value MUST be larger than | credit windows in octets. A credit window value MUST be larger than | |||
the number of octets contained in a packet, including any MAC headers | 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 | 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 | send the packet to a modem for forwarding. 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 sent | A router MUST identify the credit window associated with traffic sent | |||
to a modem based on the traffic classification information provided | to a modem based on the traffic classification information provided | |||
in the data items defined in this document. The definitions support | in the data items defined in this document. Note that routers will | |||
identification based on DLEP destination and, at the modem's | typically view a DLEP destination as the next hop MAC address. | |||
discretion, DSCPs. Note that routers will typically view a DLEP | ||||
destination as the next hop. | ||||
5. Extension Messages | 4.2. 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 | 4.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 (modem or router) MUST NOT send a second (or any | is, a sender (modem or router) MUST NOT send a second (or any | |||
subsequent) Credit Control Message until a Credit Control Response | subsequent) Credit Control Message until a Credit Control Response | |||
Message is received from its peer (router or modem). | Message is received from its peer (router or modem). | |||
Credit Control Messages are sent by modems to provide credit window | Credit Control Messages are sent by modems to provide credit window | |||
increases. Modems send credit increases when there is transmission | increases. Modems send credit increases when there is transmission | |||
or local queue availability that exceeds the credit window value | or local queue availability that exceeds the credit window value | |||
skipping to change at page 6, line 19 ¶ | skipping to change at page 6, line 42 ¶ | |||
Credit Control Messages MAY be sent by routers to request credits and | Credit Control Messages MAY be sent by routers to request credits and | |||
provide window status. Routers will need to balance the load | provide window status. Routers will need to balance the load | |||
generated by sending and processing frequent credit window requests | generated by sending and processing frequent credit window requests | |||
against a having data traffic available to send, but no credits | against a having data traffic available to send, but no credits | |||
available. | available. | |||
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. | |||
A message sent by a modem, MUST contain one or more Credit Window | 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 | Grant Data Items as defined below in Section 4.3.3. A router | |||
this message MUST respond with a Credit Control Response Message. | receiving this message MUST respond with a Credit Control Response | |||
Message. | ||||
A message sent by a router, MUST contain one or more Credit Window | A message sent by a router, MUST contain one or more Credit Window | |||
Request Data Items defined below in Section 6.6 and SHOULD contain a | Request Data Items defined below in Section 4.3.5 and SHOULD contain | |||
Credit Window Status Data Item, defined in Section 6.5, corresponding | a Credit Window Status Data Item, defined in Section 4.3.4, | |||
to each credit window request. A modem receiving this message MUST | corresponding to each credit window request. A modem receiving this | |||
respond with a Credit Control Response Message based on the received | message MUST respond with a Credit Control Response Message based on | |||
message and data item and the processing defined below, which will | the received message and data item and the processing defined below, | |||
typically result in credit window increments being provided. | which will typically result in credit window increments being | |||
provided. | ||||
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 | 4.2.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. A message sent by a router, | current Credit Window for a destination. A message sent by a router, | |||
MUST contain one or more Credit Window Status Data Items as defined | MUST contain one or more Credit Window Status Data Items as defined | |||
below in Section 6.5. Specific receive processing associated with | below in Section 4.3.4. Specific receive processing associated with | |||
the Credit Window Window Status Data Item is provided below. | the Credit Window Status Data Item is provided below. | |||
Credit Control Response Messages sent by modems MUST contain one or | Credit Control Response Messages sent by modems MUST contain one or | |||
more Credit Window Credit Grant Data Items. A data item for every | more Credit Window Grant Data Items. A data item for every Credit | |||
Credit Window Request data item contained in the for Credit Control | Window Request data item contained in the corresponding Credit | |||
Response Message sent by the router MUST be included. Each Grant | Control Response Message received by the modem MUST be included. | |||
Data Item MAY provide zero or more additional credits based on a the | Each Credit Grant Data Item MAY provide zero or more additional | |||
modem;s transmission or local queue availability. Specific receive | credits based on the modem's transmission or local queue | |||
processing associated with each Grant Data Item is provided below. | availability. Specific receive processing associated with each Grant | |||
Data Item is provided below. | ||||
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. | |||
6. Extension Data Items | 4.3. Credit Window Control Data Items | |||
Six data items are defined by this extension. The Credit Window | Five new data items are defined to support credit window control. | |||
Initialization Data Item is used by a modem to identify a credit | The Credit Window Initialization Data Item is used by a modem to | |||
window and set its size. The Credit Window Traffic Classification | identify a credit window and set its size. The Credit Window | |||
Data Item is used by a modem to identify a set which identifies which | Association Data Item is used by a modem to identify which traffic | |||
DSCPs are mapped to a credit window. The Credit Window Association | classification identifiers (flows) should be used when sending | |||
Data Item is used by a modem to identify which traffic classification | traffic to a particular DLEP identified destination. The Credit | |||
set should be used when sending traffic to a particular DLEP | Window Grant is used by a modem to provide additional credits to a | |||
identified destination. The Credit Window Grant is used by a modem | router. The Credit Request is used by a router to request additional | |||
to provide additional credits to a router. The Credit Request is | credits. The Credit Window Status is used to advertise the sender's | |||
used by a router to request additional credits. The Credit Window | view of number of available credits for state synchronization | |||
Status is used to advertise the sender's view of number of available | purposes. | |||
credits for state synchronization purposes. | ||||
Any errors or inconsistencies encountered in parsing data items are | Any errors or inconsistencies encountered in parsing data items are | |||
handled in the same fashion as any other data dtem parsing error | handled in the same fashion as any other data dtem parsing error | |||
encountered in DLEP, see [RFC8175]. In particular, the node parsing | encountered in DLEP, see [RFC8175]. In particular, the node parsing | |||
the data item MUST terminate the session with a Status Data Item | the data item MUST terminate the session with a Status Data Item | |||
indicating Invalid Data. | indicating Invalid Data. | |||
The defined data items and operations have similar objectives as | The defined data items and operations have similar objectives as | |||
those found in [I-D.ietf-manet-credit-window]. One notable | those found in [I-D.ietf-manet-credit-window]. One notable | |||
difference from this extension is that in this document credits are | difference from this extension is that in this document credits are | |||
never provided by the router to the modem. | never provided by the router to the modem. | |||
6.1. Credit Window Initialization | 4.3.1. Credit Window Initialization | |||
The Credit Window Initialization Data Item is used by a modem to | 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 | identify a credit window and set its size. This Data Item SHOULD be | |||
included in any Session Initialization Response Message that also | included in any Session Initialization Response Message that also | |||
contains the DiffServ Aware Credit Windowing Extension Type Value in | contains the DiffServ Aware Credit Window Extension Type Value in the | |||
the Extensions Supported Data Item. Updates to previously identified | Extensions Supported Data Item. Updates to previously identified | |||
credit windows or new credit windows MAY be sent by a modem by | credit windows or new credit windows MAY be sent by a modem by | |||
including the data item in Session Update Messages. More than one | including the data item in Session Update Messages. More than one | |||
data item MAY be included in a message to provide information on | data item MAY be included in a message to provide information on | |||
multiple credit windows. | multiple credit windows. | |||
The Credit Window Initialization Data Item identifies a credit window | The Credit Window Initialization Data Item identifies a credit window | |||
using a Credit Window Identifier, or CID. It also provides the size | using a Credit Window Identifier, or CID. It also provides the size | |||
of the identified credit window. Finally, a queue size (in bytes) is | of the identified credit window. Finally, a queue size (in bytes) is | |||
provided for informational purposes. Note that to be used, a CID | provided for informational purposes. Note that to be used, a CID | |||
must be listed in a Credit Window Traffic Classification Data Item. | must be associated with in a Traffic Classification Identifier via a | |||
Credit Window Association Data Item. | ||||
The format of the Credit Window Initialization 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 (16) | | | Data Item Type | Length (16) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Credit Window Identifier (CID)| Reserved | | | Credit Window Identifier (CID)| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 8, line 23 ¶ | skipping to change at page 8, line 46 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: Credit Value | | : Credit Value | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Scale | Credit Window Size | | | Scale | Credit Window Size | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBA4 | Data Item Type: TBA4 | |||
Length: 16 | Length: 16 | |||
Per [RFC8175] Length is the number of octets in the data item, | Per [RFC8175] Length is the number of octets in the data item. It | |||
excluding the Type and Length fields. | MUST be equal to sixteen (16). | |||
Credit Window Identifier (CID): | Credit Window Identifier (CID): | |||
A 16-bit unsigned integer identifying a credit window. The value | A 16-bit unsigned integer identifying a credit window. The value | |||
of 0xFFFFFFFF is reserved and MUST not be used in this data item. | of 0xFFFF is reserved and MUST not be used in this data item. | |||
There is no other restriction on values used by a modem, and there | There is no other restriction on values used by a modem, and there | |||
is no requirement for sequential or ordered values. | is no requirement for sequential or ordered values. | |||
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). | |||
Credit Value: | Credit Value: | |||
skipping to change at page 9, line 28 ¶ | skipping to change at page 10, line 5 ¶ | |||
A router that receives a Credit Window Initialization Data Item MUST | A router that receives a Credit Window Initialization Data Item MUST | |||
locate the credit window that is associated with the CID indicated in | locate the credit window that is associated with the CID indicated in | |||
each received data item. If no associated credit window is found, | each received data item. If no associated credit window is found, | |||
the router MUST initialize a new credit window using the values | the router MUST initialize a new credit window using the values | |||
carried in the data item. When an associated credit window is found, | 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 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 | 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 | credit window size being reduced, for example, due to a transmission | |||
rate change on the modem. | rate change on the modem. | |||
6.2. Credit Window Traffic Classification | 4.3.2. Credit Window Associate | |||
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: | ||||
MUST be set to zero by the sender (a modem) and ignored by the | ||||
receiver (a router). | ||||
Traffic Classification Sub Data Item: | ||||
Zero or more Traffic Classification Sub Data Items of the format | ||||
defined below MAY be included. The number MUST match the value | ||||
carried in the Num SDIs field. | ||||
A router receiving the Traffic Classification Data Item MUST locate | ||||
the traffic classification information that is associated with the | ||||
TID indicated in each received data item. If no associated traffic | ||||
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. | ||||
6.2.1. Traffic Classification Sub Data Item | ||||
All Traffic Classification Sub Data Items share a common format that | ||||
is patterned after the standard DLEP data item format, see [RFC8175] | ||||
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. | ||||
The format of the Traffic Classification Sub Data Item is: | ||||
0 1 2 3 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sub Data Item Type | Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Value... : | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Sub Data Item Type: | ||||
A 16-bit unsigned integer that indicates the type and | ||||
corresponding format of the data item's Value field. Sub Data | ||||
Item Types are managed according to the IANA registry described in | ||||
Section 9.4. | ||||
Length: Variable | ||||
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. | ||||
6.2.2. DiffServ Traffic Classification Sub Data Item | ||||
The DiffServ Traffic Classification Sub Data Item is used to identify | ||||
the DSCPs associated with a specific credit window. Credit windows | ||||
are identified 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 sub data item. DSCPs are | ||||
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. | ||||
The format of the DiffServ Traffic Classification Sub Data Item is: | ||||
0 1 2 3 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| 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 | The Credit Window Associate Data Item is used by a modem to associate | |||
traffic classification information with a destination. The traffic | traffic classification information with a destination. The traffic | |||
classification information is identified using a TID value that has | classification information is identified using a TID value that has | |||
been previously been sent by the modem or is listed in a Credit | previously been sent by the modem or is listed in a Traffic | |||
Window Traffic Classification Data Item carried in the same message | Classification Data Item carried in the same message as the data | |||
as the data item. | item. | |||
A single Credit Window Associate Data Item MUST be included in all | A single Credit Window Associate Data Item MUST be included in all | |||
Destination Up and Destination Update Messages sent by a modem when | Destination Up and Destination Update Messages sent by a modem when | |||
the use of the extension defined in this document is agreed upon, see | the use of the extension defined in this document is agreed upon, see | |||
Section 3. | Section 3. Note that a TID will not be used unless it is listed in a | |||
Credit Window Associate Data Item. | ||||
The format of the Credit Window Associate Data Item is: | The format of the Credit Window Associate 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 (2) | | | Data Item Type | Length (2) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Traffic Class. Identifier (TID)| | |Traffic Class. Identifier (TID)| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBA6 | Data Item Type: TBA5 | |||
Length: 2 | Length: 2 | |||
Per [RFC8175] Length is the number of octets in the data item, | Per [RFC8175] Length is the number of octets in the data item. It | |||
excluding the Type and Length fields. | MUST be equal to two (2). | |||
Traffic Classification Identifier (TID): | Traffic Classification Identifier (TID): | |||
A 16-bit unsigned integer identifying a traffic classification set | A 16-bit unsigned integer identifying a traffic classification set | |||
that has been identified in a Credit Window Traffic Classification | that has been identified in a Credit Window Traffic Classification | |||
Data Item, see Section 6.2. Unknown TID values SHOULD be reported | Data Item, see Section 5.1. Unknown TID values SHOULD be reported | |||
and result in associated traffic being dropped. | and result in associated traffic being dropped. | |||
A router that receives the Credit Window Associate Data Item MUST | A router that receives the Credit Window Associate Data Item MUST | |||
locate the traffic classification information indicated by the | locate the traffic classification information indicated by the | |||
received TID. If no corresponding information can be located, the | received TID. If no corresponding information can be located, the | |||
data item MUST be treated as an error as described above. Once the | data item MUST be treated as an error as described above. Once the | |||
traffic classification information is located, it MUST be associated | traffic classification information is located, it MUST be associated | |||
with the destination and the router MUST ensure that any data plane | 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 | state, see Section 4.1, that is associated with the TID is updated as | |||
needed. | needed. | |||
6.4. Credit Window Credit Grant | 4.3.3. Credit Window Grant | |||
The Credit Window Credit Grant data item is used by a modem to | The Credit Window Grant data item is used by a modem to provide | |||
provide credits to a router. One or more Credit Window Grant Data | credits to a router. One or more Credit Window Grant Data Items MAY | |||
Items MAY be carried in the DLEP Destination Up, Destination Announce | be carried in the DLEP Destination Up, Destination Announce Response, | |||
Response, Destination Update, Credit Control Messages, and Credit | Destination Update, Credit Control Messages, and Credit Control | |||
Control Response Messages. Multiple Credit Window Grant Data Items | Response Messages. Multiple Credit Window Grant Data Items in a | |||
in a single message are used to indicate different credit values for | single message are used to indicate different credit values for | |||
different credit windows. In all message types, this data item | different credit windows. In all message types, this data item | |||
provides an additional number of octets to be added to the indicated | provides an additional number of octets to be added to the indicated | |||
credit window. Credit window are identified via using using CID | credit window. Credit window are identified via using CID values | |||
values that have been previously been sent by the modem or are listed | that have been previously been sent by the modem or are listed in a | |||
in a Credit Window Initialization Data Item carried in the same | Credit Window Initialization Data Item carried in the same messages | |||
messages as the data item. | as the data item. | |||
The format of the Credit Window Grant Data Item is: | 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 (12) | | | Data Item Type | Length (12) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Credit Window Identifier (CID)| Reserved | | | Credit Window Identifier (CID)| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Additional Credits : | | Additional Credits : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: Additional Credits | | : Additional Credits | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBA7 | Data Item Type: TBA6 | |||
Length: 12 | Length: 12 | |||
Per [RFC8175], Length is the number of octets in the data item, | Per [RFC8175], Length is the number of octets in the data item. | |||
excluding the Type and Length fields. It will equal 8 plus the | It MUST be equal to twelve (12). | |||
number of CID fields carried in the data item and MUST be at least | ||||
9. | ||||
Credit Window Identifier (CID): | Credit Window Identifier (CID): | |||
A 16-bit unsigned integer identifying a credit window that has | A 16-bit unsigned integer identifying a credit window that has | |||
been identified in a Credit Window Initialization Data Item, see | been identified in a Credit Window Initialization Data Item, see | |||
Section 6.1. Unknown CID values SHOULD be reported and ignored. | Section 4.3.1. Unknown CID values SHOULD be reported and ignored. | |||
Additional Credit: | Additional Credit: | |||
A 64-bit unsigned integer representing the credits, in octets, to | A 64-bit unsigned integer representing the credits, in octets, to | |||
be added to the Credit Window. This value includes MAC headers as | be added to the Credit Window. This value includes MAC headers as | |||
seen on the link between the modem and router. A value of zero | seen on the link between the modem and router. A value of zero | |||
indicates that no additional credits are being provided. | indicates that no additional credits are being provided. | |||
When receiving this data item, a router MUST identify the credit | When receiving this data item, a router MUST identify the credit | |||
window indicated by the CID. If the CID is not known to the router, | window indicated by the CID. If the CID is not known to the router, | |||
skipping to change at page 16, line 16 ¶ | skipping to change at page 12, line 30 ¶ | |||
No response is sent by the router to a modem after processing a | No response is sent by the router to a modem after processing a | |||
Credit Window Grant Data Item received in a Credit Control Response | Credit Window Grant Data Item received in a Credit Control Response | |||
Message. In other cases, the receiving router MUST send a Credit | Message. In other cases, the receiving router MUST send a Credit | |||
Window Status data item or items reflecting the resulting Credit | Window Status data item or items reflecting the resulting Credit | |||
Window value of the updated credit window. When the Credit Grant | Window value of the updated credit window. When the Credit Grant | |||
data item is received in a Destination Up Message, the Credit Window | data item is received in a Destination Up Message, the Credit Window | |||
Status data item(s) MUST be sent in the corresponding Destination Up | Status data item(s) MUST be sent in the corresponding Destination Up | |||
Response Message. Otherwise, a Credit Control Message MUST be sent. | Response Message. Otherwise, a Credit Control Message MUST be sent. | |||
6.5. Credit Window Status | 4.3.4. Credit Window Status | |||
The Credit Window Status data item is used by a router to report the | The Credit Window Status data item is used by a router to report the | |||
current credit window size to its peer modem. One or more Credit | current credit window size to its peer modem. One or more Credit | |||
Window Status data items MAY be carried in a Destination Up Response | Window Status data items MAY be carried in a Destination Up Response | |||
Message or a Credit Control Response Message. As discussed above, | Message or a Credit Control Response Message. As discussed above, | |||
the Destination Up Response Message is used when the data item is | the Destination Up Response Message is used when the data item is | |||
sent in response to a Destination Up Message, and the Credit Control | sent in response to a Destination Up Message, and the Credit Control | |||
Response Message is sent in response to a Credit Control Message. | Response Message is sent in response to a Credit Control Message. | |||
Multiple Credit Window Status data items in a single message are used | Multiple Credit Window Status data items in a single message are used | |||
to indicated different sizes of different credit windows. Similar to | to indicate different sizes of different credit windows. Similar to | |||
the Credit Window Grant, credit windows are identified using CID | the Credit Window Grant, credit windows are identified using CID | |||
values that have been previously been sent by the modem. | values that have been previously been sent by the modem. | |||
The format of the Credit Window Status Data Item is: | The format of the Credit 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 (12) | | | Data Item Type | Length (12) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Credit Window Identifier (CID)| Reserved | | | Credit Window Identifier (CID)| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Credit Window Size : | | Credit Window Size : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: Credit Window Size | | : Credit Window Size | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Data Item Type: TBA8 | Data Item Type: TBA7 | |||
Length: 12 | Length: 12 | |||
Per [RFC8175] Length is the number of octets in the data item, | Per [RFC8175] Length is the number of octets in the data item. It | |||
excluding the Type and Length fields. It will equal 8 plus the | MUST be equal to twelve (12). | |||
number of CID fields carried in the data item and MUST be at least | ||||
9. | ||||
Credit Window Identifier (CID): | Credit Window Identifier (CID): | |||
A 16-bit unsigned integer identifying a credit window that has | A 16-bit unsigned integer identifying a credit window that has | |||
been identified in a Credit Window Initialization Data Item, see | been identified in a Credit Window Initialization Data Item, see | |||
Section 6.1. | Section 4.3.1. | |||
Credit Window Size: | 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]. | |||
When receiving this data item, a modem MUST identify the credit | 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, | window indicated by the CID. If the CID is not known to the modem, | |||
skipping to change at page 17, line 39 ¶ | skipping to change at page 14, line 9 ¶ | |||
be accounted for based on observed data frames, then the modem SHOULD | be accounted for based on observed data frames, then the modem SHOULD | |||
send a Credit Window Initialization Data Item to reset the associated | send a Credit Window Initialization Data Item to reset the associated | |||
credit window size to the modem's current view of the available | credit window size to the modem's current view of the available | |||
credits. As defined above, Credit Window Initialization Data Items | credits. As defined above, Credit Window Initialization Data Items | |||
are sent in Session Update Messages. When multiple data items need | are sent in Session Update Messages. When multiple data items need | |||
to be sent, they SHOULD be combined into a single message when | 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 Credit Window | differences, the modem MAY adjust the values sent in Credit Window | |||
Grant data items to account for the reported Credit Window. | Grant data items to account for the reported Credit Window. | |||
6.6. Credit Window Request | 4.3.5. Credit Window Request | |||
The Credit Window Request Data Item is used by a router to request | The Credit Window Request Data Item is used by a router to request | |||
additional credits for particular credit windows. Credit Window | additional credits for particular credit windows. Credit Window | |||
Request Data Items are carried in Credit Control Messages, and one or | Request Data Items are carried in Credit Control Messages, and one or | |||
more Credit Window Request Data Items MAY be present in a message. | more Credit Window Request Data Items MAY be present in a message. | |||
Credit windows identified using a CID as defined above in | Credit windows identified using a CID as defined above in | |||
Section 6.1. Multiple CIDs MAY be present to allow for the case | Section 4.3.1. Multiple CIDs MAY be present to allow for the case | |||
where the router identifies that credits are needed in multiple | where the router identifies that credits are needed in multiple | |||
credit windows. The special CID value of 0xFFFFFFFF is used to | credit windows. The special CID value of 0xFFFF is used to indicate | |||
indicate that a credit request is being made across all queues. | that a credit request is being made across all queues. | |||
The format of the Credit Window 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Credit Window Identifier (CID)| ... : | | Credit Window Identifier (CID)| ... : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: ... | Credit Window Identifier (CID)| | : ... | Credit Window Identifier (CID)| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
[LB note: a list of CIDs is now supported as is special value 255.] | Data Item Type: TBA8 | |||
Data Item Type: TBA9 | ||||
Length: Variable | Length: Variable | |||
Per [RFC8175] Length is the number of octets in the data item, | Per [RFC8175] Length is the number of octets in the data item, | |||
excluding the Type and Length fields. It will equal the number of | 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. | CID fields carried in the data item times 2 and MUST be at least | |||
2. | ||||
Credit Window Identifier (CID): | Credit Window Identifier (CID): | |||
One or more 16-bit fields used to indicate a credit window that | One or more 16-bit fields used to indicate a credit window that | |||
has been identified in a Credit Window Initialization Data Item, | has been identified in a Credit Window Initialization Data Item, | |||
see Section 6.1. The special value of 0xFFFFFFFF indicates that | see Section 4.3.1. The special value of 0xFFFFFFFF indicates that | |||
the request applies to all CIDs. | 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 credit windows via Credit Window Grant Data Items | 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. Unknown CID values SHOULD be reported or logged and then | possible. Unknown CID values SHOULD be reported or logged and then | |||
ignored by the modem. | ignored by the modem. | |||
7. Compatibility | 5. Traffic Classification | |||
Traffic classification is supported by the Traffic Classification | ||||
Data Item defined below. The base data item and sub data item | ||||
structure is intended to be independent of any specific usage of the | ||||
flow identification provided within the data item. It is designed to | ||||
be extensible for future traffic classification types. While the | ||||
structure of the data items is extensible, actual flow information is | ||||
expected to be used in an extension dependent manner. | ||||
In the context of the DiffServ Aware Credit Window Extension, the | ||||
Traffic Classification Data Item is used by a modem to identify | ||||
groups of DSCPs which are to be mapped to a credit window. A DLEP | ||||
destination address is also needed to complete the traffic | ||||
classification information. This address 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 above. | ||||
5.1. Traffic Classification Data Item | ||||
This sections defines the Traffic Classification Data Item. This | ||||
data item is used by a modem to provide a router with traffic | ||||
classification information. When an extension requires use of this | ||||
data item the Traffic Classification Data Item SHOULD be included by | ||||
a modem in any Session Initialization Response Message that also | ||||
contains the corresponding 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. | ||||
The format of the 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: TBA9 | ||||
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: | ||||
MUST be set to zero by the sender (a modem) and ignored by the | ||||
receiver (a router). | ||||
Traffic Classification Sub Data Item: | ||||
Zero or more Traffic Classification Sub Data Items of the format | ||||
defined below MAY be included. The number MUST match the value | ||||
carried in the Num SDIs field. | ||||
A router receiving the Traffic Classification Data Item MUST locate | ||||
the traffic classification information that is associated with the | ||||
TID indicated in each received data item. If no associated traffic | ||||
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.1, that is associated with the TID is updated as | ||||
needed. | ||||
5.1.1. Traffic Classification Sub Data Item | ||||
All Traffic Classification Sub Data Items share a common format that | ||||
is patterned after the standard DLEP data item format, see [RFC8175] | ||||
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. | ||||
The format of the Traffic Classification Sub Data Item is: | ||||
0 1 2 3 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Sub Data Item Type | Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Value... : | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Sub Data Item Type: | ||||
A 16-bit unsigned integer that indicates the type and | ||||
corresponding format of the data item's Value field. Sub Data | ||||
Item Types are managed according to the IANA registry described in | ||||
Section 9.4. | ||||
Length: Variable | ||||
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. | ||||
5.2. DiffServ Credit Window Traffic Classification Sub Data Item | ||||
The DiffServ Credit Window Traffic Classification Sub Data Item is | ||||
used to identify the DSCPs associated with a specific credit window. | ||||
Credit windows are identified 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 sub data | ||||
item. DSCPs are 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. | ||||
The format of the DiffServ Credit Window Traffic Classification Sub | ||||
Data Item is: | ||||
0 1 2 3 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| 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 three (3) 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 4.3.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 plane 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, then it | ||||
MUST be treated as an error as described above. | ||||
When there are no unknown CIDs, the receiver MUST ensure that each DS | ||||
Field value is listed only once across the whole 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 Traffic Classification Data | ||||
Item, the data item MUST be treated as an error as described above. | ||||
In all cases, the router MUST use validated DSCPs in data plane | ||||
credit window identification as described in Section 4.1. | ||||
6. 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, MUST | DiffServ Aware Credit Window Extension Type, see Section 3, MUST NOT | |||
NOT use the [I-D.ietf-manet-credit-window] defined Credit data items. | use the [I-D.ietf-manet-credit-window] defined Credit data items. If | |||
If a node supporting the extension defined in this document, receives | a node supporting the extension defined in this document, receives a | |||
a [I-D.ietf-manet-credit-window] defined data item, the recipient | [I-D.ietf-manet-credit-window] defined data item, the recipient MUST | |||
MUST ignore the received information. | ignore the received information. | |||
7. Management Considerations | ||||
This section provides several network management guidelines to | ||||
implementations supporting the DiffServ Aware Credit Window | ||||
Extension. | ||||
The use of the extension defined in this document SHOULD be | ||||
configurable on both modems and routers. | ||||
Modems SHOULD support the configuration of DSCP to credit window | ||||
(queue) mapping. | ||||
Modems MAY support the configuration of the number of credit windows | ||||
(queues) to advertise to a router. | ||||
Routers may have limits on the number of queues that they can support | ||||
and, perhaps, even limits in supported credit window combinations, | ||||
e.g., if per destination queues can even be supported at all. When | ||||
modem-provided credit window information exceeds the capabilities of | ||||
a router, the router MAY use a subset of the provided credit windows. | ||||
Alternatively, a router MAY reset the session and indicate that the | ||||
extension is not supported. In either case, the mismatch of | ||||
capabilities SHOULD be reported to the user via normal network | ||||
management mechanisms, e.g., user interface or error logging. | ||||
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 | |||
[RFC8175]. The approach taken to Security in that document and | [RFC8175]. The approach taken to Security in that document and | |||
[I-D.ietf-manet-credit-window] apply equally when running the | [I-D.ietf-manet-credit-window] apply equally when 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 [RFC8175]. | assignments are to registries defined by [RFC8175]. | |||
9.1. Extension Type Value | 9.1. Extension Type Value | |||
skipping to change at page 19, line 20 ¶ | skipping to change at page 20, line 30 ¶ | |||
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 [RFC8175]. | 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 Type 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 Window | | |||
+------+---------------------------------+ | +------+------------------------------+ | |||
Table 1: Requested Extension Type Value | Table 1: Requested Extension Type Value | |||
9.2. Message Values | 9.2. Message Values | |||
This document requests 2 new assignments to the DLEP Message Registry | This document requests 2 new assignments to the DLEP Message Registry | |||
named "Message Values" in the range with the "Specification Required" | named "Message Values" in the range with the "Specification Required" | |||
policy. The requested values are as follows: | policy. The requested values are as follows: | |||
+-----------+-------------------------+ | +-----------+-------------------------+ | |||
skipping to change at page 19, line 47 ¶ | skipping to change at page 21, line 8 ¶ | |||
| 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 the following new assignments to the DLEP Data | This document requests the following new assignments to the DLEP Data | |||
Item Registry named "Data Item Values" in the range with the | Item Registry named "Data Item Type 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 | Credit Window Initialization | | | TBA4 | Credit Window Initialization | | |||
| | | | | | | | |||
| TBA5 | Credit Window Traffic Classification | | | TBA5 | Credit Window Association | | |||
| | | | | | | | |||
| TBA6 | Credit Window Association | | | TBA6 | Credit Window Grant | | |||
| | | | | | | | |||
| TBA7 | Credit Window Grant | | | TBA7 | Credit Window Status | | |||
| | | | | | | | |||
| TBA8 | Credit Window Status | | | TBA8 | Credit Window Request | | |||
| | | | | | | | |||
| TBA9 | Credit Window Request | | | TBA9 | Traffic Classification | | |||
+-----------+--------------------------------------+ | +-----------+------------------------------+ | |||
Table 3: Requested Data Item Values | Table 3: Requested Data Item Values | |||
9.4. DLEP Sub Data Item Registry | 9.4. DLEP Sub Data Item Registry | |||
Upon approval of this document, IANA is requested to create a new | Upon approval of this document, IANA is requested to create a new | |||
DLEP registry, named "Sub Data Item Type Values". The registry shall | DLEP registry, named "Sub Data Item Type Values". The registry shall | |||
identify the type code value, the Data Item which may use the value, | 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 | and a description of the value. While the same value may be reused | |||
in different data items, this is not recommended at this time. | in different data items, this is not recommended at this time. | |||
The following table provides initial registry values and the | The following table provides initial registry values and the | |||
[RFC8126] defined policies that should apply to the registry: | [RFC8126] defined policies that should apply to the registry: | |||
+-------------+-----------------------------+-----------------------+ | +-------------+------------------------------+----------------------+ | |||
| Type Code | Valid Data Items | Description | | | Type Code | Valid Data Items | Description | | |||
+-------------+-----------------------------+-----------------------+ | +-------------+------------------------------+----------------------+ | |||
| 0 | N/A | Reserved | | | 0 | N/A | Reserved | | |||
| | | | | | | | | | |||
| 1 | N/A | Reserved (for pause | | | 1 | N/A | Reserved (for pause | | |||
| | | sub-DI) | | | | | sub-DI) | | |||
| | | | | | | | | | |||
| 2 | (TBD4) Credit Window | DiffServ Traffic | | | 2 | DiffServ Credit Window | DiffServ Traffic | | |||
| | Traffic Classification | Classification | | | | Traffic Classification | Classification | | |||
| | | | | | | | | | |||
| 2-65407 | | Specification | | | 2-65407 | | Specification | | |||
| | | Required | | | | | Required | | |||
| | | | | | | | | | |||
| 65408-65534 | | Private Use | | | 65408-65534 | | Private Use | | |||
| | | | | | | | | | |||
| 65535 | | Reserved | | | 65535 | | Reserved | | |||
+-------------+-----------------------------+-----------------------+ | +-------------+------------------------------+----------------------+ | |||
Table 4: Initial Registry Values | Table 4: Initial Registry Values | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[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, | |||
skipping to change at page 22, line 5 ¶ | skipping to change at page 23, line 5 ¶ | |||
DOI 10.17487/RFC8175, June 2017, | DOI 10.17487/RFC8175, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8175>. | <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. | |||
[I-D.ietf-manet-dlep-pause-extension] | ||||
Cheng, B., Wiggins, D., and L. Berger, "DLEP Control Plane | ||||
Based Pause Extension", draft-ietf-manet-dlep-pause- | ||||
extension-02 (work in progress), October 2017. | ||||
[IEEE.802.1Q_2014] | ||||
IEEE, "IEEE Standard for Local and metropolitan area | ||||
networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, | ||||
DOI 10.1109/ieeestd.2014.6991462, December 2014, | ||||
<http://ieeexplore.ieee.org/servlet/ | ||||
opac?punumber=6991460>. | ||||
[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, | |||
<https://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, | |||
<https://www.rfc-editor.org/info/rfc2475>. | <https://www.rfc-editor.org/info/rfc2475>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
The sub data item format was inspired by Rick Taylor's "Data Item | The sub data item format was inspired by Rick Taylor's "Data Item | |||
Containers". He also proposed the separation of credit windows from | Containers". He also proposed the separation of credit windows from | |||
traffic classification at IETF98. | traffic classification at IETF98. Many useful comments were received | |||
from contributors to the MANET working group. | ||||
Appendix B. Open and Resolved Issues | Appendix B. Notional Support for Ethernet Priority Code Points | |||
This section captures issues that are open or have been addressed | This document is intended to allow for use of the credit control | |||
since the document has become a WG draft. This section will be | mechanisms defined in Section 4 with different flow identification | |||
removed before submission for publication. | techniques. This section explores the viability of this through the | |||
notional definition of credit control with Ethernet Priority Code | ||||
Points. Ethernet Priority Code Point support is defined as part of | ||||
the IEEE 802.1Q [IEEE.802.1Q_2014] tag format and includes a 3 bit | ||||
"PCP" field. The tag format also includes a 12 bit VLAN identifier | ||||
(VID) field. | ||||
B.1. Merge with [I-D.ietf-manet-credit-window] | In theory only one new Traffic Classification Sub Data Item is | |||
required to enable support for the traffic classification of a new | ||||
flow type. This section defines such a sub data item. This | ||||
definition is not a full Extension definition, but may serve as the | ||||
foundation for such in the future; in a new document. | ||||
There has been discussion within the WG that this document should be | B.1. Notional Ethernet Credit Window Traffic Classification Sub Data | |||
merged with [I-D.ietf-manet-credit-window]. The timing of this is | Item | |||
TBD. The authors would like to reach closure on some of the | ||||
remaining open issues before embarking on this merge, but are open to | ||||
discussion with the WG and other authors. | ||||
B.2. Supporting Router Limits | The Ethernet Credit Window Traffic Classification Sub Data Item is | |||
used to identify the VLAN and PCPs associated with a specific credit | ||||
window. Credit windows are identified 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 | ||||
sub data item. PCPs are identified in a list of priority fields. An | ||||
implementation that does not support PCPs, and wants to use credit | ||||
window flow control for all traffic to a destination or destinations, | ||||
would indicate with 0 PCPs. Such an implementation could identify a | ||||
VLAN to use per destination. | ||||
Routers may have limits on the number of queues that they can support | The format of the Ethernet Credit Window Traffic Classification Sub | |||
and, perhaps, if per destination queues can even be supported at all. | Data Item is: | |||
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 | ||||
information cannot be supported. Support for these cases clearly | ||||
needs to be addressed. | ||||
This issue was reported by Stan Ratliff <ratliffstan@gmail.com>. | 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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| TBD | Length (8) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Credit Window Identifier (CID)|NumPCPs| VLAN Identifier (VID) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Pri. 1| Pri. 2| Pri. 3| Pri. 4| Pri. 5| Pri. 6| Pri. 7| Pri. 8| | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
B.3. Absolute vs Increment | Length: Variable | |||
Stan Ratliff <ratliffstan@gmail.com> suggested an approach to | Length is the number of octets in the sub data item. It is equal | |||
simplify credit synchronization and re-synchronization by always | to eight (8). | |||
passing the credit window size rather than credit window increments. | ||||
This is an interesting idea that needs to be explored and perhaps | ||||
experimented with. | ||||
B.4. Bidirectional Flow Control (closed) | Credit Window Identifier (CID): | |||
One of the key differences between this draft and | A 16-bit unsigned integer identifying a credit window that has | |||
[I-D.ietf-manet-credit-window] is that this document only supports | been identified in a Credit Window Initialization Data Item, see | |||
flow control in one direction, i.e., for traffic sent from a router | Section 4.3.1. Unknown CID values SHOULD be reported and result | |||
to a modem, while the other credit-window draft supports it in both | in associated traffic being dropped. | |||
directions. | ||||
This was a conscious choice, made out of the desire to keep the | Num PCPs: | |||
extension as simple as possible and to provide what is really | ||||
expected to be used. Clearly the reason for being able to control | ||||
traffic that is sent from the router to the modem/radio is pretty | ||||
easily understood. Also, while bidirectional flow control existed in | ||||
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 - | ||||
once there is an actual need. | ||||
Based on a brief discussion on the WG list, and the absence of any | A 4-bit unsigned integer indicating the number of PCPs carried in | |||
advocates for bidirectional flow control, there is no current plan to | the sub data item. A zero (0) indicates a (wildcard) match | |||
add bidirectional flow control to this document. | against any PCP value. | |||
VLAN identifier (VID): | ||||
A 12-bit unsigned integer field indicating the VLAN to be used in | ||||
traffic classification. A value of all ones (0xFFF) indicates a | ||||
wild card and any VID is to be accepted during traffic | ||||
classification. Zero (0) and any other value are valid values. | ||||
Priority: | ||||
Each Priority Field is an 4-bit whose definition includes the PCP | ||||
field defined in [IEEE.802.1Q_2014] | ||||
0 1 2 3 | ||||
+---+---+---+---+ | ||||
| PCP |DEI| | ||||
+---+---+---+---+ | ||||
PCP: Priority code point | ||||
DEI: currently unused, MUST be zero | ||||
A router receiving the Ethernet Traffic Classification Sub Data Item | ||||
MUST validate the information on receipt prior to the information and | ||||
data plane 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. | ||||
When there are no unknown CIDs, the receiver MUST ensure that each | ||||
Priority Field value is listed only once across the whole Traffic | ||||
Classification Data Item. Note, this check is across the data item | ||||
and not the individual sub data item. If the same Priority Field | ||||
value is listed more than once within the same Traffic Classification | ||||
Data Item, the data item MUST be treated as an error as described | ||||
above. | ||||
In all cases, the router MUST use validated PCPs in data plane credit | ||||
window identification as described in Section 4.1. | ||||
B.2. Other Considerations | ||||
A full definition for the support of an Ethernet Credit Window | ||||
Extensions would need to assign a new Extension Type Value as well as | ||||
the Ethernet Credit Window Traffic Classification Sub Data Item | ||||
Value. It would also need to fully document the implications of | ||||
multiple VLAN support, including configuration implications, e.g., | ||||
limiting value to 0 to indicate PCP-only usage. | ||||
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 02421-6426 | Lexington, MA 02421-6426 | |||
Email: bcheng@ll.mit.edu | Email: bcheng@ll.mit.edu | |||
End of changes. 82 change blocks. | ||||
468 lines changed or deleted | 590 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/ |