Computing-Aware Networking
charter-ietf-can-00-02
Document | Proposed charter | Computing-Aware Networking WG (can) Snapshot | |
---|---|---|---|
Title | Computing-Aware Networking | ||
Last updated | 2023-02-10 | ||
State | Start Chartering/Rechartering (Internal Steering Group/IAB Review) | ||
WG | State | BOF | |
IESG | Responsible AD | John Scudder | |
Charter edit AD | John Scudder | ||
Send notices to | (None) |
Computing-Aware Networking (can)
Many modern service architectures create multiple service instances.
These instances are often geographically distributed to multiple sites.
The services are provided on computing resources (processors) and are
generically referred to as "compute services". The CAN (Computing-Aware
Networking) working group (WG) is chartered to consider the problem of
how the network edge can steer traffic between clients of a service and
sites offering the service.
Since, for some services (for example, VR/AR, intelligent
transportation), the performance experienced by clients will depend on
both network metrics such as bandwidth and latency, and compute metrics
such as processing, storage capabilities, and capacity, there is a
need for a solution that can optimize how an ingress node steers traffic
based on these metrics, as appropriate to the service.
Although the specific optimization function will likely differ between
services, implementations, and deployments, there is a need for a
general framework for the distribution of compute and network metrics
and transport of traffic from client edge to service instance. It also
is likely that some set of common metrics can be identified. The CAN WG
will concern itself with these issues.
The IETF has done past work on exposing network conditions to endpoints
(notably ALTO) and load balancing/service selection at layers 4 and 7
(for example, related to the selection of SIP servers). Specific
characteristics that may distinguish CAN from other work include the
desire to integrate both network and compute conditions in the
optimization function, and the desire to operate that function on nodes
within the service provider's network, logically separated from service
operation. As part of its work, the CAN WG will seek advice and
expertise from the ART and TSV areas.
The assumed model for the CAN WG is an overlay network, where a client
edge node makes a decision based on the metrics of interest, and then
steers the traffic to a service instance, for example using a tunnel.
Architectures that require the underlay network to be service-aware are
out of scope.
The CAN WG will analyze the problem in further detail and produce an
architecture for a solution. Ideally, that architecture will be one that
can be instantiated using existing technologies.
The CAN WG is chartered to work on the following items:
o Groundwork may be documented via a set of informational Internet-
Drafts, not necessarily for publication as RFCs:
-
Problem statement for the need to consider both network and
computing resource status. -
Use cases for steering traffic from applications that have critical
SLAs that would benefit from the integrated consideration of network
and computing resource status. -
Requirements for commonly agreed computing metrics and their
distribution across the overlay network, as well as the appropriate
frequency and scope of distribution. -
Overall CAN framework & architecture:
- This work encompasses the various building blocks and their
interactions, realizing a CAN control and data plane that
addresses the identified problems and requirements in the
groundwork. This should also cover OAM, scalability, and security
aspects.
- This work encompasses the various building blocks and their
o Additional groundwork to include:
-
Analyze the suitability and usefulness of computing and networking
metrics for traffic steering decisions in CAN with a CAN metrics
ontology as a possible outcome. -
Analyze methods for distributing the necessary information to
utilize the identified metrics in CAN use cases. -
Applicability of existing tools and mechanisms:
-
Analysis of implementing the CAN control and data plane using
existing mechanisms, including identifying the limitations of
existing tools in fulfilling requirements. -
Study potential new approaches for the CAN control and data plane
solution that can fill the identified gaps in existing tools and
solutions. -
Study FCAPS (fault, configuration, accounting, performance,
security) requirements, mechanisms, and suitability of existing
messaging protocols (NETCONF) and data models (YANG).
-
Milestones:
Jul 2023 Adopt the CAN Problem Statement, Use Cases, Gap Analysis, and
Requirements documents
Jul 2024 Adopt the CAN Framework and Architecture document
Nov 2025 Submit the CAN Framework and Architecture document to the IESG
for publication