| |
|
| |
| | ESP Echo Protocol |
| |
| | draft-ietf-ipsecme-esp-ping-00.txt |
| | Date: |
30/04/2025 |
| | Authors: |
Lorenzo Colitti, Jen Linkova, Michael Richardson |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| | Layer-3 Discovery and Liveness |
| |
| | draft-ietf-lsvr-l3dl-15.txt |
| | Date: |
30/04/2025 |
| | Authors: |
Randy Bush, Rob Austein, Russ Housley, Keyur Patel |
| | Working Group: |
Link State Vector Routing (lsvr) |
|
In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer-3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols. |
| | Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
| | draft-fossati-tls-attestation-09.txt |
| | Date: |
30/04/2025 |
| | Authors: |
Hannes Tschofenig, Yaron Sheffer, Paul Howard, Ionut Mihalcea, Yogesh Deshpande, Arto Niemi, Thomas Fossati |
| | Working Group: |
Individual Submissions (none) |
|
The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually. |
| | Resource Guarantee for SRv6 Policies |
| |
|
This document defines a new SRv6 Endpoint behavior which can be used to associate with a set of network resource partition (e.g. bandwidth, buffer and queue resources ) Programming, called End.NRP. By using the End.NRP SID to build its segment list, the SRv6 policy has the capability to program network resources and achieve strict SLA guarantees. |
| | AI Content Disclosure Header |
| |
|
This document proposes a machine-readable Hypertext Transfer Protocol (HTTP) response header field, AI-Disclosure, to disclose the presence and degree of Artificial Intelligence (AI) generated or AI-assisted content in web responses. The header is designed for compatibility with HTTP structured field syntax and provides metadata for user agents, bots, and archiving systems. It supports layered disclosure strategies alongside human-readable and structured metadata formats. |
| | SRv6 for Inter-Layer Network Programming |
| |
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. |
| |
|
| |
| | Use cases,Network Scenarios and gap analysis for Packet Optical Integration (POI) with programmable pluggables under ACTN Framework |
| |
|
This document provides general overarching guidelines for control and management of packet over optical converged networks with programmable pluggables and focuses on operators' use cases and network scenarios. It provides a set of use cases which are needed for the control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on programmable pluggables. The document provides a gap analysis to solve the use cases. |
| | A JSON Encoding for HTTP Field Values |
| |
|
This document establishes a convention for use of JSON-encoded field values in new HTTP fields. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTPS |
| |
| | draft-ietf-regext-epp-https-01.txt |
| | Date: |
29/04/2025 |
| | Authors: |
Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | DCCP Extensions for Multipath Operation with Multiple Addresses |
| |
| | draft-ietf-tsvwg-multipath-dccp-24.txt |
| | Date: |
29/04/2025 |
| | Authors: |
Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic, Stephen Johnson |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
Datagram Congestion Control Protocol (DCCP) communications, as defined in RFC 4340, are inherently restricted to a single path per connection, despite the availability of multiple network paths between peers. The ability to utilize multiple paths simultaneously for a DCCP session can enhance network resource utilization, improve throughput, and increase resilience to network failures, ultimately enhancing the user experience. Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., handsets, vehicles) and residential home gateways that maintain simultaneous connections to distinct network types, such as cellular and Wireless Local Area Networks (WLANs) or cellular and fixed access networks. Compared to existing multipath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly suited for latency- sensitive applications with varying requirements for reliability and in-order delivery. This document specifies a set of protocol extensions to DCCP that enable multipath operations. These extensions maintain the same service model as DCCP while introducing mechanisms to establish and utilize multiple concurrent DCCP flows across different network paths. |
| |
|
| |
| | Discovery of Network Rate-Limit Policies (NRLPs) |
| |
|
This document specifies mechanims for hosts to dynamically discover Network Rate-Limit Policies (NRLPs). This information is then passed to applications that might adjust their behaviors accordingly. Networks already support mechanisms to advertize a set of network properties to hosts (e.g., link MTU (RFC 4861) and PREFIX64 (RFC 8781)). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate NRLPs to hosts. For address family parity, a new DHCP option is also defined. The document also discusses how Provisioning Domains (PvD) can be used to notify hosts with NRLPs. |
| | Throughput Advice Object for SCONE |
| |
|
Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons. This document specifies a generic object (called, Throughput Advice) that can be used by mechanisms for hosts to dynamically discover these network rate-limit policies. This information is then passed to applications that might adjust their behaviors accordingly. The design of the throughput advice object is independent of the discovery channel (protocol, API, etc.). |
| | SCONE Solution Analysis |
| |
| | draft-brw-scone-analysis-01.txt |
| | Date: |
27/04/2025 |
| | Authors: |
Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras |
| | Working Group: |
Individual Submissions (none) |
|
This document provides an analysis of various SCONE solutions to share the throughput advice. |
| | Secure Task-bound Agent Message Proof (STAMP) Protocol |
| |
|
The Secure Task-bound Agent Message Proof (STAMP) protocol provides a cryptographically verifiable delegation and proof framework for AI- driven multi-agent systems. STAMP introduces task-bound access tokens and message-level proofs for agentic environments, binding tokens to specific user intents, tasks, and agent identities. STAMP tokens ensure that delegation, execution, and agent-to-agent communication comply with least-privilege and zero-trust security principles. STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of- possession (PoP) techniques, providing stronger security for dynamic, non-deterministic workflows involving autonomous agents. |
| |
|
| |
| | Enhanced Topology Independent Loop-free Alternate Fast Re-route |
| |
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. |
| | Flooding Reduction Algorithms Framework |
| |
|
This document introduces a framework to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. |
| | Reverse HTTP CONNECT for TCP and UDP |
| |
|
This document specifies an extension to the HTTP CONNECT method, enabling a proxy client to accept inbound TCP and UDP sessions proxied through HTTP/1.1, HTTP/2, or HTTP/3. This mechanism allows the client to dynamically advertise available local or internal network services and expose them through a HTTP proxy without reliance on IP routing. |
| | Initialisation of DNSSEC Policy for DNS Catalog Zones Members |
| |
|
This document describes an update to "DNS Catalog Zones" ([RFC9432]) that facilitates a method to signal DNSSEC policy to DNSSEC signers for member zone(s) using information contained within a catalog zone. |
| | Register a new reserved content coding value |
| |
|
This document proposes a new reserved value unknown for the HTTP protocol parameter content coding. |
| | JSON-Based Dynamic Configuration Management |
| |
|
JavaScript Object Notation (JSON) is a widely used data interchange format, suitable for storing configuration data due to its simple syntax, machine-readable structure, and ease of parsing and generation. This document describes informational practices associated with JSON- Based Dynamic Configuration Management. It outlines a recommended naming convention for configuration files in the form of a structured filename pattern, such as "@.json", and specifies a configuration schema to support validation, traceability, and non- disruptive updates. The document also describes the rationale for standardization and presents real-world scenarios where these practices apply. |
| |
|
| |
| | ISP Dual Queue Networking Deployment Recommendations |
| |
|
The IETF's Transport and Services Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores the potential implications of those decisions and makes recommendations that can help drive adoption and acceptance of L4S and NQB. |
| | Security Considerations for Computing-Aware Traffic Steering |
| |
|
Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats. |
| | Adaptive Routing Framework |
| |
|
In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism. |
| | Link Discovery Protocol (LLDP) Extensions for Segment Routing over IPv6 (SRv6) |
| |
|
This document describes the method of carrying SRv6 Locator information through the LLDP protocol to simplify SRv6 deployment. |
| | BGP - Link State (BGP-LS) Advertisement of BGP Egress Peer Engineering Performance Metric Extensions |
| |
|
This document specifies a method for advertising BGP Egress Peer Engineering (EPE) Traffic Engineering (TE) Performance Metric information via BGP-LS. |
| | Inter-domain Source Address Validation (SAVNET) OAM |
| |
|
This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Inter-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
| | Encapsulation and Forwarding Process for IPv6 Multicast Source Routing (MSR6) Data Plane |
| |
|
This document specifies the mechanism of IPv6 Multicast Source Routing (MSR6), covering the encapsulation and forwarding processes in the data plane. It introduces the hierarchical bitstring structure (HBS) to organize replication information, and represent more information than flat bit strings. It indicates multicast forwarding behavior based on the local bitstring forwarding table, requires less BIFT state and improve scalability. |
| | DHCPv6 Active Leasequery over QUIC |
| |
|
RFC7653 allows for actively transferring the real-time binding information data of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) via TCP, which satisfies the need of continuous update of an external requestor with Leasequery data. QUIC could provide useful, reliable and secure semantics for transferring active leasequery of DHCPv6, which enabling much better efficiency and performance by reducing connect time. This document describes how to use the QUIC transport protocol to deliver DHCPv6 Active Leasequery messages, named DHCP6oQUIC. |
| |
|
| |
| | Encrypted DNS Server Redirection |
| |
|
This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server. |
| | REST API Linked Data Keywords |
| |
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. |
| | Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
| | draft-cxx-ippm-ioamaggr-03.txt |
| | Date: |
23/04/2025 |
| | Authors: |
Alexander Clemm, Metzger, Ramon Bister, Severin Dellsperger |
| | Working Group: |
Individual Submissions (none) |
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. |
| | Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification |
| |
|
Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. |
| | A mechanism of security monitoring and management for service resources in Computing-Aware Traffic Steering (CATS) |
| |
|
This draft proposes a mechanism to realize monitoring and management of service resources. |
| |
|
| |
| | Flexible Session Protocol |
| |
|
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: * Stream-oriented send-receive with native message boundary * Flexibility to exploit authenticated encryption * On-the-wire compression * Light-weight session management |
| | KEM-based Authentication for TLS 1.3 |
| |
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| | KEM-based pre-shared-key handshakes for TLS 1.3 |
| |
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| | Convertible Forms with Multiple Keys and Signatures For Use In Internet X.509 Certificates |
| |
|
This document presents a hybrid key and signature solution, which allows to integrate two public keys and/or two signatures into a single certificate. The scheme enables a single certificate to be converted between different forms, allowing an alternative public key and/or an alternative signature to be transmitted either by direct inclusion or by referencing external data. This flexibility ensures that the scheme is backward-compatible with legacy devices, while also providing enhanced security support for upgraded devices. Four CSR attributes and two new X.509v3 certificate extensions are defined, and the procedures for signing and verifying certificates containing the defined attributes and extensions are described. |
| | Automated Summaries of IETF Contributions |
| |
|
Automated summaries of IETF contributions are permissible contributions. |
| | OAuth Pushed Client Registration |
| |
|
This specification provides a way for an ephemeral or transactional OAuth 2.0 client to signal to the AS that the client does not need or expect to have an identified state outside the existence of any issued access and refresh tokens. The specification also enables a client to push its registration information to the AS during a pushed authorization request. |
| | PQuAKE - Post-Quantum Authenticated Key Exchange |
| |
| | draft-uri-lake-pquake-00.txt |
| | Date: |
22/04/2025 |
| | Authors: |
Uri Blumenthal, Brandon Luo, Sean O'Melia, Gabriel Torres, David Wilson |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the Post-Quantum Authenticated Key Exchange (PQuAKE) protocol that addresses the needs of bandwidth- and/or power-constrained environments, while maintaining strong security guarantees. It accomplishes that by minimizing the number of bits that need to be exchanged and by utilizing an implicit peer authentication approach similar to Menezes-Qu-Vanstone (MQV) design. This protocol is suitable for integration into protocols that establish dynamic secure sessions, such as Extensible Authentication Protocol (EAP), Internet Key Exchange Version 2 (IKEv2), or Secure COmmunications Interoperability Protocol (SCIP). This protocol has proofs in the verifiers Verifpal and CryptoVerif for security properties such as secrecy of the session key, mutual authentication, identity hiding with a preshared secret, and forward secrecy of the session key. The authors are in the process of publishing the proofs. |
| | Roughtime |
| |
|
This document describes Roughtime—a protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and giving clients a format by which to report any inconsistencies they observe between time servers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work. |
| |
|
| |
| | RUSH - Reliable (unreliable) streaming protocol |
| |
| | draft-kpugin-rush-03.txt |
| | Date: |
21/04/2025 |
| | Authors: |
Kirill Pugin, Nitin Garg, Alan Frindell, Jorge Ferret, Jake Weissman |
| | Working Group: |
Individual Submissions (none) |
|
RUSH is an application-level protocol for ingesting live video. This document describes the protocol and how it maps onto QUIC. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at https://github.com/afrind/draft-rush. |
| | Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks |
| |
|
Optical networking technologies such as fine-grain OTN (fgOTN) enable premium cloud-based services, including optical leased line, cloud Virtual Reality (cloud-VR), and computing to be carried end-to-end optically between applications and cloud data centers (DCs), offering premium quality and deterministic performance. This document describes the problem statement and requirements for accessing cloud services through optical networks. It also discusses technical gaps for IETF-developed management and control protocols to support service provisioning and management in such an all-optical network scenario. |
| | Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP) |
| |
|
This document describes the usage of the Datagram Transport Layer Security (DTLS) 1.3 protocol over the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 6083. DTLS 1.3 over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS 1.3 over SCTP can use almost all transport features provided by SCTP and its extensions. |
| | 4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks |
| |
|
This document defines a new type of segment for Segment Routing, 4map6 segment, which is an IPv4/IPv6 conversion function based on stateless mapping rules running in PE nodes for the delivery of IPv4 services over IPv6-only network. At the same time, the BGP Prefix- SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6 address mapping rules in IPv6-only domain and cross-domain. |
| | Perceptive Routing Information Model |
| |
|
This docuement defines the information model for perceptive routing, which could serve as a foundational component in the implementation of perceptive routing. |
| | Protocol for Automation Control |
| |
|
This document specifies a machine-readable protocol for server-side automation permissions in the light of recent advances in AI-driven web automation. Building upon RFC9309, this protocol addresses a broader range of state-changing activities that service owners may wish to control. It defines the file format, HTTP method restrictions, and purpose requirements. |
| | Protocol Extension for Automation Control |
| |
|
This document specifies extensions to [CORE-SPEC], providing a wider range of controls for server-side automation permissions. It supports rate limiting, automation technology restrictions, API permissions, session requirements, and HTML asset annotations. These extensions enable service owners to exercise more granular control over automated interactions. |
| | ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets |
| |
|
This document specifies an experimental modification to ECN when used with TCP. It allows the use of ECN in the IP header of the following TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and retransmissions. This specification obsoletes RFC5562, which described a different way to use ECN on SYN/ACKs alone. |
| | Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) |
| |
| | draft-ietf-tsvwg-rfc4895-bis-05.txt |
| | Date: |
21/04/2025 |
| | Authors: |
Michael Tuexen, Randall Stewart, Peter Lei, Hannes Tschofenig |
| | Working Group: |
Transport and Services Working Group (tsvwg) |
|
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. This document obsoletes RFC 4895. |
| |
|
| |
| | Enforcing end-to-end delay bounds via queue resizing |
| |
|
This document presents a distributed mechanism to enforce strict delay bounds for some network flows in large scale networks. It leverages on the capacity of modern network devices to adapt their queue's capacities to bound the maximum time spent by packets in those devices. It is using a reservation protocol to guarantee the availability of the resources in the devices' queues to serve packets belonging to specific flows while enforcing an end-to-end delay constraint. |
| | Customer Experience Index for Evaluating Network Quality for Cloud Applications |
| |
| | draft-hz-ippm-cei-03.txt |
| | Date: |
20/04/2025 |
| | Authors: |
Sifa Liu, Yaojing Wang, Wei Sun, Xiang Huang, Shuai Zhou, Xuesong Geng, Hongyi Huang, Tianran Zhou, Jian Ge, KE Ma, Ruihao Chen |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines a unified Customer Experience Index (CEI) designed to assist cloud vendors in assessing network quality, reflecting the customer experience with cloud applications when accessed via the public network. |
| | Pisces: Real-Time Video Transport Framework |
| |
| | draft-zheng-pisces-01.txt |
| | Date: |
20/04/2025 |
| | Authors: |
Jiaqi Zheng, Feida Liu, Yu Liu, Yi Lu, Guihai Chen |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the Pisces, an ensemble video transport framework for real-time communication. Pisces complements the benefits of rule-based and learning-based approaches, without modifying the codec layer. Pisces uses an incremental and iterative reinforcement learning model to adapt to the unseen environment. When the real environment well matches the training environment, the learning-based approach is actively working. Otherwise, the rule- based approach is used to ensure transport safety. By simultaneously leveraging both rule-based logic and learning models to proactively probe network capacity, Pisces achieves high efficiency in both single-flow and cross-flow scenarios, while ensuring stable and fair cross-flow convergence. Pisces can be deployed in WebRTC, which replaces the default Google congestion control algorithm. |
| | Framework for Implementing Lossless Techniques in Wide Area Networks |
| |
|
This document proposes a comprehensive framework to address the challenges of efficient, reliable, and cost-effective large volume data transmission over Wide Area Networks (WANs). The framework focuses on planning and managing traffic paths, network slicing, and utilizing multi-level network buffers. It introduces dynamic path scheduling and advanced resource allocation techniques to optimize network resouce and minimize congestion. By leveraging cross-device buffer coordination and real-time adjustments, the framework ensures high throughput and low latency, meeting the demands of modern, data- intensive applications while providing a robust solution for large- scale data transmission. |
| | SCONE Real Time Communication Requirement |
| |
|
In real-time communication (RTC) applications, low latency is essential, but unstable network conditions make it challenging. Traditional control loop reacts slowly and inaccurately to network changes. A new approach is proposed, communicating bandwidth and queue information from the bottleneck to the end-host for more accurate control. |
| | BGP Prefix Independent Convergence |
| |
| | draft-ietf-rtgwg-bgp-pic-22.txt |
| | Date: |
20/04/2025 |
| | Authors: |
Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup. |
| |
|
| |
| | Applicability of Interfaces to Network Security Functions to Network-Based Security Services |
| |
| | draft-ietf-i2nsf-applicability-19.txt |
| | Date: |
03/04/2025 |
| | Authors: |
Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Sue Hares, Diego Lopez |
| | Working Group: |
Interface to Network Security Functions (i2nsf) |
|
This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. |
| | Extensions to the Access Control Lists (ACLs) YANG Model |
| |
|
RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability. The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers. |
| | A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies |
| |
| | draft-ietf-teas-5g-ns-ip-mpls-18.txt |
| | Date: |
03/04/2025 |
| | Authors: |
Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, Mohamed Boucadair, Luis Contreras |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a Network Slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks. |
| | TLS 1.2 is in Feature Freeze |
| |
|
Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that outside of urgent security fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. |