Many modern service architectures create multiple service instances. These
instances are often geographically distributed to multiple sites. 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 and storage
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, 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 the 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 an ingress
node makes a decision based on the metrics of interest, and
then steers the traffic to an egress node that serves the selected 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 and
not necessarily for publication as an RFC:

        o  Problem statement for the need for considering both network and
        computing resource status.

        o  Use cases for using the network and computing resource status to
        benefit the steering of traffic from applications that have a critical
        SLA that would require the integrated considerations of network-path
        conditions and computing resources.
        
        o  Requirements for commonly agreed computing metrics and their
        distribution across the overlay network, as well as the appropriate frequency
        and scope of distribution.

o  Overall CAN framework & architecture: 

        o  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.

o  Additional groundwork to include:

        o  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.

        o  Analyze methods for distributing the necessary information to
        utilize the identified metrics in CAN use cases.

o  Applicability of existing tools and mechanisms:

        o  Analysis of implementing the CAN control and data plane using
        existing mechanisms, including identifying the limitations of existing
        tools in fulfilling requirements.

        o  Study potential new approaches for the CAN control and data plane
        solution that can fill the identified gaps of existing tools and
        solutions.

        o  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 & architecture document

Nov 2025  Submit the CAN framework & architecture document to the IESG for
publication