rfc9892v1.txt   rfc9892.txt 
skipping to change at line 21 skipping to change at line 21
Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item
Abstract Abstract
This document defines a new Data Item for the Dynamic Link Exchange This document defines a new Data Item for the Dynamic Link Exchange
Protocol (DLEP) to support traffic classification. Traffic Protocol (DLEP) to support traffic classification. Traffic
classification information identifies traffic flows based on frame/ classification information identifies traffic flows based on frame/
packet content such as a destination address. The Data Item is packet content such as a destination address. The Data Item is
defined in an extensible and reusable fashion. Its use will be defined in an extensible and reusable fashion. Its use will be
mandated in other documents defining specific DLEP extensions. This mandated in other documents defining specific DLEP extensions. This
document also introduces DLEP Sub-Data Items; Sub-Data Items are document also introduces DLEP Sub-Data Items and defines two new Sub-
defined to support Diffserv and Ethernet traffic classification. Data Items to support Diffserv and Ethernet traffic classification.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 69 skipping to change at line 69
2.1.1. Traffic Classification Sub-Data Item 2.1.1. Traffic Classification Sub-Data Item
2.2. Diffserv Traffic Classification Sub-Data Item 2.2. Diffserv Traffic Classification Sub-Data Item
2.2.1. Router Receive Processing 2.2.1. Router Receive Processing
2.3. Ethernet Traffic Classification Sub-Data Item 2.3. Ethernet Traffic Classification Sub-Data Item
2.3.1. Router Receive Processing 2.3.1. Router Receive Processing
3. Compatibility 3. Compatibility
4. Security Considerations 4. Security Considerations
5. IANA Considerations 5. IANA Considerations
5.1. Data Item Type Values 5.1. Data Item Type Values
5.2. Traffic Classification Sub-Data Item Type Values 5.2. Traffic Classification Sub-Data Item Type Values
5.3. Registration Guidance
6. References 6. References
6.1. Normative References 6.1. Normative References
6.2. Informative References 6.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
This protocol provides the exchange of link-related control This protocol provides the exchange of link-related control
skipping to change at line 101 skipping to change at line 102
classification, see Section 2.3 of [RFC2475].) The Data Item is classification, see Section 2.3 of [RFC2475].) The Data Item is
structured to allow for the use of the defined traffic classification structured to allow for the use of the defined traffic classification
information with applications such as credit window control as information with applications such as credit window control as
specified in [RFC9893]. [RFC9893] provides an example of combining specified in [RFC9893]. [RFC9893] provides an example of combining
traffic classification and credit window flow control. traffic classification and credit window flow control.
This document defines traffic classification based on a DLEP This document defines traffic classification based on a DLEP
destination and flows identified by either Differentiated Services destination and flows identified by either Differentiated Services
Code Points (DSCPs) [RFC2475] or IEEE 802.1Q Ethernet Priority Code Code Points (DSCPs) [RFC2475] or IEEE 802.1Q Ethernet Priority Code
Points (PCPs) [IEEE8021Q]. The defined mechanism allows for flows to Points (PCPs) [IEEE8021Q]. The defined mechanism allows for flows to
be described in a flexible fashion and when combined with be described in a flexible fashion and, when combined with
applications such as credit window control, allows credit windows to applications such as credit window control, allows credit windows to
be shared across traffic sent to multiple DLEP destinations and as be (1) shared across traffic sent to multiple DLEP destinations and
part of multiple flows, or used exclusively for traffic sent to a as part of multiple flows or (2) used exclusively for traffic sent to
particular destination and/or belonging to a particular flow. The a particular destination and/or belonging to a particular flow. The
extension also supports the "wildcard" matching of any flow (DSCP or extension also supports the "wildcard" matching of any flow (DSCP or
PCP). Traffic classification information is provided such that it PCP). Traffic classification information is provided such that it
can be readily extended to support other traffic classification can be readily extended to support other traffic classification
techniques or can be used by extensions that are not related to techniques or can be used by extensions that are not related to
credit windows, such as the extension defined in [RFC8651] or even credit windows, such as the extension defined in [RFC8651] or even
5-tuple IP flows. 5-tuple IP flows.
This document defines support for traffic classification using a This document defines support for traffic classification using a
single new Data Item (see Section 2.1) for general support. Two new single new Data Item (see Section 2.1) for general support and
Sub-Data Items are defined to support identification of flows based defines two new Sub-Data Items to support identification of flows
on DSCPs and PCPs. based on DSCPs and PCPs (see Sections 2.2 and 2.3).
1.1. Key Words 1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Traffic Classification 2. Traffic Classification
skipping to change at line 140 skipping to change at line 141
traffic sent from a router to a modem. The data plane information traffic sent from a router to a modem. The data plane information
used to identify each flow is represented in a separate Sub-Data used to identify each flow is represented in a separate Sub-Data
Item. The Data Item and Sub-Data Item structures are intended to be Item. The Data Item and Sub-Data Item structures are intended to be
independent of any specific usage of the flow identification, e.g., independent of any specific usage of the flow identification, e.g.,
flow control. The Sub-Data Item structure is also intended to allow flow control. The Sub-Data Item structure is also intended to allow
for future traffic classification types, e.g., 5-tuple flows. While for future traffic classification types, e.g., 5-tuple flows. While
the structure of the Data Items is extensible, actual flow the structure of the Data Items is extensible, actual flow
information is expected to be used in an extension-dependent manner. information is expected to be used in an extension-dependent manner.
Support for DSCP and PCP-based flows is defined via individual Sub- Support for DSCP and PCP-based flows is defined via individual Sub-
Data Items; see below. Other types of flow identification, e.g., Data Items; see below. Other types of flow identification, e.g.,
based on IP protocol and ports, may be defined in the future via new based on IP transport-layer protocol and ports, may be defined in the
Sub-Data Items. Note that when extensions supporting multiple Sub- future via new Sub-Data Items. Note that when extensions supporting
Data Item types are negotiated, these types MAY be combined in a multiple Sub-Data Item types are negotiated, these types MAY be
single Data Item. combined in a single Data Item.
Each list of flows is identified using a "Traffic Classification Each list of flows is identified using a "Traffic Classification
Identifier" or "TID" and is expected to represent a valid combination Identifier" or "TID" and is expected to represent a valid combination
of data plane identifiers that may be used at the same time. Each of data plane identifiers that may be used at the same time. Each
flow is identified via a "Flow Identifier" or "FID". Each FID is flow is identified via a "Flow Identifier" or "FID". Each FID is
defined in a Sub-Data Item that carries the data plane identifier or defined in a Sub-Data Item that carries the data plane identifier or
identifiers used to associate traffic with the flow. A DLEP identifiers used to associate traffic with the flow. A DLEP
destination address is also needed to complete traffic classification destination address is also needed to complete traffic classification
information used in extensions such as flow control. This information used in extensions such as flow control. This
information is expected to be provided in an extension-specific information is expected to be provided in an extension-specific
skipping to change at line 199 skipping to change at line 200
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Classification Sub-Data Item n ~ ~ Traffic Classification Sub-Data Item n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: Data Item Type:
29 29
Length: Length:
Variable Variable
Per [RFC8175], Length is the number of octets in the Data Item, Per Section 11.3 of [RFC8175], Length is the number of octets in
excluding the Type and Length fields. The length here is limited the Data Item, excluding the Data Item Type and Length fields.
by the packet data unit (PDU) length supported. For example, if The length here is limited by the packet data unit (PDU) length
the packet is limited to 1400 bytes, then the length MUST NOT supported. For example, if the packet is limited to 1400 bytes,
exceed this value. If larger packets are supported, the maximum then the length MUST NOT exceed this value. If larger packets are
MUST be adjusted to be smaller than or equal to the maximum PDU. supported, the maximum MUST be adjusted to be smaller than or
Multiple messages can be used if there is more data than will fit equal to the maximum PDU. Multiple messages can be used if there
in a single TLV. is more data than will fit in a single TLV.
Traffic Classification Identifier (TID): Traffic Classification Identifier (TID):
A 16-bit unsigned integer identifying a traffic classification A 16-bit unsigned integer identifying a traffic classification
set. There is no restriction on values used by a modem, and there set. There is no restriction on values used by a modem, and there
is no requirement for sequential or ordered values. is no requirement for sequential or ordered values.
Num SDIs: Num SDIs:
An 8-bit unsigned integer indicating the number of Traffic An 8-bit unsigned integer indicating the number of Traffic
Classification Sub-Data Items included in the Data Item. A value Classification Sub-Data Items included in the Data Item. A value
of zero (0) is allowed and indicates that no traffic should be of zero (0) is allowed and indicates that no traffic should be
skipping to change at line 274 skipping to change at line 275
Item Types are scoped within the Data Item in which they are Item Types are scoped within the Data Item in which they are
carried, i.e., the Sub-Data Item Type field MUST be used together carried, i.e., the Sub-Data Item Type field MUST be used together
with the Traffic Classification Data Item Type to identify the with the Traffic Classification Data Item Type to identify the
format of the Sub-Data Item. Traffic Classification Sub-Data Item format of the Sub-Data Item. Traffic Classification Sub-Data Item
Types are managed according to the IANA registry described in Types are managed according to the IANA registry described in
Section 5.2. Section 5.2.
Length: Length:
Variable Variable
Per [RFC8175], Length is a 16-bit unsigned integer that is the Per Section 11.3 of [RFC8175], Length is a 16-bit unsigned integer
number of octets in the Sub-Data Item, excluding the Type and that is the number of octets in the Sub-Data Item, excluding the
Length fields. The maximum length is limited on a per Sub-Data Data Item Type and Length fields. Each Sub-Data Item has its own
Item Type. Length field.
Value:
A field of <Length> octets that contains data specific to a
particular Data Item.
2.2. Diffserv Traffic Classification Sub-Data Item 2.2. Diffserv Traffic Classification Sub-Data Item
The Diffserv Traffic Classification Sub-Data Item identifies the set The Diffserv Traffic Classification Sub-Data Item identifies the set
of DSCPs that should be treated as a single flow, i.e., receive the of DSCPs that should be treated as a single flow, i.e., receive the
same traffic treatment. DSCPs are identified in a list of Diffserv same traffic treatment. DSCPs are identified in a list of Diffserv
fields. An implementation that does not support DSCPs and wants the fields. An implementation that does not support DSCPs and wants the
same traffic treatment for all traffic to a destination or same traffic treatment for all traffic to a destination or
destinations would indicate 0 DSCPs. destinations would indicate 0 DSCPs.
skipping to change at line 395 skipping to change at line 400
Traffic Classification Sub-Data Item Type in the format defined in Traffic Classification Sub-Data Item Type in the format defined in
Section 2.1.1. Section 2.1.1.
Length: Length:
Variable Variable
Length is defined above. For this Sub-Data Item, it is equal to Length is defined above. For this Sub-Data Item, it is equal to
four (4) plus the number of octets needed to accommodate the four (4) plus the number of octets needed to accommodate the
number of Priority fields indicated by the NumPCPs field. Note number of Priority fields indicated by the NumPCPs field. Note
that as the length is in octets and each Priority field is 4 bits, that as the length is in octets and each Priority field is 4 bits,
the additional length is the value carried in the NumPCPs field the total length of this Sub-Data Item is the 2 octets of Flow
divided by 2 and rounded up to the next higher integer quantity. Identifier, plus the 2 octets for NumPCPs and VLAN Identifier plus
This TLV has a maximum length of 4 plus 8 divided by 2 or 16 the number of octets for PCPs. The number of octets for the PCPs
octets. is computed by rounding up NumPCPs to the nearest even value and
dividing by 2. This TLV has maximum length of 4 plus 8 divided by
2 or 8 octets.
Flow Identifier (FID): Flow Identifier (FID):
A 16-bit unsigned integer representing the data plane information A 16-bit unsigned integer representing the data plane information
carried in the Sub-Data Item that is to be used in identifying a carried in the Sub-Data Item that is to be used in identifying a
flow. The value 0xFFFF is reserved and MUST NOT be used in this flow. The value 0xFFFF is reserved and MUST NOT be used in this
field. field.
Num PCPs: Num PCPs:
A 4-bit unsigned integer indicating the number of Priority fields A 4-bit unsigned integer indicating the number of Priority fields
carried in the Sub-Data Item. A zero (0) indicates a (wildcard) carried in the Sub-Data Item. A zero (0) indicates a (wildcard)
skipping to change at line 425 skipping to change at line 432
A 12-bit unsigned integer field indicating the VLAN to be used in A 12-bit unsigned integer field indicating the VLAN to be used in
traffic classification. A value of zero (0) indicates that the traffic classification. A value of zero (0) indicates that the
VID is to be ignored and any VID is to be accepted during traffic VID is to be ignored and any VID is to be accepted during traffic
classification. Any explicitly mapped VLANs are matched first. classification. Any explicitly mapped VLANs are matched first.
Any VLANs that do not have a mapping will then map to this default Any VLANs that do not have a mapping will then map to this default
mapping. mapping.
Priority: Priority:
Each Priority Field is 4 bits long and indicates a PCP field as Each Priority Field is 4 bits long and indicates a PCP field as
defined in [IEEE8021Q]. Note that zero (0) is a valid value for defined in [IEEE8021Q]. Note that zero (0) is a valid value for
either PCP. PCP.
0 1 2 3 0 1 2 3
+---+---+---+---+ +---+---+---+---+
| PCP |MBZ| | PCP |MBZ|
+---+---+---+---+ +---+---+---+---+
PCP: Priority Code Point [IEEE8021Q] PCP: Priority Code Point [IEEE8021Q]
MBZ: Must Be Zero - set to zero when transmitted MBZ: Must Be Zero - set to zero when transmitted
Pad: Pad:
skipping to change at line 488 skipping to change at line 495
for DLEP. These mechanisms expose vulnerabilities similar to for DLEP. These mechanisms expose vulnerabilities similar to
existing DLEP messages. An example of a threat to which traffic existing DLEP messages. An example of a threat to which traffic
classification might be susceptible is where a malicious actor classification might be susceptible is where a malicious actor
masquerading as a DLEP peer could inject an alternate Traffic masquerading as a DLEP peer could inject an alternate Traffic
Classification Data Item, changing the mapping of traffic to queues; Classification Data Item, changing the mapping of traffic to queues;
this would in turn cause delay, congestion, or loss in one or more this would in turn cause delay, congestion, or loss in one or more
service classes. Other possible threats are discussed in the service classes. Other possible threats are discussed in the
Security Considerations section of [RFC8175] and are also applicable, Security Considerations section of [RFC8175] and are also applicable,
but not specific, to traffic classification. but not specific, to traffic classification.
The transport-layer security mechanisms documented in [RFC8175], with The transport-layer security mechanisms documented in [RFC8175],
some updated references to external documents listed below, can be along with the latest versions of [BCP195], [IEEE-802.1AE], and
applied to this document. Implementations following the "networked [IEEE-802.1X] at the time of this writing, can be applied to this
deployment" model described in Section 4 ("Implementation Scenarios") document. Implementations following the "networked deployment" model
of [RFC8175] SHOULD refer to [BCP195] for additional details. The described in Section 4 ("Implementation Scenarios") of [RFC8175]
Layer 2 security mechanisms documented in [RFC8175] can also, with SHOULD refer to [BCP195] for additional details. The Layer 2
some updates, be applied to the mechanisms defined in this document. security mechanisms documented in [RFC8175] can also, with some
updates, be applied to the mechanisms defined in this document.
Examples of technologies that can be deployed to secure the Layer 2 Examples of technologies that can be deployed to secure the Layer 2
link include [IEEE-802.1AE] and [IEEE-8802-1X]. link include [IEEE-802.1AE] and [IEEE-802.1X].
5. IANA Considerations 5. IANA Considerations
5.1. Data Item Type Values 5.1. Data Item Type Values
IANA has assigned the following value from the "Specification IANA has assigned the following value from the "Specification
Required" range [RFC8126] in the DLEP "Data Item Type Values" Required" range [RFC8126] in the DLEP "Data Item Type Values"
registry: registry:
+===========+========================+ +===========+========================+
skipping to change at line 551 skipping to change at line 559
+-------------+---------------------------------+-------------+ +-------------+---------------------------------+-------------+
| 3-65407 | Unassigned | | | 3-65407 | Unassigned | |
+-------------+---------------------------------+-------------+ +-------------+---------------------------------+-------------+
| 65408-65534 | Reserved for Private Use | RFC 9892 | | 65408-65534 | Reserved for Private Use | RFC 9892 |
+-------------+---------------------------------+-------------+ +-------------+---------------------------------+-------------+
| 65535 | Reserved | RFC 9892 | | 65535 | Reserved | RFC 9892 |
+-------------+---------------------------------+-------------+ +-------------+---------------------------------+-------------+
Table 3: Initial Registry Contents Table 3: Initial Registry Contents
This section provides guidance for registrations in the "Traffic
Classification Sub-Data Item Type Values" registry.
This registry encompasses packet traffic classification, where This registry encompasses packet traffic classification, where
standard packet header identifiers in packets or data frames indicate standard packet header identifiers in packets or data frames indicate
Quality of Service (QoS) treatment. It includes two specific Quality of Service (QoS) treatment. It includes two specific entries
registries for widely recognized identifiers used in QoS management for widely recognized identifiers used in QoS management for IP and
for IP and Ethernet networks. Reserved values are set aside for Ethernet networks. Reserved values are set aside for similar future
similar future identifiers that may emerge to denote QoS treatment. identifiers that may emerge to denote QoS treatment. However,
However, requests for new entries are not expected to be frequent. requests for new entries are not expected to be frequent.
Allocations within the registry are subject to the following Allocations within the registry are subject to the following
requirements: requirements:
1. Documentation of the intended use of the requested value, in 1. Documentation of the intended use of the requested value, in
compliance with the "Specification Required" policy defined in compliance with the "Specification Required" policy defined in
[RFC8126]. [RFC8126].
2. Approval by the designated expert (DE) appointed by the IESG. 2. Approval by the designated expert (DE) appointed by the IESG.
The DE must do the following: The DE must do the following:
skipping to change at line 590 skipping to change at line 595
mailing list designated by the IESG). mailing list designated by the IESG).
* Validate that external specifications requesting code points * Validate that external specifications requesting code points
are publicly available, are permanently archived, and do not are publicly available, are permanently archived, and do not
conflict with active or published IETF work. conflict with active or published IETF work.
* Ensure that the review process is conducted in a timely * Ensure that the review process is conducted in a timely
manner, with any disputes resolved through consultation with manner, with any disputes resolved through consultation with
the appropriate working groups. the appropriate working groups.
To simplify future registrations in DLEP-related registries, it is 5.3. Registration Guidance
recommended that this guidance apply to all registries within the
"Dynamic Link Exchange Protocol (DLEP) Parameters" registry group. This section provides guidance for registrations in the "Traffic
Future specifications may point to the guidance in this document. Classification Sub-Data Item Type Values" registry. To simplify
future registrations in DLEP-related registries, it is recommended
that the guidance in this section apply to all registries within the
"Dynamic Link Exchange Protocol (DLEP) Parameters" registry group
that use the "Specification Required" policy [RFC8126]. Future
specifications may point to the guidance in this document.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at line 636 skipping to change at line 646
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
[IEEE-802.1AE] [IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", networks-Media Access Control (MAC) Security",
DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018,
December 2018, December 2018,
<https://ieeexplore.ieee.org/document/8585421>. <https://ieeexplore.ieee.org/document/8585421>.
[IEEE-8802-1X] [IEEE-802.1X]
IEEE, "IEEE/ISO/IEC International Standard- IEEE, "8802-1X-2021 - IEEE/ISO/IEC International Standard-
Telecommunications and exchange between information Telecommunications and exchange between information
technology systems--Requirements for local and technology systems--Requirements for local and
metropolitan area networks--Part 1X:Port-based network metropolitan area networks--Part 1X:Port-based network
access control", DOI 10.1109/IEEESTD.2021.9650828, IEEE access control", DOI 10.1109/IEEESTD.2021.9650828, IEEE
Std 8802-1X-2021, December 2021, Std IEEE-802.1X-2021, December 2021,
<https://ieeexplore.ieee.org/document/9650828>. <https://ieeexplore.ieee.org/document/9650828>.
[IEEE8021Q] [IEEE8021Q]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks", Networks--Bridges and Bridged Networks",
DOI 10.1109/IEEESTD.2022.10004498, IEEE Std 802.1Q-2022, DOI 10.1109/IEEESTD.2022.10004498, IEEE Std 802.1Q-2022,
December 2022, December 2022,
<https://ieeexplore.ieee.org/document/10004498>. <https://ieeexplore.ieee.org/document/10004498>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
 End of changes. 17 change blocks. 
53 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.48.