Index - Month Index of IDs
All IDs - sorted by date)
| Trusted Execution Environment Provisioning (TEEP) Protocol | ||||||||||||||
|
This document specifies the Trusted Execution Environment Provisioning (TEEP) Protocol, which enables secure lifecycle management of Trusted Components in devices with a Trusted Execution Environment (TEE). The protocol defines message exchanges between a Trusted Application Manager (TAM) and a TEEP Agent to query device state, convey attestation evidence, and install, update, or delete Trusted Components. Messages are encoded in CBOR and secured using COSE. | |||||||||||||
| Chunked Oblivious HTTP Messages | ||||||||||||||
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. | |||||||||||||
| LISP Traffic Engineering | ||||||||||||||
|
This document describes how Locator/Identifier Separation Protocol (LISP) re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes and specify how existing Routing Locator encodings are used to construct Explicit Locator Paths for traffic engineering purposes. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. | |||||||||||||
| Group Communication for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. | |||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution | ||||||||||||||
|
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. | |||||||||||||
| YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol | ||||||||||||||
|
This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. | |||||||||||||
| YANG Groupings for HTTP Clients and HTTP Servers | ||||||||||||||
|
This document presents three YANG 1.1 modules as follows. The "iana- http-versions" module defines a YANG "typedef" for HTTP protocol versions. The "ietf-http-client" module defines a YANG "grouping" for configuring an HTTP client's ability to communicate with an HTTP service endpoint. The "ietf-http-server" module defines a "grouping" for configuring an HTTP server's service endpoints. | |||||||||||||
| YANG Data Model for MPLS mLDP | ||||||||||||||
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements | ||||||||||||||
|
Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute- intensive and delay-sensitive services. To optimize throughput and response time, "Computing-Aware Traffic Steering" (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain, and drives requirements for the CATS framework. | |||||||||||||
| A YANG Data Model for Flexi-Grid Optical Networks | ||||||||||||||
|
This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. | |||||||||||||