Index - Month Index of IDs
All IDs - sorted by date)
| Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item | ||||||||||||||
|
This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP) to support traffic classification. Traffic classification information identifies traffic flows based on frame/ packet content such as destination address. The Data Item is defined in an extensible and reusable fashion. Its use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP Sub-Data Items, and Sub-Data Items are defined to support DiffServ and Ethernet traffic classification. | |||||||||||||
| Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items | ||||||||||||||
|
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. | |||||||||||||
| DLEP IEEE 802.1Q Aware Credit Window Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit- window scheme for destination-specific and shared flow control. | |||||||||||||
| Domain-based Message Authentication,Reporting,and Conformance (DMARC) Aggregate Reporting | ||||||||||||||
|
Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record. | |||||||||||||
| Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests | ||||||||||||||
|
This specification describes extensions to the SUIT manifest format. These extensions allow an update author, update distributor or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. | |||||||||||||
| Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document clarifies and extends the meaning of transform type 5 in IKEv2. It updates RFC 7296 by renaming the transform type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". It also renames two currently defined values for this transform type: value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers". | |||||||||||||
| Root-initiated Routing State in RPL | ||||||||||||||
|
The Routing Protocol for Low-Power and Lossy Networks (RPL, RFC 6550) enables data packet routing along a Destination-Oriented Directed Acyclic Graph . However, the default route establishment mechanism relies on hop-by-hop forwarding along the DODAG, which may not always provide optimal routing efficiency. This document introduces the concept of DAO Projection, a mechanism that allows a RPL root or an external controller to install optimized routes within the RPL domain. DAO Projections enable the creation of optimized unicast or multicast routes that do not strictly follow the DODAG structure, thereby improving routing efficiency, reliability, availability, and resource utilization in the RPL domain. The document specifies two types of projected routes—storing mode and non-storing mode projections—and outlines the signaling procedures necessary to establish, maintain, and remove these routes. This document extends RFC 6550, RFC 6553, and RFC 8138. | |||||||||||||
| More Accurate Explicit Congestion Notification (AccECN) Feedback in TCP | ||||||||||||||
|
Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. ECN was originally specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recent new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) or Low Latency, Low Loss, and Scalable Throughput (L4S) need more Accurate ECN (AccECN) feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it allocates a reserved header bit previously assigned to the ECN-Nonce. It also overloads the two existing ECN flags in the TCP header. The resulting extra space is additionally exploited to feed back the IP-ECN field received during the TCP connection establishment. Supplementary feedback information can optionally be provided in two new TCP option alternatives, which are never used on the TCP SYN. The document also specifies the treatment of this updated TCP wire protocol by middleboxes. | |||||||||||||
| Advertisement of Segment Routing Policies using BGP Link-State | ||||||||||||||
|
This document describes a mechanism to collect the Segment Routing Policy information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. | |||||||||||||
| DLEP DiffServ Aware Credit Window Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a DiffServ aware credit-window scheme for destination-specific and shared flow control. | |||||||||||||
| Strong Assertions of IoT Network Access Requirements | ||||||||||||||
|
The Manufacturer Usage Description (MUD) specification describes the access and network functionality required for a device to properly function. This description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration. A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control. This document defines a way to link the Software Updates for Internet of Things (SUIT) manifest to a MUD file offering a stronger binding between the two. | |||||||||||||
| Trusted Execution Environment Provisioning (TEEP) Protocol | ||||||||||||||
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. | |||||||||||||
| Supporting Asymmetric Links in Low Power Networks: AODV-RPL | ||||||||||||||
|
Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routes and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. | |||||||||||||