rfc9893.original.xml		rfc9893.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY filename "draft-ietf-manet-dlep-credit-flow-control-19">
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
	<?rfc symrefs="yes" ?>		docName="draft-ietf-manet-dlep-credit-flow-control-19" number="9893" consensus=
	<?rfc sortrefs="yes"?>		"true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="t
	<?rfc iprnotified="no" ?>		rue" symRefs="true" sortRefs="true" version="3">
	<?rfc strict="yes" ?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
	ipr="trust200902"
	docName="&filename;"
	obsoletes="" updates=""
	submissionType="IETF" xml:lang="en"
	tocInclude="true"
	symRefs="true" sortRefs="true"
	version="3">
	<!-- xml2rfc v2v3 conversion 3.19.4 -->
	<front>		<front>
	<title abbrev="DLEP Credit-Based Flow Control">		<title abbrev="DLEP Credit-Based Flow Control">Dynamic Link Exchange Protoco
	Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and D		l (DLEP) Credit-Based Flow Control Messages and Data Items</title>
	ata Items</title>		<seriesInfo name="RFC" value="9893"/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-manet-dlep-credit-flow-c
	ontrol-19"/>
	<author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">		<author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">
	<organization>MIT Lincoln Laboratory</organization>		<organization>MIT Lincoln Laboratory</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Massachusetts Institute of Technology</street>		<street>Massachusetts Institute of Technology</street>
	<street>244 Wood Street</street>		<street>244 Wood Street</street>
	<city>Lexington</city>		<city>Lexington</city>
	<region>MA</region>		<region>MA</region>
	<code>02421-6426</code>		<code>02421-6426</code>
			<country>United States of America</country>
	</postal>		</postal>
	<email>bcheng@ll.mit.edu</email>		<email>bcheng@ll.mit.edu</email>
	</address>		</address>
	</author>		</author>
	<author initials="D." surname="Wiggins" fullname="David Wiggins">		<author initials="D." surname="Wiggins" fullname="David Wiggins">
	<address>
	<email>david@none.org</email>
	</address>
	</author>		</author>
	<author fullname="Stan Ratliff" initials="S." surname="Ratliff">		<author fullname="Stan Ratliff" initials="S." surname="Ratliff">
	<address>
	<email>stan@none.org</email>
	</address>
	</author>		</author>
	<author initials="L." surname="Berger" fullname="Lou Berger">		<author initials="L." surname="Berger" fullname="Lou Berger">
	<organization>LabN Consulting, L.L.C.</organization>		<organization>LabN Consulting, L.L.C.</organization>
	<address>		<address>
	<email>lberger@labn.net</email>		<email>lberger@labn.net</email>
	</address>		</address>
	</author>		</author>
	<author role="editor" initials="E." surname="Kinzie" fullname="Eric Kinzie">		<author role="editor" initials="E." surname="Kinzie" fullname="Eric Kinzie">
	<organization>LabN Consulting, L.L.C.</organization>		<organization>LabN Consulting, L.L.C.</organization>
	<address>		<address>
	<email>ekinzie@labn.net</email>		<email>ekinzie@labn.net</email>
	</address>		</address>
	</author>		</author>
	<date/>		<date month="November" year="2025"/>
			<area>RTG</area>
			<workgroup>manet</workgroup>
			<!-- [rfced] Please insert any keywords (beyond those that appear in the
			title) for use on <https://www.rfc-editor.org/search>. -->
	<abstract>		<abstract>
	<t>		<t>
	This document defines new Dynamic Link Exchange Protocol (DLEP)		This document defines new Dynamic Link Exchange Protocol (DLEP)
	Data Items that are used to support credit-based flow control.		Data Items that are used to support credit-based flow control.
	Credit window control is used to regulate when data may be sent to		Credit window control is used to regulate when data may be sent to
	an associated virtual or physical queue. The Data Items are		an associated virtual or physical queue. These Data Items are
	extensible and reusable.		extensible and reusable.
			<!-- [rfced] Abstract: As it appears that the two new message types
			(Credit Control and Credit Control Response) also figure prominently
			in this document (and appear to be mentioned in the document title),
			would you like to also mention them in the Abstract?
			Original:
			This document defines new Dynamic Link Exchange Protocol (DLEP) Data
			Items that are used to support credit-based flow control. Credit
			window control is used to regulate when data may be sent to an
			associated virtual or physical queue. The Data Items are extensible
			and reusable.
			Possibly:
			This document defines new Dynamic Link Exchange Protocol (DLEP) Data
			Items that are used to support credit-based flow control. Credit
			window control is used to regulate when data may be sent to an
			associated virtual or physical queue. These Data Items are
			extensible and reusable.
			This document also defines new messages that support credit window
			control. -->
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
			<!-- [rfced] FYI: We have added expansions for abbreviations where
			they are first used, per Section 3.6 of RFC 7322 ("RFC Style Guide")
			(https://www.rfc-editor.org/info/rfc7322). Please review the
			following expansions to ensure correctness.
			DSCP: Differentiated Services Code Point (Figure 1)
			MAC: Media Access Control (Section 2)
			PCP: Priority Code Point (Figure 1) -->
	<section anchor="sec-1" numbered="true">		<section anchor="sec-1" numbered="true">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	The Dynamic Link Exchange Protocol (DLEP), defined in <xref target="RFC817 5" format="default"/>, provides the exchange of link related		The Dynamic Link Exchange Protocol (DLEP), defined in <xref target="RFC817 5" format="default"/>, provides the exchange of link-related
	control information between DLEP peers. DLEP peers are comprised		control information between DLEP peers. DLEP peers are comprised
	of a modem and a router. DLEP defines a base set of mechanisms as		of a modem and a router. DLEP defines a base set of mechanisms as
	well as support for future extensions. DLEP defines Data Items		well as support for future extensions. DLEP defines Data Items,
	which are sets of information that can be reused in DLEP		which are sets of information that can be reused in DLEP
	messaging.		messaging.
	The DLEP specification does not include any flow		The DLEP specification does not include any flow
	identification beyond DLEP endpoints nor flow control capability.		identification beyond DLEP endpoints, nor does it address flow control cap
	There are various flow control techniques theoretically possible		ability.
			Various flow control techniques are theoretically possible
	with DLEP. For example, a credit-window scheme for		with DLEP. For example, a credit-window scheme for
	destination-specific flow control which provides aggregate flow		destination-specific flow control that provides aggregate flow
	control for both modem and routers has been proposed in <xref target="I-D.		control for both modems and routers has been proposed in <xref target="I-D
	ietf-manet-credit-window" format="default"/>, and a control plane pause		.ietf-manet-credit-window" format="default"/>, and a mechanism referred to as th
	based mechanism is defined in <xref target="RFC8651" format="default"/>.		e Control-Plane-Based Pause Extension is defined in <xref target="RFC8651" forma
			t="default"/>.
	The use of other flow control mechanisms simultaneously with		The use of other flow control mechanisms simultaneously with
	Credit-Based Flow Control is not within the scope of this document.		credit-based flow control is not within the scope of this document.
			<!-- [rfced] Section 1: We updated "control plane pause based
			mechanism" per RFC 8651. Please let us know any objections.
			Original:
			For example, a credit-window
			scheme for destination-specific flow control which provides aggregate
			flow control for both modem and routers has been proposed in
			[I-D.ietf-manet-credit-window], and a control plane pause based
			mechanism is defined in [RFC8651].
			Currently:
			For example, a credit-window
			scheme for destination-specific flow control that provides aggregate
			flow control for both modems and routers has been proposed in
			[Credit-Window-Extension], and a mechanism referred to as the
			Control-Plane-Based Pause Extension is defined in [RFC8651]. -->
	</t>		</t>
	<t>		<t>
	Credit-Based Flow Control, as a result of its proactive nature,		Credit-based flow control, as a result of its proactive nature,
	may offer some advantages over a pause mechanism.		may offer some advantages over a pause mechanism.
	Packet loss resulting from insufficient buffer space is less		Packet loss resulting from insufficient buffer space is less
	likely, as a transmitter does not send packets until the receiver		likely, as a transmitter does not send packets until the receiver
	has indicated that there is sufficient buffer available.		has indicated that there is sufficient buffer space available.
	</t>		</t>
	<t>		<t>
	<xref target="router-modem" format="default"/> illustrates		<xref target="router-modem" format="default"/> illustrates
	a local node consisting of a router and a modem with a		a local node consisting of a router and a modem implementing
	DLEP.		DLEP.
	DLEP messages optionally contain a number of Data Items and		DLEP messages optionally contain a number of Data Items and
	Sub-data Items.		Sub-Data Items.
	Traffic flow classification Data Items provided by the modem,		Traffic Classification Data Items provided by the modem
	are defined in <xref target="I-D.ietf-manet-dlep-traffic-classification" f		are defined in <xref target="RFC9892" format="default"/>.
	ormat="default"/>.
	In this case, a flow is identified based on		In this case, a flow is identified based on
	information found in a data plane header and one or more matches		information found in a data plane header, and one or more matches
	are associated with a single flow.		are associated with a single flow.
	Refer to Section 2.3 of <xref target="RFC2475" format="default"/>		Refer to <xref target="RFC2475" section="2.3"/>
	for general background on traffic classification.		for general background on traffic classification.
	</t>		</t>
	<figure anchor="router-modem" align="left" suppress-title="false">		<figure anchor="router-modem" align="left">
	<name slugifiedName="router_to_modem">Router and Modem DLEP Exchange</name		<name>Router and Modem DLEP Exchange</name>
	>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	|--------------------Local Node--------------------|		|--------------------Local Node--------------------|
	| |		| |
	+-----------------------------+ +-------+		+-----------------------------+ +-------+
	| Router | |Modem |		| Router | |Modem |
	| | |Device |{~~~~~~~~} Remote		| | |Device |{~~~~~~~~} Remote
	| | | | Link Nodes		| | | | Link Nodes
	| Traffic Classification: | | | Protocol		| Traffic Classification: | | | Protocol
	| Per TID: | | | (e.g.,		| Per TID: | | | (e.g.,
	| DSCPs to FID / PCPs to FID | | | 802.11)		| DSCPs to FID / PCPs to FID | | | 802.11)
	| | Data Items | |		| | Data Items | |
	| Per Modem: (list of TIDs) |<---------->| |		| Per Modem: (list of TIDs) |<---------->| |
	| FID to Credit Window Queues |============| |		| FID to Credit Window Queues |============| |
	| | | |		| | | |
	+-----------------------------+ +-------+		+-----------------------------+ +-------+
	| |		| |
	|----DLEP--- |		|----DLEP--- |
			DSCP: Differentiated Services Code Point
			FID: Flow Identifier
			PCP: Priority Code Point
			TID: Traffic Classification Identifier
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>		<t>
	This document defines DLEP Data Items which provide		This document defines DLEP Data Items that provide
	a flow control mechanism for traffic sent		a flow control mechanism for traffic sent
	from a router to a modem. Flow control is provided using one or		from a router to a modem. Flow control is provided using one or
	more logical "Credit Windows", each of which will typically be		more logical "Credit Windows", each of which will typically be
	supported by an associated virtual or physical queue.		supported by an associated virtual or physical queue.
	Credit windows may be shared or dedicated on a per flow basis. The		Credit windows may be shared or dedicated on a per-flow basis. The
	Data Items are structured to allow for reuse of the defined		Data Items are structured to allow for the reuse of the defined
	credit window based flow		credit-window-based flow control
	control with different traffic classification techniques.		with different traffic classification techniques.
	A router logically consumes credits for each credit window		A router logically consumes credits for each credit window
	matching packet sent.		matching packet sent.
	</t>		</t>
	<t>		<t>
	Note that this document defines common Messages, Data Items and		Note that this document defines common messages, Data Items, and
	mechanisms that are reusable. They are expected to be required by		mechanisms that are reusable. They are expected to be required by
	DLEP extensions defined in other documents such as found in <xref target=" I-D.ietf-manet-dlep-da-credit-extension" format="default"/>.		DLEP extensions defined in other documents, such as the extension defined in <xref target="RFC9894" format="default"/>.
	</t>		</t>
	<t>		<t>
	This document		This document
	introduces support for credit window control by defining two new DLEP		introduces support for credit window control by defining two new DLEP
	messages in <xref target="sec-msgs" format="default"/>, and five new DLEP		messages (<xref target="sec-msgs" format="default"/>) and five new DLEP Da
	Data		ta
	Items in <xref target="sec-data-items" format="default"/>.		Items (<xref target="sec-data-items" format="default"/>).
	</t>		</t>
	<t>		<t>
	Various conditions described in this document cause a message to		Various conditions described in this document cause a message to
	be logged.		be logged.
	In all cases, the log message results from the contents of a		In all cases, the log message results from the contents of a
	received Data Item defined here.		received Data Item defined here.
	No messages are logged in response to activity in the data plane.		No messages are logged in response to activity in the data plane.
	</t>		</t>
	<section anchor="sec-1.1" numbered="true" toc="default">		<section anchor="sec-1.1" numbered="true" toc="default">
	<name>Key Words</name>		<name>Key Words</name>
	<t>		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in		"<bcp14>SHOULD NOT</bcp14>",
	BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174"		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	format="default"/> when, and		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	only when, they appear in all capitals, as shown here.		are to be interpreted as described in BCP&nbsp;14
	</t>		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-cw-control" numbered="true" toc="default">		<section anchor="sec-cw-control" numbered="true" toc="default">
	<name>Credit Window Control</name>		<name>Credit Window Control</name>
	<t>		<t>
	This section defines additions to DLEP used in credit based flow		This section defines additions to DLEP used in credit-based flow
	control.		control.
	The use of credit window control impacts the data plane.		The use of credit window control impacts the data plane.
	</t>		</t>
	<t>		<t>
	The credit window control mechanisms defined in this document		The credit window control mechanisms defined in this document
	support credit based flow control of traffic sent from a router to a		support credit-based flow control of traffic sent from a router to a
	modem. The mapping of specific flows to a particular		modem. The mapping of specific flows to a particular
	credit window is based on the Traffic Classification Data Item		credit window is based on the Traffic Classification Data Item
	defined in <xref target="I-D.ietf-manet-dlep-traffic-classification" format=		defined in <xref target="RFC9892" format="default"/>.
	"default"/>.		Both types of DLEP peers -- router and modem -- negotiate the use of an
	Both types of DLEP peers, router and modem, negotiate the use of an
	extension employing this mechanism during session initialization as		extension employing this mechanism during session initialization as
	required, for example, by		required; for example, see
	<xref target="I-D.ietf-manet-dlep-da-credit-extension" format="default"/>.		<xref target="RFC9894" format="default"/>.
	When using		When using
	credit windows, data traffic is only allowed to be sent by the		credit windows, data traffic is only allowed to be sent by the
	router to the modem when there are credits available.		router to the modem when there are credits available.
	</t>		</t>
	<t>		<t>
	Credits are managed on a per logical "Credit Window" basis. Each		Credits are managed on a 'per logical "Credit Window"' basis. Each
	credit window can be thought of as corresponding to a queue within a		credit window can be thought of as corresponding to a queue within a
	modem. Credit windows may be shared across, or dedicated to,		modem. Credit windows may be shared across, or dedicated to,
	destinations and data plane identifiers, for example, DSCPs, at a		destinations and data plane identifiers -- for example, DSCPs -- at a
	granularity that is appropriate for a modem's implementation and its		granularity that is appropriate for a modem's implementation and its
	attached transmission technology. As defined below in		attached transmission technology. As specified in
	<xref target="sec-di-cwi" format="default"/>, there is a		<xref target="sec-di-cwi" format="default"/>, there is a
	direct one-for-one mapping of credit windows to flows as identified		direct one-to-one mapping of credit windows to flows as identified
	by Flow Identifiers (FIDs) carried within the Traffic Classification Data It em. Modems		by Flow Identifiers (FIDs) carried within the Traffic Classification Data It em. Modems
	pass to the router information on their credit windows and FIDs		pass to the router information on their credit windows and FIDs
	prior to a router being able to send data when an extension		prior to a router being able to send data when an extension
	requiring the use of credit window control is used.		requiring the use of credit window control is used.
	Note that TID and FID values are significant only to the issuing modem.		Note that Traffic Classification Identifier (TID) values and FID values are significant only to the issuing modem.
	There is no relationship implied by the same TID or FID value being		There is no relationship implied by the same TID or FID value being
	issued by more than one modem.		issued by more than one modem.
	In addition to		In addition to
	the traffic classification information associated with a FID,		the traffic classification information associated with a FID,
	modems provide an initial credit window size, as well as the		modems provide an initial credit window size, as well as the
	maximum size of the logical queue associated with each credit		maximum size of the logical queue associated with each credit
	window. The maximum size is included for informative and potential		window. The maximum size is included for informative and potential
	future uses.		future uses.
	</t>		</t>
	<t>		<t>
	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.		when rate information changes.
	An increment to a Credit Window size, specified in a Credit Grant		An increment to a credit window size, specified in a Credit Grant
	Data Item, is provided in a Destination Up or the new "Credit Control"		Data Item, is provided in a Destination Up Message (<xref target="sec-di-cwa
	Message.		"/>) or Credit Control
			Message (<xref target="sec-cc-msg"/>).
	A router provides its view		A router provides its view
	of the Credit Window, which is known as "Status", in Destination Up		of the Credit Window, which is known as "Status", in Destination Up
	Response and the new "Credit Control Response" Messages. Routers		Response Messages (<xref target="sec-di-grant"/>) and Credit Control Respons
	can also request credits using the new "Credit Control" Message.		e Messages (<xref target="sec-ccr-msg"/>). Routers
	</t>		can also request credits using the Credit Control Message.</t>
	<t>		<t>
	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		(per-packet) Media Access Control (MAC) headers, and this may not match the
	the modem attached transmission technology. In that case a direct		actual overhead of
	mapping, or an approximation will need to be made by the modem to		the modems' attached transmission technology. In that case, a direct
			mapping or an approximation will need to be made by the modem to
	provide appropriate credit values.		provide appropriate credit values.
	</t>		</t>
	<t>		<t>
	Actual flows of traffic are mapped to credit windows based on flow		Actual flows of traffic are mapped to credit windows based on flow
	identification information provided by modems in the Traffic		identification information provided by modems in the Traffic
	Classification Data Item defined in <xref target="I-D.ietf-manet-dlep-traffi		Classification Data Item defined in <xref target="RFC9892" format="default"/
	c-classification" format="default"/>. This		>. This
	data item supports traffic classification on a per destination or		Data Item supports traffic classification on a per-destination or
	more fine grain level. Routers use the combination of the DLEP		more fine-grained level. Routers use the combination of the
	identified destination and flow information associated with a credit		DLEP-identified destination and flow information associated with a credit
	window in order to match traffic they send to specific credit		window in order to match traffic they send to specific credit
	windows.		windows.
	In some cases, the Traffic Classification Data Item allows		In some cases, the Traffic Classification Data Item allows
	the modem to specify a wildcard to match any packets that do not		the modem to specify a wildcard to match any packets that do not
	match other data items, for example see <xref target		match other Data Items; for example, see <xref target="RFC9895"/>.
	="I-D.ietf-manet-dlep-ether-credit-extension"/>.		In the absence of a wildcard, a packet may not match any of the Data
	In the absence of a wildcard, a packet may not match any of the data		Items and, in this case, <bcp14>MUST</bcp14> be dropped by the router.
	items and, in this case, MUST be dropped by the router.
	</t>		</t>
	<t>		<t>
	When a destination becomes reachable, a modem "associates"		When a destination becomes reachable, a modem "associates"
	(identifies) the appropriate traffic classification information via		(identifies) the appropriate traffic classification information via
	the Traffic Class Identifier (TID) to be used for traffic sent by the router to that		the TID to be used for traffic sent by the router to that
	destination.		destination.
	This is supported by the Credit Window		This is supported by the Credit Window
	Association Data Item which is carried in Destination Up and Update		Association Data Item, which is carried in Destination Up and Destination Up
	messages, see <xref target="sec-di-cwa" format="default"/>.		date
			Messages; see <xref target="sec-di-cwa" format="default"/>.
	The TID provides the information to support router traffic		The TID provides the information to support router traffic
	classification, based on the FIDs contained in the TID, see <xref target="I- D.ietf-manet-dlep-traffic-classification" format="default"/>.		classification, based on the FIDs contained in the TID; see <xref target="RF C9892" format="default"/>.
	As defined,		As defined,
	each credit window has a corresponding FID, so traffic is		each credit window has a corresponding FID, so traffic is
	mapped to a credit window by locating a matching FID that is		mapped to a credit window by locating a matching FID that is
	contained in the TID that is associated with the traffic's		contained in the TID that is associated with the traffic's
	destination.		destination.
	This means that the use of FIDs, TIDs and the association of a		This means that the use of FIDs and TIDs, and the association of a
	TID to a DLEP destination enables a modem to share or dedicate		TID to a DLEP destination, enable a modem to share or dedicate
	resources as needed to match the specifics of its implementation and		resources as needed to match the specifics of its implementation and
	its attached transmission technology.		its attached transmission technology.
			<!-- [rfced] Section 2: We had trouble determining what is listed in
			this sentence. We updated as follows. If this is incorrect, please
			clarify the text.
			Original:
			This means that the use of FIDs, TIDs and the
			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.
			Currently:
			This means that the use
			of FIDs and TIDs, and the association of a TID to a DLEP destination,
			enable a modem to share or dedicate resources as needed to match the
			specifics of its implementation and its attached transmission
			technology. -->
	</t>		</t>
	<t>		<t>
	The defined credit window control has similar objectives as the		Credit window control as defined in this document has objectives similar t
	control found in <xref target="I-D.ietf-manet-credit-window" format="defau		o the
	lt"/>.		control technique described in <xref target="I-D.ietf-manet-credit-window"
	One notable difference from that credit control is that in this		format="default"/>.
			One notable difference from that type of credit control is that in this
	document, credits are never provided by the router to the modem.		document, credits are never provided by the router to the modem.
	</t>		</t>
	<section anchor="data-plane" numbered="true">		<section anchor="data-plane" numbered="true">
	<name>Data Plane Considerations</name>		<name>Data Plane Considerations</name>
	<t>		<t>
	When credit windowing is used, a router MUST NOT send data traffic		When credit windowing is used, a router <bcp14>MUST NOT</bcp14> send data traffic
	to a modem for forwarding if there is no matching classifier.		to a modem for forwarding if there is no matching classifier.
	If a matching classifier is found, a router MUST NOT send data		If a matching classifier is found, a router <bcp14>MUST NOT</bcp14> send d ata
	traffic to a modem when there are no credits available in the		traffic to a modem when there are no credits available in the
	associated Credit Window.		associated Credit Window.
	<xref target="sec-cw-control" format="default"/> describes		<xref target="sec-cw-control" format="default"/> describes
	how classifiers are associated with destinations and how credit		how classifiers are associated with destinations and how credit
	windows are associated with classifiers.		windows are associated with classifiers.
	Additionally, a router MUST ensure sufficient credits are available in the associated		Additionally, a router <bcp14>MUST</bcp14> ensure that sufficient credits are available in the associated
	Credit Window for the current data packet before sending that data packet to the modem.		Credit Window for the current data packet before sending that data packet to the modem.
	The count of octets in the packet includes MAC overhead.		The count of octets in the packet includes MAC overhead.
	In the example of Ethernet, framing, header and trailer are all		Taking Ethernet as an example, framing, header, and trailer are all
	included in this count.		included in this count.
	This document defines credit windows in octets and the credit		This document defines credit windows in octets, and the credit
	window is decremented by the number of sent octets.		window is decremented by the number of sent octets.
			<!-- [rfced] Section 2.1: We had trouble following this sentence.
			Does "framing" mean "frame size" or something else?
			Original:
			In the example of Ethernet, framing,
			header and trailer are all included in this count. -->
	</t>		</t>
	<t>		<t>
	A router MUST identify the credit window associated with traffic		A router <bcp14>MUST</bcp14> identify the credit window associated with tr affic
	to be		to be
	sent to a modem based on the traffic classification information		sent to a modem based on the traffic classification information
	provided in the Data Items defined in this document.		provided in the Data Items defined in this document.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-msgs" numbered="true">		<section anchor="sec-msgs" numbered="true">
	<name>Credit Window Messages</name>		<name>Credit Window Messages</name>
	<t>		<t>
	Two new messages are defined in support for credit window control:		This document defines two new messages that support credit window control:
	the Credit Control and the Credit Control Response Messages. Sending		Credit Control Messages and Credit Control Response Messages. Sending
	and receiving both message types is REQUIRED to support the credit		and receiving both message types is <bcp14>REQUIRED</bcp14> to support the
	window control defined in this document.		credit
			window control mechanisms defined in this document.
	</t>		</t>
	<section anchor="sec-cc-msg" numbered="true">		<section anchor="sec-cc-msg" numbered="true">
	<name>Credit Control Message</name>		<name>Credit Control Message</name>
	<t>		<t>
	Credit Control Messages are sent by modems and routers. Each		Credit Control Messages are sent by modems and routers. Each
	sender is only permitted to have one message outstanding at one		sender is only permitted to have one message outstanding at one
	time. That is, a sender (either modem or router) MUST NOT send		time. That is, a sender (either modem or router) <bcp14>MUST NOT</bcp14
	any subsequent Credit Control Message until a Credit		> send
	Control Response Message is received from its peer.		a subsequent Credit Control Message until a Credit
			Control Response Message has been received from its peer.
	</t>		</t>
	<t>		<t>
	Credit Control Messages are sent by modems to provide credit		Credit Control Messages are sent by modems to provide credit
	window increases. Modems send credit increases when there is		window increases. Modems send credit increases when their
	transmission or local queue availability that exceeds the credit		transmission or local queue availability exceeds the credit
	window value previously provided to the router. Modems will need to		window value previously provided to the router. Modems will need to
	balance the load generated by sending and processing credit		balance the load generated by sending and processing credit
	window increases against a router having data traffic available to send,		window increases against a router having data traffic available to send,
	but no credits available.		but no credits available.
			<!-- [rfced] Section 2.2.1: We had trouble parsing these sentences.
			If the suggested text is not correct, please clarify "having data
			traffic available to send, but no credits available".
			Original:
			Modems will need to balance the
			load generated by sending and processing credit window increases
			against a router having data traffic available to send, but no
			credits available.
			...
			Routers will need to balance the load
			generated by sending and processing credit window requests against
			having data traffic available to send, but no credits available.
			Suggested:
			Modems will need to balance the
			load generated by sending and processing credit window increases
			against a router that has data traffic available to send but no
			available credits.
			...
			Routers will need to balance the load
			generated by sending and processing credit window requests against
			having data traffic available to send but no available credits. -->
	</t>		</t>
	<t>		<t>
	Credit Control Messages MAY be sent by routers to request		Credit Control Messages <bcp14>MAY</bcp14> be sent by routers to request
	credits and provide window status. Routers will need to		credits and provide window status. Routers will need to
	balance the load generated by sending and processing credit		balance the load generated by sending and processing credit
	window requests against having data traffic available to send,		window requests against having data traffic available to send,
	but no credits available.		but no credits available.
	</t>		</t>
	<t>		<t>
	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 17.
	</t>		</t>
	<t>		<t>
	A Credit Control message sent by a modem, MUST contain one or more		A Credit Control Message sent by a modem <bcp14>MUST</bcp14> contain one
	Credit Window Grant Data Items as defined in <xref target="sec-di-grant"		or more
	format="default"/>. A router receiving this message MUST		Credit Window Grant Data Items as defined in <xref target="sec-di-grant"
			format="default"/>. A router receiving this message <bcp14>MUST</bcp14>
	respond with a Credit Control Response Message.		respond with a Credit Control Response Message.
	</t>		</t>
	<t>		<t>
	A Credit Control message sent by a router, MUST contain one or more Cred		A Credit Control Message sent by a router <bcp14>MUST</bcp14> contain on
	it Window		e or more Credit Window
	Request Data Items defined in <xref target="sec-di-request" format="defa		Request Data Items as defined in <xref target="sec-di-request" format="d
	ult"/> and SHOULD contain a Credit Window		efault"/> and <bcp14>SHOULD</bcp14> contain a Credit Window
	Status Data Item, defined in <xref target="sec-di-status" format="defaul t"/>,		Status Data Item, defined in <xref target="sec-di-status" format="defaul t"/>,
	corresponding to each credit window request. A modem receiving		corresponding to each credit window request. A modem receiving
	this message MUST respond with a Credit Control Response		this message <bcp14>MUST</bcp14> respond with a Credit Control Response
	Message based on the received message and Data Item and the		Message based on the received message and Data Item and the
	processing defined in		processing defined in
	<xref target="sec-ccr-msg" format="default"/>,		<xref target="sec-ccr-msg" format="default"/>,
	which will typically result in credit		which will typically result in credit
	window increments being provided.		window increments being provided.
	</t>		</t>
	<t>		<t>
	Specific processing associated with each Credit Data Item is		Specific processing associated with each Credit Data Item is
	provided in		provided in
	<xref target="sec-data-items" format="default"/>.		<xref target="sec-data-items" format="default"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-ccr-msg" numbered="true">		<section anchor="sec-ccr-msg" numbered="true">
	<name>Credit Control Response Message</name>		<name>Credit Control Response Message</name>
	<t>		<t>
	Credit Control Response Messages are sent by routers to report		Credit Control Response Messages are sent by routers to report
	the current Credit Window for a destination. A Credit Control		the current Credit Window for a destination. A Credit Control
	Response message sent by		Response Message sent by
	a router, MUST contain one or more Credit Window Status Data		a router <bcp14>MUST</bcp14> contain one or more Credit Window Status Da
	Items as defined below in <xref target="sec-di-status" format="default"/		ta
	>.		Items as defined in <xref target="sec-di-status" format="default"/>.
	Specific receive processing associated with the Credit Window		Specific receive processing associated with the Credit Window
	Status Data Item is provided in <xref target="sec-di-status" format="def ault"/>.		Status Data Item is provided in <xref target="sec-di-status" format="def ault"/>.
	</t>		</t>
	<t>		<t>
	Credit Control Response Messages sent by modems MUST contain one		Credit Control Response Messages sent by modems <bcp14>MUST</bcp14> cont ain one
	or more Credit Window Grant Data Items. A Data Item for every		or more Credit Window Grant Data Items. A Data Item for every
	Credit Window Request Data Item contained in the corresponding		Credit Window Request Data Item contained in the corresponding
	Credit Control Message received by the modem MUST be		Credit Control Message received by the modem <bcp14>MUST</bcp14> be
	included. Each Credit Grant Data Item MAY provide zero or more		included. Each Credit Grant Data Item <bcp14>MAY</bcp14> provide zero o
			r more
	additional credits based on the modem's transmission or local		additional credits based on the modem's transmission or local
	queue availability. Specific receive processing associated with		queue availability. Specific receive processing associated with
	each Grant Data Item is provided in <xref target="sec-di-grant" format=" default"/>.		each Grant Data Item is provided in <xref target="sec-di-grant" format=" default"/>.
	</t>		</t>
	<t>		<t>
	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 18.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-data-items" numbered="true">		<section anchor="sec-data-items" numbered="true">
	<name>Credit Window Control Data Items</name>		<name>Credit Window Control Data Items</name>
	<t>		<t>
	Five new Data Items are defined to support credit window control.		Five new Data Items are defined to support credit window control:</t>
	The Credit Window Initialization		<ul spacing="normal">
	Data Item is used by a modem to identify a credit window and set its		<li>The Credit Window Initialization
	size.		Data Item (<xref target="sec-di-cwi"/>) is used by a modem to identify a c
	The Credit Window Association		redit window and set its
	Data Item is used by a modem to identify which traffic classification		size.</li>
	identifiers (flows) should be used when sending traffic to a particular DL		<li>The Credit Window Association
	EP		Data Item (<xref target="sec-di-cwa"/>) is used by a modem to identify whi
	identified destination.		ch TIDs
	The Credit Window Grant Data Item is used by a modem to provide additional		(flows) should be used when sending traffic to a particular
	credits to a router.		DLEP-identified destination.</li>
	The Credit Window Request Data Item is used by a router to request additio		<li>The Credit Window Grant Data Item (<xref target="sec-di-grant"/>) is u
	nal		sed by a modem to provide additional
	credits.		credits to a router.</li>
	The Credit Window Status Data Item is used to advertise the sender's view		<li>The Credit Window Status Data Item (<xref target="sec-di-status"/>) is
	of		used to advertise the sender's view of the
	number of available credits for state synchronization purposes.		number of available credits for state synchronization purposes.</li>
	</t>		<li>The Credit Window Request Data Item (<xref target="sec-di-request"/>)
			is used by a router to request additional
			credits.</li>
			</ul>
	<t>		<t>
	Any errors or inconsistencies encountered in parsing Data Items		Any errors or inconsistencies encountered in parsing Data Items
	are handled in the same fashion as any other data item parsing error		are handled in the same fashion as any other Data Item parsing error
	encountered in DLEP, see <xref target="RFC8175" format="default"/>. In par		encountered in DLEP; see <xref target="RFC8175" format="default"/>. In par
	ticular, the		ticular, the
	node parsing the Data Item MUST terminate the session with a		node parsing the Data Item <bcp14>MUST</bcp14> terminate the session with
	Status Data Item indicating Invalid Data.		a
			Status Data Item indicating "Invalid Data".
			<!-- [rfced] Section 2.3: Does "a Status Data Item" refer
			specifically to the Status Data Item defined in RFC 8175 - in which
			case RFC 8175 should be cited here - or does it refer to the Credit
			Window Status Data Item as defined in this document?
			Original:
			In particular, the node parsing
			the Data Item MUST terminate the session with a Status Data Item
			indicating Invalid Data.
			Perhaps:
			In particular, the node parsing
			the Data Item MUST terminate the session with a Status Data Item
			[RFC8175] indicating "Invalid Data".
			Or possibly:
			In particular, the node parsing
			the Data Item MUST terminate the session with a Credit Window Status
			Data Item indicating "Invalid Data" as defined in [RFC8175]. -->
	</t>		</t>
	<section anchor="sec-di-cwi" numbered="true">		<section anchor="sec-di-cwi" numbered="true">
	<name>Credit Window Initialization</name>		<name>Credit Window Initialization</name>
	<t>		<t>
	The Credit Window Initialization Data Item is used by a modem to		As noted above, the Credit Window Initialization Data Item is used by a modem to
	identify a credit window and set its size.		identify a credit window and set its size.
	In order to avoid errors caused by the use of undefined FIDs or		In order to avoid errors caused by the use of undefined FIDs or
	uninitialized credit windows, this Data Item SHOULD be included		uninitialized credit windows, this Data Item <bcp14>SHOULD</bcp14> be in cluded
	in any Session Initialization Response Message that indicates		in any Session Initialization Response Message that indicates
	support for any such extension.		support for any such extension.
	Updates to		Updates to
	previously identified credit windows or new credit windows MAY		previously identified credit windows or new credit windows <bcp14>MAY</b cp14>
	be sent by a modem by including the Data Item in Session Update		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		Messages. More than one Data Item <bcp14>MAY</bcp14> be included in a m essage
	to provide information on multiple credit windows.		to provide information on multiple credit windows.
	</t>		</t>
	<t>		<t>
	The Credit Window Initialization Data Item identifies a credit		The Credit Window Initialization Data Item identifies a credit
	window using a Flow Identifier, or FID. It also provides the		window using a FID. It also provides the
	size of the identified credit window. To be used, a FID must be		size of the identified credit window. To be used, a FID must be
	defined within a Traffic Classification Data Item and the		defined within a Traffic Classification Data Item, and the
	associated TID must be provided via a Credit Window Association		associated TID must be provided via a Credit Window Association
	Data Item.		Data Item.
	</t>		</t>
	<t>		<t>
	The format of the Credit Window Initialization Data Item is:		The format of the Credit Window Initialization Data Item is as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow Identifier (FID) | Reserved |		| Flow Identifier (FID) | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Credit Value |		| Credit Value |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Scale | Credit Window Max Size |		| Scale | Credit Window Max Size |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		]]></artwork>
	<dl newline="true" spacing="normal">		<dl newline="true" spacing="normal">
	<dt>Data Item Type:</dt>		<dt>Data Item Type:</dt>
	<dd>Data Item Type (TBA4)</dd>		<dd>30</dd>
	<dt>Length:</dt>		<dt>Length:</dt>
	<dd>		<dd>
	<t>16</t>		<t>16</t>
	<t>		<t>
	As specified in <xref target="RFC8175"/>, Length is the number		As specified in <xref target="RFC8175"/>, Length is the number
	of octets in the Data Item. It MUST be equal to sixteen		of octets in the Data Item. It <bcp14>MUST</bcp14> be equal to sixtee
	(16). If it is some other value, the Data Item is corrupt so		n
			(16). If it is some other value, the Data Item is corrupt, so
	the message in which it appears cannot be reliably parsed and		the message in which it appears cannot be reliably parsed and
	is ignored.		is ignored.
	</t>		</t>
	</dd>		</dd>
	<dt>Flow Identifier (FID):</dt>		<dt>Flow Identifier (FID):</dt>
	<dd>		<dd>
	A two-octet flow identifier as defined by the Traffic		A 2-octet flow identifier as defined by the Traffic
	Classification Data Item <xref		Classification Data Item <xref target="RFC9892"/>. The
	target="I-D.ietf-manet-dlep-traffic-classification" />. The
	FID also uniquely identifies a credit window for a specific		FID also uniquely identifies a credit window for a specific
	DLEP session.		DLEP session.
	</dd>		</dd>
	<dt>Reserved:</dt>		<dt>Reserved:</dt>
	<dd>		<dd>
	For the Credit Window Initialization Data Item this reserved		For the Credit Window Initialization Data Item, this reserved
	field is currently unused.		field is currently unused.
	It MUST set to all zeros for this version of the Data Item		It <bcp14>MUST</bcp14> be set to all zeros for this version of the D
	and it is currently ignored on reception.		ata Item
			and is currently ignored on reception.
	This allows for future extensions of the Data Item if needed.		This allows for future extensions of the Data Item if needed.
	</dd>		</dd>
	<dt>Credit Value:</dt>		<dt>Credit Value:</dt>
	<dd>		<dd>
	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		be added to the Credit Window. This value includes MAC
	headers as seen on the link between the modem and router.		headers as seen on the link between the modem and router.
	</dd>		</dd>
	<dt>Scale:</dt>		<dt>Scale:</dt>
	<dd>		<dd>
	<t>		<t>
	An 8-bit unsigned integer indicating the scale used in the Credit Wi ndow		An 8-bit unsigned integer indicating the scale used in the Credit Wi ndow
	Max Size field. The valid values are:		Max Size field. The valid values are as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table anchor="table_scale" align="left">
	Value Scale		<name>Valid Scale Field Values</name>
	------------		<thead><tr><th>Value</th><th align="center">Scale</th></tr></thead>
	0 B - Bytes (Octets)		<tbody>
	1 KB - Kilobytes (B/1024)		<tr><td>0</td><td>B: Bytes (Octets)</td></tr>
	2 MB - Megabytes (KB/1024)		<tr><td>1</td><td>KB: Kilobytes (B/1024)</td></tr>
	3 GB - Gigabytes (MB/1024)		<tr><td>2</td><td>MB: Megabytes (KB/1024)</td></tr>
	]]></artwork>		<tr><td>3</td><td>GB: Gigabytes (MB/1024)</td></tr>
			</tbody>
			</table>
			<!-- [rfced] Section 2.3.1: As the dashes initially appeared to be
			minus signs, we changed them to colons. If this is incorrect, please
			consider whether these entries could be written in some other way.
			We also gave the table a title. Please let us know any objections.
			If you prefer a different title, please specify.
			Original (dashes are broken in order to avoid xml2rfc's "Double
			hyphen within comment" error):
			Value Scale
			- - - - -
			0 B - Bytes (Octets)
			1 KB - Kilobytes (B/1024)
			2 MB - Megabytes (KB/1024)
			3 GB - Gigabytes (MB/1024)
			Currently:
			+=======+=========================+
			| Value | Scale |
			+=======+=========================+
			| 0 | B: Bytes (Octets) |
			+- - - -+- - - - - - - - - - - - -+
			| 1 | KB: Kilobytes (B/1024) |
			+- - - -+- - - - - - - - - - - - -+
			| 2 | MB: Megabytes (KB/1024) |
			+- - - -+- - - - - - - - - - - - -+
			| 3 | GB: Gigabytes (MB/1024) |
			+- - - -+- - - - - - - - - - - - -+
			Table 1: Valid Scale Field Values -->
	</dd>		</dd>
	<dt>Credit Window Max Size:</dt>		<dt>Credit Window Max Size:</dt>
	<dd>		<dd>
	A 24-bit unsigned integer representing the maximum size, in the		A 24-bit unsigned integer representing the maximum size, in the
	octet scale indicated by the Scale field, of the associated credit		octet scale indicated by the Scale field, of the associated credit
	window.		window.
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	A router that receives a Credit Window Initialization Data Item		A router that receives a Credit Window Initialization Data Item
	MUST ensure that the FID field value has been provided by the		<bcp14>MUST</bcp14> ensure that the FID field value has been provided by the
	modem in a Traffic Classification Data Item carried in either		modem in a Traffic Classification Data Item carried in either
	the current or a previous message. If the FID cannot be found the		the current message or a previous message. If the FID cannot be found,
	router SHOULD log this information.		the
			router <bcp14>SHOULD</bcp14> log this information.
	The method of logging is left to the router implementation.		The method of logging is left to the router implementation.
	Note that		Note that
	no traffic will be associated with the credit window in this		no traffic will be associated with the credit window in this
	case. After FID validation, the router MUST locate the credit		case. After FID validation, the router <bcp14>MUST</bcp14> locate the c redit
	window that is associated with the FID indicated in each		window that is associated with the FID indicated in each
	received Data Item. If no associated credit window is found,		received Data Item. If no associated credit window is found,
	the router MUST initialize a new credit window using the values		the router <bcp14>MUST</bcp14> initialize a new credit window using the values
	carried in the Data Item. When an associated credit window is		carried in the Data Item. When an associated credit window is
	found, the router MUST update the credit window and associated		found, the router <bcp14>MUST</bcp14> update the credit window and assoc iated
	data plane state using the values carried in the Data Item.		data plane state using the values carried in the Data Item.
	If the resulting Credit Value results in the credit window		If the resultant Credit Value in turn results in the credit window
	exceeding the represented Credit Window Max Size, the Credit		exceeding the represented Credit Window Max Size, the Credit
	Window Max Size field value is used as the new credit window size.		Window Max Size field value is used as the new credit window size.
			<!-- [rfced] Section 2.3.1: Does "Credit Value" specifically refer
			to the Credit Value field, or does it mean "credit value" as used
			generally elsewhere in this document (e.g., "appropriate credit
			values" as written in Section 2)?
			Original:
			If the resulting
			Credit Value results in the credit window exceeding the represented
			Credit Window Max Size, the Credit Window Max Size field value is
			used as the new credit window size. -->
	</t>		</t>
	<t>		<t>
	It is worth noting, that such updates can result in a credit window		It is worth noting that such updates can result in a credit window
	size being reduced, for example, due to a transmission rate		size being reduced -- for example, due to a transmission rate
	change on the modem.		change on the modem.
	After sending the Session Update Message with one or more Credit		After sending the Session Update Message with one or more Credit
	Window Initialization Data Items that decrease the Credit Window		Window Initialization Data Items that decrease the Credit Window
	Max Size, the modem SHOULD continue processing received packets		Max Size, the modem <bcp14>SHOULD</bcp14> continue processing received p ackets
	that match the indicated FIDs, fit within the window for the		that match the indicated FIDs, fit within the window for the
	unmodified Credit Window Max Size and arrive before the modem		unmodified Credit Window Max Size, and arrive before the modem
	receives the corresponding Session Update Response Message.		receives the corresponding Session Update Response Message.
	The modem SHOULD NOT issue additional credits for any affected		The modem <bcp14>SHOULD NOT</bcp14> issue additional credits for any aff
	FID until that FID's associated Window has drained to be		ected
			FID until that FID's associated window has drained to be
	less than the new Credit Window Max Size, regardless of when		less than the new Credit Window Max Size, regardless of when
	the corresponding Session Update Response Message is received.		the corresponding Session Update Response Message is received.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-di-cwa" numbered="true">		<section anchor="sec-di-cwa" numbered="true">
	<name>Credit Window Association</name>		<name>Credit Window Association</name>
	<t>		<t>
	The Credit Window Association Data Item is used by a modem to		The Credit Window Association Data Item is used by a modem to
	associate traffic classification information with a destination.		associate traffic classification information with a destination.
	The traffic classification information is identified using a TID		The traffic classification information is identified using a TID
	value that has previously been sent by the modem or is listed		value that has been previously sent by the modem or is listed
	in a Traffic Classification Data Item carried in the same message		in a Traffic Classification Data Item carried in the same message
	as the		as the
	Credit Window Association		Credit Window Association
	Data Item. TIDs in different Credit windows must not		Data Item. TIDs in different credit windows must not
	overlap.		overlap.
	</t>		</t>
	<t>		<t>
	A single Credit Window Association Data Item MUST be included in every		A single Credit Window Association Data Item <bcp14>MUST</bcp14> be incl
	Destination Up and Destination Update Message sent by a modem when		uded in every
	the credit window control defined in this document is used. Note		Destination Up and Destination Update Message sent by a modem when a
			credit window control mechanism defined in this document is used. Note
	that a TID will not be used unless it is listed in a Credit Window		that a TID will not be used unless it is listed in a Credit Window
	Association Data Item.		Association Data Item.
	</t>		</t>
	<t>		<t>
	The format of the Credit Window Association Data Item is:		The format of the Credit Window Association Data Item is as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	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)|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		]]></artwork>
	<dl newline="true" spacing="normal">		<dl newline="true" spacing="normal">
	<dt>Data Item Type:</dt>		<dt>Data Item Type:</dt>
	<dd>Data Item Type (TBA5)</dd>		<dd>31</dd>
	<dt>Length:</dt>		<dt>Length:</dt>
	<dd>		<dd>
	<t>2</t>		<t>2</t>
	<t>		<t>
	As specified in <xref target="RFC8175"/>, Length is the number		As specified in <xref target="RFC8175"/>, Length is the number
	of octets in the Data Item. It MUST be equal to two (2). If it		of octets in the Data Item. It <bcp14>MUST</bcp14> be equal to two (2)
	is some other value, the Data Item is corrupt so the message		. If it
			is some other value, the Data Item is corrupt, so the message
	in which it appears cannot be reliably parsed and is ignored.		in which it appears cannot be reliably parsed and is ignored.
	</t>		</t>
	</dd>		</dd>
	<dt> Traffic Classification Identifier (TID):</dt>		<dt> Traffic Classification Identifier (TID):</dt>
	<dd>		<dd>
	A 16-bit unsigned integer identifying a traffic		A 16-bit unsigned integer identifying a traffic
	classification set that has been identified in a Traffic		classification set that has been identified in a Traffic
	Classification Data Item, see <xref target="I-D.ietf-manet-dlep-traf fic-classification" format="default"/>.		Classification Data Item; see <xref target="RFC9892" format="default "/>.
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	A router that receives a Credit Window Association Data Item MUST		A router that receives a Credit Window Association Data Item <bcp14>MUST </bcp14>
	locate the traffic classification information indicated by the		locate the traffic classification information indicated by the
	received TID. If no corresponding information is found, the		received TID. If no corresponding information is found, the
	Credit Window Association		Credit Window Association
	Data Item MUST be treated as an error as described above.		Data Item <bcp14>MUST</bcp14> be treated as an error as described above.
	If the traffic classification information is located, the		If the traffic classification information is located, the
	router MUST ensure that any data plane state that is associated		router <bcp14>MUST</bcp14> ensure that any data plane state that is asso
	with the TID and its corresponding FIDs are updated as needed		ciated
			with the TID and its corresponding FIDs is updated as needed
	(per <xref target="data-plane" format="default"/>).		(per <xref target="data-plane" format="default"/>).
	If a		If a
	router determines that a newly received Data Item results in		router determines that a newly received Data Item results in
	credit windows with overlapping TIDs, the Data Item MUST be		credit windows with overlapping TIDs, the Data Item <bcp14>MUST</bcp14> be
	treated as an error as described above.		treated as an error as described above.
			<!-- [rfced] Section 2.3.2: Because this sentence as written
			indicated that the data plane state is updated as needed, we changed
			"are" to "is" accordingly (also per "In both cases, a router MUST
			also ensure that any data plane state, e.g.,
			[I-D.ietf-manet-dlep-credit-flow-control], that is associated with
			the TID is updated as needed." in
			draft-ietf-manet-dlep-traffic-classification, where it cites this
			document). If this is incorrect, please clarify what is being
			updated as needed.
			Original:
			If the traffic classification information is located, the
			router MUST ensure that any data plane state that is associated with
			the TID and its corresponding FIDs are updated as needed (per
			Section 2.1).
			Currently:
			If the traffic classification information is located, the
			router MUST ensure that any data plane state that is associated with
			the TID and its corresponding FIDs is updated as needed (per
			Section 2.1). -->
	</t>		</t>
	</section>		</section>
	<section anchor="sec-di-grant" numbered="true">		<section anchor="sec-di-grant" numbered="true">
	<name>Credit Window Grant</name>		<name>Credit Window Grant</name>
	<t>		<t>
	The Credit Window Grant Data Item is used by a modem to		The Credit Window Grant Data Item is used by a modem to
	provide credits to a router. One or more Credit Window Grant Data		provide credits to a router. One or more Credit Window Grant Data
	Items MAY be carried in the DLEP Destination Up, Destination Announce		Items <bcp14>MAY</bcp14> be carried in the DLEP Destination Up, Destinat
	Response, Destination Update, Credit Control Messages, and Credit		ion Announce
			Response, Destination Update, Credit Control, and Credit
	Control Response Messages.		Control Response Messages.
	Multiple Credit Window Grant Data Items may be present in a		Multiple Credit Window Grant Data Items may be present in a
	single message.		single message.
	Each item grants credits to a different credit window and,		Each item grants credits to a different credit window and
	therefor, references a different FID.		therefore references a different FID.
	In all		In all
	message types, this Data Item provides an additional number of octets		message types, this Data Item provides an additional number of octets
	to be added to the indicated credit window. Credit windows are		to be added to the indicated credit window. Credit windows are
	identified using FID values that have been previously been		identified using FID values that have been previously
	sent by the modem or are listed in a Credit Window Initialization		sent by the modem or are listed in a Credit Window Initialization
	Data Item carried in the same message as the Data Item.		Data Item carried in the same message as the Data Item.
	</t>		</t>
	<t>		<t>
	The format of the Credit Window Grant Data Item is:		The format of the Credit Window Grant Data Item is as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow Identifier (FID) | Reserved |		| Flow Identifier (FID) | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Additional Credits |		| Additional Credits |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		]]></artwork>
	<dl newline="true" spacing="normal">		<dl newline="true" spacing="normal">
	<dt>Data Item Type:</dt>		<dt>Data Item Type:</dt>
	<dd>Data Item Type (TBA6)</dd>		<dd>32</dd>
	<dt>Length:</dt>		<dt>Length:</dt>
	<dd>		<dd>
	<t>12</t>		<t>12</t>
	<t>		<t>
	As specified in <xref target="RFC8175"/>, Length is the number		As specified in <xref target="RFC8175"/>, Length is the number
	of octets in the Data Item. It MUST be equal to twelve		of octets in the Data Item. It <bcp14>MUST</bcp14> be equal to twelve
	(12). If it is some other value, the Data Item is corrupt so		(12). If it is some other value, the Data Item is corrupt, so
	the message in which it appears cannot be reliably parsed and		the message in which it appears cannot be reliably parsed and
	is ignored.		is ignored.
	</t>		</t>
	</dd>		</dd>
	<dt>Flow Identifier (FID):</dt>		<dt>Flow Identifier (FID):</dt>
	<dd>		<dd>
	A two-octet flow identifier as defined by the Traffic		A 2-octet flow identifier as defined by the Traffic
	Classification Data Item. The FID also uniquely indicates a		Classification Data Item. The FID also uniquely indicates a
	credit window.		credit window.
	</dd>		</dd>
	<dt>Reserved:</dt>		<dt>Reserved:</dt>
	<dd>		<dd>
	For the Credit Window Grant Data Item this reserved field		For the Credit Window Grant Data Item, this reserved field
	is currently unused.		is currently unused.
	It MUST set to all zeros for this version of the Data Item		It <bcp14>MUST</bcp14> be set to all zeros for this version of the D
	and it is currently ignored on reception.		ata Item
			and is currently ignored on reception.
	This allows for future extensions of the Data Item if needed.		This allows for future extensions of the Data Item if needed.
	</dd>		</dd>
	<dt>Additional Credit:</dt>		<dt>Additional Credits:</dt>
	<dd>		<dd>
	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		be added to the Credit Window. This value includes MAC
	headers as seen on the link between the modem and router. A value		headers as seen on the link between the modem and router. A value
	of zero indicates that no additional credits are being provided.</dd>		of zero indicates that no additional credits are being provided.</dd>
	</dl>		</dl>
	<t>		<t>
	When receiving this Data Item, a router MUST identify the credit		When receiving this Data Item, a router <bcp14>MUST</bcp14> identify the credit
	window indicated by the FID. If the FID is not known to the router,		window indicated by the FID. If the FID is not known to the router,
	it SHOULD log this information and discard the Data Item.		it <bcp14>SHOULD</bcp14> log this information and discard the Data Item.
	The method of logging is left to the router implementation.		The method of logging is left to the router implementation.
	It is important to note that while this Data Item can be received in a		It is important to note that while this Data Item can be received in a
	destination specific message, credit windows are managed independently		destination-specific message, credit windows are managed independently
	from the destination identified in the message carrying this Data		of the destination identified in the message carrying this Data
	Item, and the indicated FID MAY even be disjoint from the identified		Item, and the indicated FID <bcp14>MAY</bcp14> even be disjoint from the
			identified
	destination.		destination.
	</t>		</t>
	<t>		<t>
	Once the credit window is identified, the credit window size MUST be		Once the credit window is identified, the credit window size <bcp14>MUST </bcp14> be
	increased by the value contained in the Additional Credits field. If		increased by the value contained in the Additional Credits field. If
	the increase results in a window overflow, the Credit Window		the increase results in a window overflow, the Credit Window
	must be set to its maximum as defined by the Credit Window Max		must be set to its maximum as defined by the Credit Window Max
	Size carried in the Credit Window Initialization Data Item.		Size carried in the Credit Window Initialization Data Item.
	</t>		</t>
	<t>		<t>
	No response is sent by the router to a modem after processing a Credit		No response is sent by the router to a modem after processing a Credit
	Window Grant Data Item received in a Credit Control Response Message.		Window Grant Data Item received in a Credit Control Response Message.
	When a Credit Window Grant Data Item is received in other message types,		When a Credit Window Grant Data Item is received in other message types,
	the receiving router MUST send a		the receiving router <bcp14>MUST</bcp14> send a
	Credit Window Status Data Item or items reflecting the		Credit Window Status Data Item or items reflecting the
	resulting Credit Window value of the updated credit window. When the		resultant Credit Window value of the updated credit window. When the
	Credit Grant Data Item is received in a Destination Up Message, the		Credit Grant Data Item is received in a Destination Up Message, the
	Credit Window Status Data Item(s) MUST be sent in the		Credit Window Status Data Item(s) <bcp14>MUST</bcp14> be sent in the
	corresponding Destination Up Response Message. Otherwise, a		corresponding Destination Up Response Message. Otherwise, a
	Credit Control Message MUST be sent.		Credit Control Message <bcp14>MUST</bcp14> be sent.
			<!-- [rfced] Section 2.3.3: Does "a Credit Window Status Data Item
			or items" mean "one or more Credit Window Status Data Items" here, or
			does "or items" refer to some other types of items other than Data
			Items? We ask because we see "Credit Window Status Data Item(s)" in
			the next sentence.
			Original (the next sentence is included for context):
			When a Credit Window Grant Data Item is received in other
			message types, the receiving router MUST send a Credit Window Status
			Data Item or items reflecting the resulting Credit Window value of
			the updated credit window. When the Credit Grant Data Item is
			received in a Destination Up Message, the Credit Window Status Data
			Item(s) MUST be sent in the corresponding Destination Up Response
			Message.
			Perhaps:
			When a Credit Window Grant Data Item is received in other
			message types, the receiving router MUST send one or more Credit
			Window Status Data Items reflecting the resultant Credit Window
			value of the updated credit window. -->
	</t>		</t>
	</section>		</section>
	<section anchor="sec-di-status" numbered="true">		<section anchor="sec-di-status" numbered="true">
	<name>Credit Window Status</name>		<name>Credit Window Status</name>
	<t>		<t>
	The Credit Window Status Data Item is used by		The Credit Window Status Data Item is used by
	a router to report the current credit window size to its peer modem. On e		a router to report the current credit window size to its peer modem. On e
	or more Credit Window Status Data Items MAY be carried in a		or more Credit Window Status Data Items <bcp14>MAY</bcp14> be carried in a
	Destination Up Response Message or a Credit Control Response Message.		Destination Up Response Message or a Credit Control Response Message.
	As discussed in		As discussed in
	<xref target="sec-di-grant" format="default"/>,		<xref target="sec-di-grant" format="default"/>,
	the Destination Up Response Message is used when		the Destination Up Response Message is used when
	the Data Item is sent in response to a Destination Up Message, and		the Data Item is sent in response to a Destination Up Message, and
	the Credit Control Response Message is sent in response to a Credit		the Credit Control Response Message is sent in response to a Credit
	Control Message. Multiple Credit Window Status Data Items in a		Control Message. Multiple Credit Window Status Data Items in a
	single message are used to indicate different sizes of different		single message are used to indicate different sizes of different
	credit windows. Similar to the Credit Window Grant, credit windows		credit windows. Similar to the Credit Window Grant Data Item, credit wi
	are identified using FID values that have been previously been sent		ndows
			are identified using FID values that have been previously sent
	by the modem.		by the modem.
	</t>		</t>
	<t>		<t>
	The format of the Credit Window Status Data Item is:		The format of the Credit Window Status Data Item is as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow Identifier (FID) | Reserved |		| Flow Identifier (FID) | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Current Credit Window Size |		| Current Credit Window Size |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		]]></artwork>
	<dl newline="true" spacing="normal">		<dl newline="true" spacing="normal">
	<dt>Data Item Type:</dt>		<dt>Data Item Type:</dt>
	<dd>Data Item Type (TBA7)</dd>		<dd>33</dd>
	<dt>Length:</dt>		<dt>Length:</dt>
	<dd>		<dd>
	<t>12</t>		<t>12</t>
	<t>		<t>
	As specified in <xref target="RFC8175"/>, Length is the number		As specified in <xref target="RFC8175"/>, Length is the number
	of octets in the Data Item. It MUST be equal to twelve		of octets in the Data Item. It <bcp14>MUST</bcp14> be equal to twelve
	(12). If it is some other value, the Data Item is corrupt so		(12). If it is some other value, the Data Item is corrupt, so
	the message in which it appears cannot be reliably parsed and		the message in which it appears cannot be reliably parsed and
	is ignored.		is ignored.
	</t>		</t>
	</dd>		</dd>
	<dt>Flow Identifier (FID):</dt>		<dt>Flow Identifier (FID):</dt>
	<dd>		<dd>
	A two-octet flow identifier as defined by the Traffic		A 2-octet flow identifier as defined by the Traffic
	Classification Data Item. The FID also uniquely identifies		Classification Data Item. The FID also uniquely identifies
	a credit window.		a credit window.
	</dd>		</dd>
	<dt>Reserved:</dt>		<dt>Reserved:</dt>
	<dd>		<dd>
	For the Credit Window Status Data Item this reserved field		For the Credit Window Status Data Item, this reserved field
	is currently unused.		is currently unused.
	It MUST set to all zeros for this version of the Data Item		It <bcp14>MUST</bcp14> be set to all zeros for this version of the D
	and it is currently ignored on reception.		ata Item
			and is currently ignored on reception.
	This allows for future extensions of the Data Item if needed.		This allows for future extensions of the Data Item if needed.
	</dd>		</dd>
	<dt>Current Credit Window Size:</dt>		<dt>Current Credit Window Size:</dt>
	<dd>		<dd>
	A 64-bit unsigned integer, indicating		A 64-bit unsigned integer indicating
	the current number of credits, in octets, available for the		the current number of credits, in octets, available for the
	router to send to the modem.		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
	<xref target="I-D.ietf-manet-credit-window" format="default"/>.		<xref target="I-D.ietf-manet-credit-window" format="default"/>.
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	When receiving this Data Item, a modem MUST identify the credit		When receiving this Data Item, a modem <bcp14>MUST</bcp14> identify the credit
	window indicated by the FID. If the FID is not known to the modem,		window indicated by the FID. If the FID is not known to the modem,
	it SHOULD log this information and discard the Data Item.		it <bcp14>SHOULD</bcp14> log this information and discard the Data Item.
	The method of logging is left to the modem implementation.		The method of logging is left to the modem implementation.
	As with the Credit Window Grant Data Item, the FID MAY be unrelated to		As with the Credit Window Grant Data Item, the FID <bcp14>MAY</bcp14> be
	the Destination indicated in the message carrying the Data Item.		unrelated to
			the destination indicated in the message carrying the Data Item.
	</t>		</t>
	<t>		<t>
	Once the credit window is identified, the modem SHOULD check the		Once the credit window is identified, the modem <bcp14>SHOULD</bcp14> ch eck the
	received Current Credit Window Size field value against the outstanding credit		received Current Credit Window Size field value against the outstanding credit
	window's available credits at the time the most recent Credit Window		window's available credits at the time the most recent Credit Window
	Initialization or Grant Data Item associated with the indicated FID		Initialization or Grant Data Item associated with the indicated FID
	was sent. If the difference in values is greater than can		was sent. If the difference in values is greater than what can
	be accounted for based on observed data frames, then the modem SHOULD		be accounted for based on observed data frames, then the modem <bcp14>SH
			OULD</bcp14>
	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 in		credits. As specified in
	<xref target="sec-di-cwi" format="default"/>,		<xref target="sec-di-cwi" format="default"/>,
	Credit Window Initialization Data Items are		Credit Window Initialization Data Items are
	sent in Session Update Messages. When multiple Data Items need to be		sent in Session Update Messages. When multiple Data Items need to be
	sent, they SHOULD be combined into a single message when possible.		sent, they <bcp14>SHOULD</bcp14> be combined into a single message when possible.
	Alternatively, and also in cases where there are small differences,		Alternatively, and also in cases where there are small differences,
	the modem MAY adjust the values sent in Credit Window Grant Data Items		the modem <bcp14>MAY</bcp14> adjust the values sent in Credit Window Gra nt Data Items
	to account for the reported Credit Window.		to account for the reported Credit Window.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-di-request" numbered="true">		<section anchor="sec-di-request" numbered="true">
	<name>Credit Window Request</name>		<name>Credit Window Request</name>
	<t>		<t>
	The Credit Window Request Data Item is used by a router to		The Credit Window Request Data Item is used by a router to
	request additional credits for particular credit windows. Credit		request additional credits for particular credit windows. Credit
	Window Request Data Items are carried in Credit Control Messages, and		Window Request Data Items are carried in Credit Control Messages, and
	one or more Credit Window Request Data Items MAY be present in a		one or more Credit Window Request Data Items <bcp14>MAY</bcp14> be prese nt in a
	message.		message.
	</t>		</t>
	<t>		<t>
	Credit windows are identified using a FID as defined in <xref target="se		Credit windows are identified using a FID as defined in <xref target="se
	c-di-cwi" format="default"/>. Multiple FIDs MAY be present to allow for the		c-di-cwi" format="default"/>. Multiple FIDs <bcp14>MAY</bcp14> be present to al
	case where the router identifies that credits are needed in multiple		low for the
			case where the router determines that credits are needed in multiple
	credit windows. A special FID value, as defined below, is used to		credit windows. A special FID value, as defined below, is used to
	indicate that a credit request is being made across all queues.		indicate that a credit request is being made across all queues.
			<!-- [rfced] Section 2.3.5: Should "credit request" be "credit
			window request" as used generally elsewhere in the text? We don't
			see "credit request" used anywhere else in this document or group of
			documents (Cluster 541 /
			https://www.rfc-editor.org/cluster_info.php?cid=C541).
			Original:
			A special FID value, as defined below, is used to
			indicate that a credit request is being made across all queues. -->
	</t>		</t>
	<t>		<t>
	The format of the Credit Window Request Data Item is:		The format of the Credit Window Request Data Item is as follows:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flow Identifier (FID) [1] | Flow Identifier (FID) [2] |		| Flow Identifier (FID) [1] | Flow Identifier (FID) [2] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ... | Flow Identifier (FID) [n] |		| ... | Flow Identifier (FID) [n] |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>		]]></artwork>
	<dl newline="true" spacing="normal">		<dl newline="true" spacing="normal">
	<dt>Data Item Type:</dt>		<dt>Data Item Type:</dt>
	<dd>Data Item Type (TBA8)</dd>		<dd>34</dd>
	<dt>Length:</dt>		<dt>Length:</dt>
	<dd>		<dd>
	<t>Variable</t>		<t>Variable</t>
	<t>		<t>
	As specified in <xref target="RFC8175"/>, Length is the number		As specified in <xref target="RFC8175"/>, Length is the number
	of octets in the Data Item, excluding the Type and Length		of octets in the Data Item, excluding the Type and Length
	fields. It is equal to the number of FID fields carried in		fields. It is equal to the number of FID fields carried in
	the Data Item times 2 and MUST be at least 2. If it is less		the Data Item times 2 and <bcp14>MUST</bcp14> be at least 2. If it is
	than 2, the Data Item is corrupt so the message in which it		less
			than 2, the Data Item is corrupt, so the message in which it
	appears cannot be reliably parsed and is ignored.		appears cannot be reliably parsed and is ignored.
			<!-- [rfced] Section 2.3.5: We do not see a Type field in RFC 8175,
			but we see a "Data Item Type" field. May we update as suggested
			(per Section 11.3 ("DLEP Generic Data Item") of RFC 8175), to
			distinguish this definition from the definitions of Length in
			Sections 11.1 ("DLEP Signal Header") and 11.2 ("DLEP Message Header")
			of RFC 8175, which do not mention excluding a "Type" field?
			Original:
			As specified in [RFC8175], Length is the number of octets in the
			Data Item, excluding the Type and Length fields.
			Suggested:
			As specified in [RFC8175], Length is the number of octets in the
			Data Item, excluding the Data Item Type and Length fields. -->
	</t>		</t>
	</dd>		</dd>
	<dt>Flow Identifier (FID):</dt>		<dt>Flow Identifier (FID):</dt>
	<dd>		<dd>
	A two-octet flow identifier as defined by the Traffic		A 2-octet flow identifier as defined by the Traffic
	Classification Data Item. The FID also uniquely identifies		Classification Data Item. The FID also uniquely identifies
	a credit window. The special value of 0xFFFF indicates that		a credit window. The special value 0xFFFF indicates that
	the request applies to all FIDs. When this special value is		the request applies to all FIDs. When this special value is
	included, all other FID values included in the Data Item are		included, all other FID values included in the Data Item are
	redundant as the special value indicates all FIDs.		redundant, as the special value indicates all FIDs.
	</dd>		</dd>
	</dl>		</dl>
	<t>		<t>
	A modem receiving this Data Item MUST provide a Credit Increment for		A modem receiving this Data Item <bcp14>MUST</bcp14> provide a credit wi ndow 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 <bcp14>SHOULD</bcp14> be combined into a single Credit Control M
	possible. Unknown FID values SHOULD be logged and then		essage when
			possible. Unknown FID values <bcp14>SHOULD</bcp14> be logged and then
	ignored by the modem.		ignored by the modem.
	The method of logging is left to the modem implementation.		The method of logging is left to the modem implementation.
			<!-- [rfced] Section 2.3.5: We changed "Credit Increment" to "credit
			window increment" here, as we could not find the initial-capitalized
			form elsewhere in this document, in the group (cluster) of related
			documents, or in any published RFC to date. This update is also in
			line with this sentence from Section 2.2.1:
			A modem receiving this
			message MUST respond with a Credit Control Response Message based on
			the received message and Data Item and the processing defined in
			Section 2.2.2, which will typically result in credit window
			increments being provided.
			Please let us know any objections.
			Original:
			A modem receiving this Data Item MUST provide a Credit Increment for
			the indicated credit windows via Credit Window Grant Data Items
			carried in a new Credit Control Message.
			Currently:
			A modem receiving this Data Item MUST provide a credit window
			increment for the indicated credit windows via Credit Window Grant
			Data Items carried in a new Credit Control Message. -->
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-mgmnt" numbered="true">		<section anchor="sec-mgmnt" numbered="true">
	<name>Management Considerations</name>		<name>Management Considerations</name>
	<t>		<t>
	This section provides several network management guidelines		This section provides several network management guidelines
	to implementations supporting the credit window mechanisms defined		for implementations supporting the credit window mechanisms defined
	in this document.		in this document.
	</t>		</t>
	<t>		<t>
	Modems MAY support the configuration of the number of credit		Modems <bcp14>MAY</bcp14> support the configuration of the number of credi t
	windows (queues) to advertise to a router.		windows (queues) to advertise to a router.
	</t>		</t>
	<t>		<t>
	Routers may have limits on the number of queues that they can		Routers may have limits on the number of queues that they can
	support. They may even have limits on supported credit window		support. They may even have limits on supported credit window
	combinations. For example, per destination queues may not be		combinations. For example, per-destination queues may not be
	supported at all. When modem-provided credit window information		supported at all. When credit window information provided by a
	exceeds the capabilities of a router, the router SHOULD use a subset of		modem exceeds the capabilities of a router, the router <bcp14>SHOULD</bcp1
	the provided credit windows. Alternatively, a router MAY reset the		4> use a subset of
			the provided credit windows. Alternatively, a router <bcp14>MAY</bcp14> r
			eset the
	session and indicate that the extension is not supported. In either		session and indicate that the extension is not supported. In either
	case, the mismatch of capabilities SHOULD be reported to the user via		case, any mismatch in capabilities <bcp14>SHOULD</bcp14> be reported to th e user via
	normal network management mechanisms, such as the user interface		normal network management mechanisms, such as the user interface
	or error logging.		or error logging.
			<!-- [rfced] Section 2.4: We changed "the mismatch of capabilities"
			to "any mismatch in capabilities" per
			draft-ietf-manet-dlep-ether-credit-extension. Please let us know any
			objections.
			Original:
			In
			either case, the mismatch of capabilities SHOULD be reported to the
			user via normal network management mechanisms, such as the user
			interface or error logging.
			Currently:
			In
			either case, any mismatch in capabilities SHOULD be reported to the
			user via normal network management mechanisms, such as the user
			interface or error logging. -->
	</t>		</t>
	<t>		<t>
	In all cases, if credit windows are in use, traffic for which credits are not		In all cases, if credit windows are in use, traffic for which credits are not
	available MUST NOT be sent to the modem by the router.		available <bcp14>MUST NOT</bcp14> be sent to the modem by the router.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-compat" numbered="true">		<section anchor="sec-compat" numbered="true">
	<name>Compatibility</name>		<name>Compatibility</name>
	<t>		<t>
	The messages and Data Items defined in this document will only be used when		The messages and Data Items defined in this document will only be used when
	extensions require their use.		extensions require their use.
	</t>		</t>
	<t>		<t>
	The DLEP specification <xref target="RFC8175" format="default"/> defines han dling of unexpected		The DLEP specification <xref target="RFC8175" format="default"/> defines the handling of unexpected
	appearances of any Data Items, including those defined in this		appearances of any Data Items, including those defined in this
	document.		document.
	</t>		</t>
	</section>		</section>
	<section anchor="sec-sec" numbered="true">		<section anchor="sec-sec" numbered="true">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	This document introduces credit window control and flow mechanisms		This document introduces credit window control and flow mechanisms
	to DLEP. These mechanisms expose vulnerabilities similar to existing		for DLEP. These mechanisms expose vulnerabilities similar to existing
	DLEP messages.		DLEP messages.
	An example of a threat to which flow control might be susceptible is		An example of a threat to which flow control might be susceptible is where
	a malicious actor masquerading as a DLEP peer could inject a Credit		a malicious actor masquerading as a DLEP peer could inject a Credit
	Window Initialization Data Item, which resizes a credit window to		Window Initialization Data Item that resizes a credit window to
	a value that results in a denial of service.		a value that results in a denial of service.
	Other possible threats are given in the Security Considerations of		Other possible threats are discussed in the Security Considerations section
	<xref target="RFC8175" format="default"/> and are also applicable to,		of
	but not specific to, flow control.		<xref target="RFC8175" format="default"/> and are also applicable,
	The transport layer security mechanisms documented in		but not specific, to flow control.
			The transport-layer security mechanisms documented in
	<xref target="RFC8175" format="default"/>, with some updated		<xref target="RFC8175" format="default"/>, with some updated
	references to external documents listed below, can be applied to		references to external documents listed below, can be applied to
	this document.		this document.
	Implementations following the "networked deployment" model described		Implementations following the "networked deployment" model described
	in the "Implementation Scenarios" of		in Section&nbsp;<xref target="RFC8175" section="4"
	<xref target="RFC8175" format="default"/> SHOULD refer to		sectionFormat="bare">"Implementation Scenarios"</xref> of <xref target="RFC8175"
			/>
			<bcp14>SHOULD</bcp14> refer to
	<xref target="BCP195" format="default"/> for additional details.		<xref target="BCP195" format="default"/> for additional details.
	The Layer 2 security mechanisms documented in		The Layer 2 security mechanisms documented in
	<xref target="RFC8175" format="default"/> can also, with some updates,		<xref target="RFC8175" format="default"/> can also, with some updates,
	be applied to the mechanism defined in this document.		be applied to the mechanisms defined in this document.
	Examples of technologies that can be deployed to secure the Layer		Examples of technologies that can be deployed to secure the Layer
	2 link include <xref target="IEEE-802.1AE"/> and <xref target="IEEE-8802-1X" />.		2 link include <xref target="IEEE-802.1AE"/> and <xref target="IEEE-8802-1X" />.
			<!-- [rfced] Section 4: We had trouble following "some updated
			references to external documents listed below" in this paragraph.
			It appears that "external documents" is intended to refer to
			[BCP195], [IEEE-802.1AE], and [IEEE-8802-1X].
			However, we see that [RFC8175] cites [IEEE-802.1X] ("IEEE Standards
			for Local and metropolitan area networks-Port-Based Network Access
			Control"), but this document cites [IEEE-8802-1X] ("IEEE/ISO/IEC
			International Standard-Telecommunications and exchange between
			information technology systems-Requirements for local and
			metropolitan area networks-Part 1X:Port-based network access
			control").
			May we update as suggested? If not, please clarify the text.
			Original:
			The transport layer security mechanisms documented in [RFC8175], with
			some updated references to external documents listed below, can be
			applied to this document.
			Suggested:
			The transport layer security mechanisms documented in [RFC8175],
			along with the latest versions of [BCP195], [IEEE-802.1AE], and
			[IEEE-8802-1X] at the time of this writing, can be applied to this
			document. -->
	</t>		</t>
	</section>		</section>
	<section anchor="sec-iana" numbered="true">		<section anchor="sec-iana" numbered="true">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>
	This document requests the assignment of several values by IANA. All
	assignments are to registries defined by <xref target="RFC8175" format="defa
	ult"/>.
	</t>
	<section anchor="sec-iana-msg" numbered="true">		<section anchor="sec-iana-msg" numbered="true">
	<name>Message Type Values</name>		<name>Message Type Values</name>
	<t>		<t>
	This document requests 2 new assignments to the DLEP Message Registry		IANA has assigned two new values from the "Specification Required" range <
	named "Message Values" in the range with the "Specification Required"		xref target="RFC8126"/> in the DLEP "Message Type Values" registry:
	policy. The requested values are as follows:
	</t>		</t>
	<t keepWithNext="true"/>
	<table anchor="table_msg" align="center">		<table anchor="table_msg" align="center">
	<name>Requested Message Type Values</name>		<name>Message Type Values</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Type Code</th>		<th align="left">Type Code</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">TBA2</td>		<td align="left">17</td>
	<td align="left">Credit Control</td>		<td align="left">Credit Control</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">TBA3</td>		<td align="left">18</td>
	<td align="left">Credit Control Response</td>		<td align="left">Credit Control Response</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t keepWithPrevious="true"/>
	</section>		</section>
	<section anchor="sec-iana-di" numbered="true" toc="default">		<section anchor="sec-iana-di" numbered="true" toc="default">
	<name>Data Item Values</name>		<name>Data Item Values</name>
	<t>		<t>
	This document requests the following new assignments to the DLEP Data Item		IANA has assigned the following values from the "Specification Required" r
	Registry named "Data Item Type Values" in the range with the "Specificatio		ange <xref target="RFC8126"/> in the DLEP "Data Item Type Values" registry:
	n
	Required" policy. The requested values are as follows:
	</t>		</t>
	<t keepWithNext="true"/>
	<table anchor="table_di" align="center">		<table anchor="table_di" align="center">
	<name>Requested Data Item Values</name>		<name>Data Item Values</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Type Code</th>		<th align="left">Type Code</th>
	<th align="left">Description</th>		<th align="left">Description</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">TBA4</td>		<td align="left">30</td>
	<td align="left">Credit Window Initialization</td>		<td align="left">Credit Window Initialization</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">TBA5</td>		<td align="left">31</td>
	<td align="left">Credit Window Association</td>		<td align="left">Credit Window Association</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">TBA6</td>		<td align="left">32</td>
	<td align="left">Credit Window Grant</td>		<td align="left">Credit Window Grant</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">TBA7</td>		<td align="left">33</td>
	<td align="left">Credit Window Status</td>		<td align="left">Credit Window Status</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">TBA8</td>		<td align="left">34</td>
	<td align="left">Credit Window Request</td>		<td align="left">Credit Window Request</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t keepWithPrevious="true"/>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-manet-credit-window" to="Credit-Window-Extens
			ion"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 175.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 175.xml"/>
	<reference anchor="I-D.ietf-manet-dlep-traffic-classification"
	target="https://datatracker.ietf.org/doc/draft-ietf-manet-dle		<!-- draft-ietf-manet-dlep-traffic-classification (RFC 9892) -->
	p-traffic-classification">		<reference anchor="RFC9892" target="https://www.rfc-editor.org/info/rfc9
			892">
	<front>		<front>
	<title>Dynamic Link Exchange Protocol (DLEP) Traffic		<title>Dynamic Link Exchange Protocol (DLEP) Traffic Classification
	Classification Data Item</title>		Data Item</title>
	<author fullname="Bow-Nan Cheng" initials="B."		<author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">
	surname="Cheng">		<organization>MIT Lincoln Laboratory</organization>
	<organization>MIT Lincoln Laboratory</organization>		</author>
	</author>		<author initials="D." surname="Wiggins" fullname="David Wiggins">
	<author fullname="David Wiggins" initials="D."		</author>
	surname="Wiggins"/>		<author initials="L." surname="Berger" fullname="Lou Berger">
	<author fullname="Lou Berger" initials="L." surname="Berger">		<organization>LabN Consulting, L.L.C.</organization>
	<organization>LabN Consulting, L.L.C.</organization>		</author>
	</author>		<author initials="D." surname="Fedyk" fullname="Don Fedyk" role="edi
	<author fullname="Don Fedyk" initials="D." surname="Fedyk">		tor">
	<organization>LabN Consulting, L.L.C.</organization>		<organization>LabN Consulting, L.L.C.</organization>
	</author>		</author>
	<date day="19" month="November" year="2024"/>		<date month='November' year='2025'/>
	</front>		</front>
	<seriesInfo name="Internet-Draft"		<seriesInfo name="RFC" value="9892"/>
	value="draft-ietf-manet-dlep-traffic-classification"/>		<seriesInfo name="DOI" value="10.17487/RFC9892"/>
	</reference>		</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="I-D.ietf-manet-dlep-da-credit-extension"
	target="https://datatracker.ietf.org/doc/draft-ietf-manet-dlep
	-da-credit-extension/">
	<front>
	<title>DLEP DiffServ Aware Credit Window Extension</title>
	<author fullname="Bow-Nan Cheng" initials="B."
	surname="Cheng">
	<organization>MIT Lincoln Laboratory</organization>
	</author>
	<author fullname="David Wiggins" initials="D."
	surname="Wiggins"/>
	<author fullname="Lou Berger" initials="L."
	surname="Berger">
	<organization>LabN Consulting, L.L.C.</organization>
	</author>
	<author fullname="Donald E. Eastlake 3rd" initials="D. E."
	surname="Eastlake">
	<organization>Independent</organization>
	</author>
	<date day="15" month="December" year="2024"/>
	</front>
	<seriesInfo name="Internet-Draft"
	value="draft-ietf-manet-dlep-da-credit-extension"/>
	</reference>
	<reference anchor="I-D.ietf-manet-dlep-ether-credit-extension"
	target="https://datatracker.ietf.org/doc/draft-ietf-manet-dlep
	-ether-credit-extension/">
	<front>
	<title>DLEP IEEE 802.1Q Aware Credit Window
	Extension</title>
	<author fullname="David Wiggins" initials="D."
	surname="Wiggins"/>
	<author fullname="Lou Berger" initials="L."
	surname="Berger">
	<organization>LabN Consulting, L.L.C.</organization>
	</author>		<!-- draft-ietf-manet-dlep-da-credit-extension-21 (RFC 9894) -->
	<author fullname="Donald E. Eastlake 3rd" initials="D. E."		<reference anchor="RFC9894" target="https://www.rfc-editor.org/info/rfc9894">
	surname="Eastlake">		<front>
	<organization>Independent</organization>		<title>Dynamic Link Exchange Protocol (DLEP) Diffserv Aware Credit Window
	</author>		Extension</title>
	<date day="15" month="December" year="2024"/>		<author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">
	</front>		<organization>MIT Lincoln Laboratory</organization>
	<seriesInfo name="Internet-Draft"		</author>
	value="draft-ietf-manet-dlep-ether-credit-extension"/>		<author initials="D." surname="Wiggins" fullname="David Wiggins">
	</reference>		</author>
			<author initials="L." surname="Berger" fullname="Lou Berger">
			<organization>LabN Consulting, L.L.C.</organization>
			</author>
			<author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake
			3rd" role="editor">
			<organization>Independent</organization>
			</author>
			<date month="November" year="2025" />
			</front>
			<seriesInfo name="RFC" value="9894"/>
			<seriesInfo name="DOI" value="10.17487/RFC9894"/>
			</reference>
			<!-- draft-ietf-manet-dlep-ether-credit-extension-09 (RFC 9895) -->
			<reference anchor="RFC9895" target="https://www.rfc-editor.org/info/rfc9895">
			<front>
			<title>Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Wind
			ow Extension</title>
			<author initials="D." surname="Wiggins" fullname="David Wiggins">
			</author>
			<author initials="L." surname="Berger" fullname="Lou Berger">
			<organization>LabN Consulting, L.L.C.</organization>
			</author>
			<author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake
			3rd" role="editor">
			<organization>Independent</organization>
			</author>
			<date month="November" year="2025" />
			</front>
			<seriesInfo name="RFC" value="9895"/>
			<seriesInfo name="DOI" value="10.17487/RFC9895"/>
			</reference>
			<!-- draft-ietf-manet-credit-window-07 (Expired) -->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-manet-credit-window.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-manet-credit-window.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 475.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 475.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 651.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 651.xml"/>
	<referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/b		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	cp195">		126.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
	.9325.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC		0195.xml"/>
	.8996.xml"/>
	</referencegroup>
	<reference anchor="IEEE-802.1AE" target="https://ieeexplore.ieee.org/docu ment/8585421">		<reference anchor="IEEE-802.1AE" target="https://ieeexplore.ieee.org/docu ment/8585421">
	<front>		<front>
	<title>IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security Amendment 4: MAC Privacy protection</title>		<title>IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security Amendment 4: MAC Privacy protection</title>
	<author/>		<author>
			<organization>IEEE</organization>
			</author>
			<date month="December" year="2018"/>
	</front>		</front>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
	</reference>		</reference>
	<reference anchor="IEEE-8802-1X" target="https://ieeexplore.ieee.org/docu
	ment/9650828">		<!-- [rfced] [IEEE-802.1AE]: The title listed here does not match
	<front>		the title found at the provided URL. Is the intent here to
	<title>8802-1X-2021 - IEEE/ISO/IEC International Standard-Telecommu		specifically point to Amendment 4 (in which case the citation string
	nications and exchange between information technology systems--Requirements for		should be changed to [IEEE-802.1AEdk-2023] and the URL should be
	local and metropolitan area networks--Part 1X:Port-based network access control<		changed to <https://ieeexplore.ieee.org/document/10225636>), or would
	/title>		you prefer to list [IEEE-802.1AE] per
	<author/>		draft-ietf-manet-dlep-traffic-classification-17?
			Original:
			[IEEE-802.1AE]
			"IEEE Standard for Local and metropolitan area networks-
			Media Access Control (MAC) Security Amendment 4: MAC
			Privacy protection",
			<https://ieeexplore.ieee.org/document/8585421>.
			As listed in the edited copy of
			draft-ietf-manet-dlep-traffic-classification-17:
			[IEEE-802.1AE]
			IEEE, "IEEE Standard for Local and metropolitan area
			networks-Media Access Control (MAC) Security",
			DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018,
			December 2018,
			<https://ieeexplore.ieee.org/document/8585421>. -->
			<!-- [LB]: If authors don't want to list the 802.1AE amendment after
			all, pull the 802.1AE listing from
			draft-ietf-manet-dlep-traffic-classification-17.xml-->
			<reference anchor="IEEE-8802-1X" target="https://ieeexplore.ieee.org/doc
			ument/9650828">
			<front>
			<title>IEEE/ISO/IEC International Standard-Telecommunications and
			exchange between information technology systems--Requirements for local and metr
			opolitan area networks--Part 1X:Port-based network access control</title>
			<author>
			<organization>IEEE</organization>
			</author>
			<date month="December" year="2021"/>
	</front>		</front>
			<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9650828"/>
			<seriesInfo name="IEEE Std" value="8802-1X-2021"/>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section numbered="true">		<section anchor="Tree" numbered="true" toc="default">
	<name>Acknowledgments</name>
	<t>
	We mourn the loss of Stan Ratliff who passed away on October 22,
	2019. His guidance, leadership and personal contributions were
	critical in the development of this work and DLEP as a whole. His
	leadership and friendship shall be missed.
	</t>
	<t>
	We had the honor of working too briefly with David Wiggins on this
	and related DLEP work. His contribution to the IETF and publication
	of the first and definitive open source DLEP implementation have
	been critical to the acceptance of DLEP. We morn his passing on
	November 23, 2023. We wish to recognize his guidance, leadership
	and professional excellence. We were fortunate to benefit from his
	leadership and friendship. He shall be missed.
	</t>
	<t>
	Many useful comments were
	received from contributors to the MANET working group, notably Rick
	Taylor, Ronald in't Velt, David Black and Donald E. Eastlake.
	This
	document was derived from <xref target="I-D.ietf-manet-dlep-da-credit-exten
	sion" format="default"/> as a result of
	discussions at IETF 101.
	</t>
	</section>
	<section anchor="Tree" numbered="true" toc="default">
	<name>Example DLEP Credit Flow Control and Traffic Classification Data Ite m Exchange</name>		<name>Example DLEP Credit Flow Control and Traffic Classification Data Ite m Exchange</name>
	<t>		<t>
	Below <xref target="dlep-exchange" format="default"/> illustrates		<xref target="dlep-exchange" format="default"/> illustrates
	a credit flow control and traffic classification exchange between		a credit flow control and traffic classification exchange between
	a Router and a Modem.		a router and a modem.
	The Modem will initialize a number of queues with Credit Window		The modem will initialize a number of queues with Credit Window
	Initialization Data Items, Window Association Data Item(s)		Initialization Data Items, Credit Window Association Data Item(s),
	and Traffic Classification Item(s) included in DLEP messages as		and Traffic Classification Data Item(s) included in DLEP messages as
	outlined in this document.		outlined in this document.
	If the Data Items are successfully validated, traffic is mapped		If the Data Items are successfully validated, traffic is mapped
	to the corresponding credit window on the router and forwarded		to the corresponding credit window on the router and forwarded
	when there are sufficient credits.		when there are sufficient credits.
	Routers can periodically report the status of the credit window.		Routers can periodically report the status of the credit window.
	Modems will send periodic updates with more credits as packets are		Modems will send periodic updates with more credits as packets are
	transmitted. Routers may request more credits for a particular		transmitted. If a router requires more credits for a particular window,
	window if the router requires more credits.		it may request them.
			This document defines credit window flow information for FIDs
			that map to the queues.
			<xref target="RFC9892" format="default"/>
			defines the Traffic Classification Sub-Data Items, such as DSCPs,
			that map to the FIDs.
			<!-- [rfced] Appendix B: We changed "traffic classification data sub
			items" to "Traffic Classification Sub-Data Items" per
			draft-ietf-manet-dlep-traffic-classification and the rest of this
			group (Cluster 541 /
			https://www.rfc-editor.org/cluster_info.php?cid=C541) of documents.
			Please let us know any objections.
			Original:
			[I-D.ietf-manet-dlep-traffic-classification] defines the traffic
			classification data sub items such as DiffServ code points that map
			to the FIDs.
			Currently:
			[RFC9892] defines the Traffic
			Classification Sub-Data Items, such as DSCPs, that map to the FIDs. -->
	This document defines window credit flow information for flow
	Identifiers (FIDs) that map to the queues.
	<xref target="I-D.ietf-manet-dlep-traffic-classification" format="defaul
	t"/>
	defines the traffic classification data sub items such as DiffServ
	code points that map to the FIDs.
	</t>		</t>
	<figure anchor="dlep-exchange" align="left" suppress-title="false">		<figure anchor="dlep-exchange" align="left">
	<name slugifiedName="dlep_exchange">Example DLEP Traffic Classification		<name>Example DLEP Traffic Classification / Credit Flow Exchange</name>
	/Credit Flow Exchange</name>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<artwork name="" type="" align="center" alt=""><![CDATA[
	Router Modem		Router Modem
	|<----------------DLEP Messages---------------|		|<----------------DLEP Messages---------------|
	| Traffic Classification Data Item(s) |		| Traffic Classification Data Item(s) |
	| Window Association Data Item(s) |		| Credit Window Association Data Item(s) |
	| Credit Window Initialization Data Item(s) |		| Credit Window Initialization Data Item(s) |
	| |		| |
	|============================================>|		|============================================>|
	| Traffic |		| Traffic |
	| |		| |
	|<----------------DLEP Messages---------------|		|<----------------DLEP Messages---------------|
	| Credit Window Grant Data Item(s) | T		| Credit Window Grant Data Item(s) | T
	|============================================>| i		|============================================>| i
	| Traffic | m		| Traffic | m
	| | e		| | e
	skipping to change at line 1252 ¶		skipping to change at line 1575 ¶
	|<------------------------------------------- |		|<------------------------------------------- |
	| Credit Window Grant Data Item(s) |		| Credit Window Grant Data Item(s) |
	| |		| |
	|============================================>|		|============================================>|
	| Traffic |		| Traffic |
	| |		| |
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	</section>		</section>
			<section numbered="false">
			<name>Acknowledgments</name>
			<t>
			We mourn the loss of <contact fullname="Stan Ratliff"/>, who passed away on
			October 22,
			2019. His guidance, leadership, and personal contributions were
			critical in the development of this work and DLEP as a whole. His
			leadership and friendship shall be missed.
			</t>
			<t>
			We had the honor of working too briefly with <contact fullname="David Wiggi
			ns"/> on this
			and related DLEP work. His contribution to the IETF and publication
			of the first and definitive open-source DLEP implementation have
			been critical to the acceptance of DLEP. We mourn his passing on
			November 26, 2023. We wish to recognize his guidance, leadership,
			and professional excellence. We were fortunate to benefit from his
			leadership and friendship. He shall be missed.
			</t>
			<t>
			Many useful comments were
			received from contributors to the MANET Working Group, notably <contact ful
			lname="Rick
			Taylor"/>, <contact fullname="Ronald in 't Velt"/>, <contact fullname="Davi
			d Black"/>, and <contact fullname="Donald E.&nbsp;Eastlake"/>.
			This
			document was derived from <xref target="RFC9894" format="default"/> as a re
			sult of
			discussions at IETF 101.
			</t>
			</section>
	</back>		</back>
			<!-- [rfced] Please review the "Inclusive Language" portion of the
			online Style Guide at
			<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
			and let us know if any changes are needed. Updates of this nature
			typically result in more precise language, which is helpful for
			readers.
			Note that our script did not flag any words in particular, but this
			should still be reviewed as a best practice. -->
			<!-- [rfced] Please let us know if any changes are needed for the
			following:
			a) The following terms were used inconsistently in this document.
			We chose to use the latter forms. Please let us know any objections.
			Additional Credit (field name, i.e., "Additional Credit:") /
			Additional Credits ("Additional Credits field")
			credit based flow control / credit-based flow control (added hyphen)
			Credit-Based Flow Control (in text) / credit-based flow control
			Credit Control message (2 instances) / Credit Control Message
			Credit Control Response message (1 instance) /
			Credit Control Response Message
			Credit Window size (1 instance, i.e., "a Credit Window size") /
			credit window size (7 instances, e.g., "an initial credit window
			size") (used generally throughout Section 2)
			data item / Data Item (per the rest of this document and per this
			group (cluster) of documents)
			different Credit windows / different credit windows
			Messages / messages ("common Messages", "No messages")
			(We changed "common Messages" to "common messages".)
			Window Association Data Item (2 instances in Appendix B) /
			Credit Window Association Data Item (10 instances in text,
			the table entry in the IANA Considerations section, and
			<https://www.iana.org/assignments/dlep-parameters/>)
			b) The following terms appear to be used inconsistently in this
			document. Please let us know which form is preferred.
			Credit Window / credit window (used generally, e.g., "associated
			Credit Window", "associated credit window",
			'logical "Credit Window(s)s"')
			(Note: We also see 'logical "Credit Windows"' in
			draft-ietf-manet-dlep-da-credit-extension. Otherwise, all of the
			documents in this group of documents use the lowercase form
			"credit window" when used generally.)
			c) Please let us know how/if the following should be made consistent:
			Credit Grant Data Item (3 instances in text) /
			Credit Window Grant Data Item (~13 instances in text) /
			Grant Data Item (2 instances in text) ("each Grant Data Item",
			"or Grant Data Item")
			Suggested, assuming that these different forms all refer to the
			same type of Data Item: Credit Window Grant Data Item, per
			<https://www.iana.org/assignments/dlep-parameters/>.
			Alternatively, please let us know if the IANA entry needs to
			be changed (e.g., from "Credit Window Grant" to "Credit Grant"
			or simply "Grant", noting that any such change would not match
			the format of the other entries on the page.) -->
	</rfc>		</rfc>
End of changes. 216 change blocks.
	458 lines changed or deleted		919 lines changed or added
This html diff was produced by rfcdiff 1.48.