From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: can@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Computing-Aware Networking (can)
A new IETF WG has been proposed in the Routing Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2023-02-27.
Computing-Aware Networking (can)
-----------------------------------------------------------------------
Current status: BOF WG
Chairs:
Peng Liu <liupengyjy@chinamobile.com>
Adrian Farrel <adrian@olddog.co.uk>
Assigned Area Director:
John Scudder <jgs@juniper.net>
Routing Area Directors:
Alvaro Retana <aretana.ietf@gmail.com>
John Scudder <jgs@juniper.net>
Andrew Alston <andrew-ietf@liquid.tech>
Mailing list:
Address: can@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/can
Archive: https://mailarchive.ietf.org/arch/browse/can/
Group page: https://datatracker.ietf.org/group/can/
Charter: https://datatracker.ietf.org/doc/charter-ietf-can/
Computing-Aware Networking (can)
Many service architectures create multiple service instances. These
instances are often geographically distributed to multiple sites, and
a single site may support multiple instances of a service. The services
are provided on computing platforms 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, the evolution of networked AR/VR,
and deployment of autonomous and networked vehicles), 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 a network edge 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 network 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 is working 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 that informs the steering applied by the network
edge nodes, and the desire to operate that function on nodes within the
service provider's network, logically separated from service operation.
Exposure of network and compute conditions to applications is not in the
scope of CAN. Because of their experience and prior work in collecting
and exposing network conditions for use in selecting paths and servers,
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 network
edge node makes a decision based on the metrics of interest, and then
steers the traffic to a node that serves a service instance, for example
using a tunnel. The CAN WG will focus on single domain models.
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.
o 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,
including methods for distributing necessary information to utilize
the identified metrics in CAN use cases. This will also cover OAM,
scalability, and security aspects.
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.
o 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
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
can-chairs@ietf.org,
can@ietf.org
Subject: WG Action: Formed Computing-Aware Networking (can)
A new IETF WG has been formed in the Routing Area. For additional
information, please contact the Area Directors or the WG Chairs.
Computing-Aware Networking (can)
-----------------------------------------------------------------------
Current status: BOF WG
Chairs:
Linda Dunbar <linda.dunbar@futurewei.com>
Zhaohui Zhang <zzhang@juniper.net>
Assigned Area Director:
John Scudder <jgs@juniper.net>
Routing Area Directors:
Alvaro Retana <aretana.ietf@gmail.com>
John Scudder <jgs@juniper.net>
Andrew Alston <andrew-ietf@liquid.tech>
Mailing list:
Address: can@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/can
Archive: https://mailarchive.ietf.org/arch/browse/can/
Group page: https://datatracker.ietf.org/group/can/
Charter: https://datatracker.ietf.org/doc/charter-ietf-can/
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
Milestones: