A Framework for Computing-Aware Traffic
Steering (CATS)Huawei TechnologiesChinac.l@huawei.comChina MobileChinaduzongpeng@chinamobile.comOrangeFrancemohamed.boucadair@orange.comTelefonicaSpainluismiguel.contrerasmurillo@telefonica.comJuniper Networks, Inc.United States of Americajdrake@juniper.net
Routing area
catsUser ExperienceCollaborative NetworkingService optimizationThis document describes a framework for Computing-Aware Traffic
Steering (CATS). Particularly, the document identifies a set of CATS
components, describes their interactions, and exemplifies the workflow
of the control and data planes.IntroductionComputing service architectures have been expanding from single
service site to multiple, sometimes collaborative, service sites to
address various issues (e.g., long response times or suboptimal service
and network resource usage).The underlying networking infrastructures that include computing
resources usually provide relatively static service dispatching (that
is, the selection of the service instances that will be invoked for a
request). In such infrastructures, service-specific traffic is often
directed to the closest service site from a routing perspective without
considering the actual network state (e.g., traffic congestion
conditions) or the service site state.As described in ,
traffic steering that takes into account computing resource metrics
would benefit several services, including latency-sensitive services
like immersive services that rely upon the use of augmented reality or
virtual reality (AR/VR) techniques. This document provides an
architectural framework that aims at facilitating the making of compute-
and network-aware traffic steering decisions in networking environments
where computing service resources are deployed.The Computing-Aware Traffic Steering (CATS) framework assumes that
there might be multiple service instances that are providing one given
service. Each of these service instances can be accessed via a service
contact instance. A single service site may have limited computing
resources available at a given time, whereas the various service sites
may experience different resource availability issues over time. A
single service site may host one or multiple service contact
instances.Steering in CATS is about selecting the appropriate service contact
instance that will service a request according to a set of network and
computing metrics. That selection may not necessarily reveal the actual
service instance that will be invoked, e.g., in hierarchical or
recursive contexts. Therefore, the metrics of the service contact
instance may be the aggregated metrics from multiple service
instances.The CATS framework is an overlay framework for the selection of the
suitable service contact instance(s) from a set of candidates. The exact
characterization of 'suitable' is determined by a combination of
networking and computing metrics.Also, this document describes a workflow of the main CATS procedures
that are executed in both the control and data planes.TerminologyThis document makes use of the following terms:
Client:
An endpoint that is connected to a service provider network.
Computing-Aware Traffic Steering (CATS):
A traffic engineering approach that takes into account the
dynamic nature of computing resources and network state to optimize
service-specific traffic forwarding towards a given service contact
instance. Various relevant metrics may be used to enforce such
computing-aware traffic steering policies.
CATS Service ID (CS-ID):
An identifier representing a service, which the clients use to
access it. See .
CATS Instance Selector ID (CIS-ID):
An identifier of a specific service contact instance. See .
Service:
An offering that is made available by a provider by orchestrating
a set of resources (networking, compute, storage, etc.).
Which and how these resources are solicited is part of the
service logic which is internal to the provider. For example, these
resources may be:
Exposed by one or multiple processes (a.k.a. Service
Functions (SFs) ).
Provided by virtual instances, physical, or a combination
thereof.
Hosted within the same or distinct nodes.
Hosted within the same or multiple service sites.
Chained to provide a service using a variety of means.
How a service is structured is out of the scope of CATS.
The same service can be provided in many locations; each of them
constitutes a service instance.
Computing Service:
An offering is made available by a provider by orchestrating a
set of computing resources (without networking resources).
Service instance:
An instance of running resources according to a given service
logic.
Many such instances can be enabled by a provider. Instances that
adhere to the same service logic provide the same service.
An instance is typically running in a service site. Clients'
requests are serviced by one of these instances.
Service site:
A location that hosts the resources that are required to offer a
service.
A service site may be a node or a set of nodes.
A CATS-serviced site is a service site that is connected to a
CATS-Forwarder.
Service contact instance:
A client-facing service function instance that is responsible for
receiving requests in the context of a given service. A service
request is processed according to the service logic (e.g., handle
locally or solicit backend resources). Steering beyond the service
contact instance is hidden to both clients and CATS components.
a service contact instance is reachable via at least one Egress
CATS Forwarder.
A service can be accessed via multiple service contact instances
running at the same or different locations (service sites).
The same service contact instance may dispatch service requests
to one or more service instances (e.g., an instance that behaves as
a service load-balancer).
A forwarding (or steering, computing) scheme which takes a set of
metrics that reflect the capabilities and state of computing
resources as input.
Service request:
A request to access or invoke a specific service. Such a request
is steered to a service contact instance via CATS-Forwarders.
A service request is placed using service-specific protocols.
Service requests are not explicitly sent by clients to
CATS-Forwarders.
CATS-Forwarder:
A network entity that makes forwarding decisions based on CATS
information to steer traffic specific to a service request towards a
corresponding yet selected service contact instance. The selection
of a service contact instance relies upon a multi-metric path
computation.
A CATS-Forwarder may behave as Ingress or Egress
CATS-Forwarder.
Ingress CATS-Forwarder:
An entity that steers service-specific traffic along a
CATS-computed path that leads to an Egress CATS-Forwarder that
connects to the most suitable service site that host the service
contact instance selected to satisfy the initial service
request.
Egress CATS-Forwarder:
An entity that is located at the end of a CATS-computed path and
which connects to a CATS-serviced site.
CATS Path Selector (C-PS):
A functional entity that computes and selects paths towards
service locations and instances and which accommodates the
requirements of service requests. Such a path computation engine
takes into account the service and network status information. See
.
CATS Service Metric Agent (C-SMA):
A functional entity that is responsible for collecting service
capabilities and status, and for reporting them to a CATS Path
Selector (C-PS). See .
CATS Network Metric Agent (C-NMA):
A functional entity that is responsible for collecting network
capabilities and status, and for reporting them to a C-PS. See .
CATS Traffic Classifier (C-TC):
A functional entity that is responsible for determining which
packets belong to a traffic flow for a particular service request.
It is also responsible for forwarding such packets along a C-PS
computed path that leads to the relevant service contact instance.
See .
CATS Framework and ComponentsAssumptionsCATS assumes that there are multiple service instances running on
different service sites, and which provide a given service that is
represented by the same service identifier (see ). However, CATS does not make any assumption about
these instances other than they are reachable via one or multiple
service contact instances.CATS IdentifiersCATS uses the following identifiers:
CATS Service ID (CS-ID):
An identifier representing a service, which the clients use to
access it. Such an ID identifies all the instances of a given
service, regardless of their location.
The CS-ID is independent of which service contact instance
serves the service request.
Service requests are spread over the service contact instances
that can accommodate them, considering the location of the
initiator of the service request and the availability (in terms of
resource/traffic load, for example) of the service instances
resource-wise among other considerations like traffic congestion
conditions.
CATS Instance Selector ID (CIS-ID):
An identifier of a specific service contact instance.
Framework OverviewA high-level view of the CATS framework, without expanding the
functional entities in the network, is illustrated in .Main CATS Interactions| C-SMA |
| Control Plane | | | |
+----------------------------------+ | +---+----+
/\ | |
|| | |
\/ | |
+----------------------------------+ | +--------+
| Data Plane | | | +--------+
+----------------------------------+ |<=======>| |Service |
| +-|Contact |
| |Instance|
| +--------+
Network Domain Computing Domain
]]>Starting from the bottom part of and
moving to the upper part, the following planes are defined:
CATS Management Plane: Responsible for monitoring, configuring,
and maintaining CATS network devices.
CATS Control Plane: Responsible for scheduling services based
on computing and network information. It is also responsible for
making decisions about how packets should be forwarded by involved
forwarding nodes and communicating such decisions to the CATS Data
Plane for execution.
CATS Data Plane: Responsible for computing-aware routing,
including handling packets in the data path, such as packet
forwarding.
Depending on implementation and deployment, these planes may
consist of several functional elements/components, and the details
will be described in the following sections.CATS Functional ComponentsCATS nodes make forwarding decisions for a given service request
that has been received from a client according to the capabilities and
status information of both service contact instances and network. The
main CATS functional elements and their interactions are shown in
.CATS Functional ComponentsService Sites, Services Instances, and Service Contact
InstancesService sites are the premises that host a set of computing
resources. As mentioned in , a compute
service (e.g., for face recognition purposes or a game server) is
uniquely identified by a CATS Service IDentifier (CS-ID). The CS-ID
does not need to be globally unique, though.Service instances can be instantiated and accessed through
different service sites so that a single service can be represented
and accessed via several contact instances that run in different
regions of a network. shows two CATS nodes
("CATS-Forwarder 1" and "CATS-Forwarder 3") that provide access to
service contact instances. These nodes behave as Egress
CATS-Forwarders ().
Note: "Egress" is used here in reference to the direction of
the service request placement. The directionality is called to
explicitly identify the exit node of the CATS
infrastructure.
CATS Service Metric Agent (C-SMA)The CATS Service Metric Agent (C-SMA) is a functional component
that gathers information about service sites and server resources,
as well as the status of the different service instances. The C-SMAs
are located adjacent to the service contact instances and may be
hosted by the Egress CATS-Forwarders () or
located next to them. shows one C-SMA embedded in
"CATS-Forwarder 3", and another C-SMA that is adjacent to
"CATS-Forwarder 1".CATS Network Metric Agent (C-NMA)The CATS Network Metric Agent (C-NMA) is a functional component
that gathers information about the state of the underlay network.
The C-NMAs may be implemented as standalone components or may be
hosted by other components, such as CATS-Forwarders or CATS Path
Selectors (C-PS) ().C-NMA is likely to leverage existing techniques (e.g., ). shows a single, standalone
C-NMA within the underlay network. There may be one or more C-NMAs
for an underlay network.CATS Path Selector (C-PS)The C-SMAs and C-NMAs share the collected information with CATS
Path Selectors (C-PSes) that use such information to select the
Egress CATS-Forwarders (and potentially the service contact
instances) where to forward traffic for a given service request.
C-PSes also determine the best paths (possibly using tunnels) to
forward traffic, according to various criteria that include network
state and traffic congestion conditions. The collected information
is encoded into one or more metrics that feed the C-PS path
computation logic. Such an information also includes CS-ID and
possibly CIS-IDs.There might be one or more C-PSes used to compute CATS paths in a
CATS infrastructure.A C-PS can be integrated into CATS-Forwarders (e.g., "C-PS#1" in
) or may be deployed as a
standalone component (e.g., "C-PS#2" in ). Generally, a standalone C-PS can be
a functional component of a centralized controller (e.g., a Path
Computation Element (PCE) ).CATS Traffic Classifier (C-TC)CATS Traffic Classifier (C-TC) is a functional component that is
responsible for associating incoming packets from clients with
existing service requests. CATS classifiers also ensure that packets
that are bound to a specific service contact instance are all
forwarded towards that same service contact instance, as instructed
by a C-PS.CATS classifiers are typically hosted in CATS-Forwarders.Overlay CATS-ForwardersThe Egress CATS-Forwarders are the endpoints that behave as an
overlay egress for service requests that are forwarded over a CATS
infrastructure. A service site that hosts service instances may be
connected to one or more Egress CATS-Forwarders (that is,
multi-homing is of course a design option). If a C-PS has selected a
specific service contact instance and the C-TC has marked the
traffic with the CIS-ID, the Egress CATS-Forwarder then forwards
traffic to the relevant service contact instance. In some cases, the
choice of the service contact instance may be left open to the
Egress CATS-Forwarder (i.e., traffic is marked only with the CS-ID).
In such cases, the Egress CATS-Forwarder selects a service contact
instance using its knowledge of service and network capabilities as
well as the current load as observed by the CATS-Forwarder, among
other considerations. Absent explicit policy, an Egress
CATS-Forwarder must make sure to forward all packets that pertain to
a given service request towards the same service contact
instance.Note that, depending on the design considerations and service
requirements, per-service contact instance computing-related metrics
or aggregated per-site computing related metrics (and a combination
thereof) can be used by a C-PS. Using aggregated per-site computing
related metrics appears as a privileged option scalability-wise, but
relies on Egress CATS-Forwarders that connect to various service
contact instances to select the proper service contact instance. An
Egress CATS-Forwarder may choose to aggregate the metrics from
different sites as well. In this case, the Egress CATS-Forwarder
will choose the best site by itself when the packets arrive at
it.Underlay InfrastructureThe "underlay infrastructure" in indicates an IP/MPLS network that is
not necessarily CATS-aware. The CATS paths that are computed by a
P-CS will be distributed among the CATS-Forwarders (), and will not affect the underlay nodes.
Underlay nodes are typically P routers ().Deployment ConsiderationsThis document does not make any assumption about how the various
CATS functional elements are implemented and deployed. Concretely,
whether a CATS deployment follows a fully distributed design or relies
upon a mix of centralized (e.g., a C-PS) and distributed CATS
functions (e.g., CATS traffic classifiers) is deployment-specific and
may reflect the savoir-faire of the (CATS) service provider.Centralized designs where the computing related metrics from the
C-SMAs are collected by a (logically) centralized path computation
logic (e.g., a PCE) that also collects network metrics may be adopted.
In the latter case, the CATS computation logic may process incoming
service requests to compute and select paths and, therefore, service
contact instances. The outcomes of such a computation process may then
be communicated to CATS traffic classifiers (C-TCs).In conclusion, at least three deployment models can be considered
for the deployment of the CATS framework:
Distributed model:
Computing metrics are distributed among network devices
directly using distributed protocols without interactions with a
centralized control plane. Service scheduling function is
performed by the CATS forwarders in the distribution model,
Therefore, the C-PS is integrated into an Ingress
CATS-Forwarder.
Centralized model:
Computing metrics are collected by a centralized control plane,
and then the centralized control plane performs service scheduling
function, and computes the forwarding path for service requests
and syncs up with the Ingress CATS-Forwarder. In this model, C-PS
is implemented in the centralized control plane.
Hybrid model:
Is a combination of distribution and centralized models.
A part of computing metrics are distributed among involved
network devices, and others may be collected by a centralized
control plane. For example, some static information (e.g.,
capabilities information) can be distributed among network devices
since they are quite stable. Frequent changing information (e.g.,
resource utilization) can be collected by a centralized control
plane to avoid frequent flooding in the distributed control plane.
Service scheduling function can be performed by a centralized
control plane and/or the CATS forwarder. The entire or partial
C-PS function may be implemented in the centralized control plane,
depending on the specific implementation and deployment.
CATS Framework WorkflowThe following subsections provide an overview of how the CATS
workflow operates assuming a distributed CATS design.Provisioning of CATS ComponentsTBC: --detail required provisioning at CAST elements
(booptsrapping, credentials of peer CAST nodes, services, optimization
metrics per service, etc.)--Service AnnouncementA service is associated with a unique identifier called a CS-ID. A
CS-ID may be a network identifier, such as an IP address. The mapping
of CS-IDs to network identifiers may be learned through a name
resolution service, such as DNS .Metrics DistributionAs described in , a C-SMA collects
both service-related capabilities and metrics, and associates them
with a CS-ID that identifies the service. The C-SMA may aggregate the
metrics for multiple service contact instances, or maintain them
separately or both.The C-SMA then advertises CS-IDs along with metrics to related
C-PSes in the network. Depending on deployment choice, CS-IDs with
metrics may be distributed in different ways.For example, in a distributed model, CS-IDs with metrics can be
distributed from the C-SMA to an Egress CATS Forwarder firstly and
then be redistributed by the Egress CATS Forwarder to related C-PSes
that are integrated into Ingress CATS Forwarders.In the centralized model, CS-IDs with metrics can be distributed
from the C-SMA to a centralized control plane, for instance, a
standalone C-PS.In the hybrid model, the metrics can be distributed to C-PSes in
combination of distributed and centralized ways.The service metrics include computing-related metrics and
potentially other service-specific metrics like the number of
end-users who access the service contact instance at any given time,
their location, etc.Computing metrics may change very frequently (see for a discussion). How
frequently such information is distributed is to be determined as part
of the specification of any communication protocol (including routing
protocols) that may be used to distribute the information. Various
options can be considered, such as (but not limited to) interval-based
updates, threshold-triggered updates, or policy-based updates.Additionally, the C-NMA collects network-related capabilities and
metrics. These may be collected and distributed by existing routing
protocols, although extensions to such protocols may be required to
carry additional information (e.g., link latency). The C-NMA
distributes the network metrics to the C-PSes so that they can use the
combination of service and network metrics to determine the best
Egress CATS-Forwarder to provide access to a service contact instance
and invoke the compute function required by a service request. Similar
to service-related metrics, the network-related metrics can be
distributed using distributed, centralized, or hybrid schemes. This
document does not describe such details since this is a
deployment-specific.Network metrics may also change over time. Dynamic routing
protocols may take advantage of some information or capabilities to
prevent the network from being flooded with state change information
(e.g., Partial Route Computation (PRC) of OSPFv3 ). C-NMAs should also be configured or instructed
like C-SMAs to determine when and how often updates should be notified
to the C-PSes. shows an example of how
CATS metrics can be disseminated in the distributed model. There is a
client attached to the network via "CATS-Forwarder 1". There are three
instances of the service with CS-ID "1": two are located at "Service
Site 2" attached via "CATS-Forwarder 2" and have CIS-IDs "1" and "2";
the third service contact instance is located at "Service Site 3"
attached via "CATS-Forwarder 3" and with CIS-ID "3". There is also a
second service with CS-ID "2" with only one service contact instance
located at "Service Site 2".In , the C-SMA collocated
with "CATS-Forwarder 2" distributes the service metrics for both
service contact instances (i.e., (CS-ID 1, CIS-ID 1) and (CS-ID 1,
CIS-ID 2)). Note that this information may be aggregated into a single
advertisement, but in this case, the metrics for each service contact
instance are indicated separately. Similarly, the C-SMA agent located
at "Service Site 2" advertises the service metrics for the two
services hosted by "Service Site 2".The service metric advertisements are processed by the C-PS hosted
by "CATS-Forwarder 1". The C-PS also processes network metric
advertisements sent by the C-NMA. All metrics are used by the C-PS to
compute and select the most relevant path that leads to the Egress
CATS-Forwarder according to the initial client's service request, the
service that is requested ("CS-ID 1" or "CS-ID 2"), the state of the
service contact instances as reported by the metrics, and the state of
the network.An Example of CATS Metric Dessimination in a Distributed
Model
Service CS-ID 1, instance CIS-ID 2
:<----------------------:
: : +--------+
: : |CS-ID 1 |
: : +--|CIS-ID 1|
: +----------------+ | +--------+
: | C-SMA |----| Service Site 2
: +----------------+ | +--------+
: |CATS-Forwarder 2| +--|CS-ID 1 |
: +----------------+ |CIS-ID 2|
+--------+ : | +--------+
| Client | : Network +----------------------+
+--------+ : metrics | +-------+ |
| : :<---------| C-NMA | |
| : : | +-------+ |
+---------------------+ | |
|CATS-Forwarder 1|C-PS|----| |
+---------------------+ | Underlay |
: | Infrastructure | +--------+
: | | |CS-ID 1 |
: +----------------------+ +---|CIS-ID 3|
: | | +--------+
: +----------------+ +-------+
: |CATS-Forwarder 3|--| C-SMA | Service Site 3
: +----------------+ +-------+
: : | +-------+
: : +---|CS-ID 2|
: : +-------+
:<-------------------------------:
Service CS-ID 1, instance CIS-ID 3
Service CS-ID 2,
]]>The example in mainly
describes a per-instance computing-related metric distribution. In the
case of distributing aggregated per-site computing-related metrics,
the per-instance CIS-ID information will not be included in the
advertisement. Instead, a per-site CIS-ID may be used in case multiple
sites are connected to the Egress CATS-Forwarder to explicitly
indicate the site from where the aggregated metrics come.If the CATS framework is implemented using a centralized model, the
metric can be, e.g., distributed as illustrated in .An Example of CATS Metric Distribution in a Centralized
Model
Service CS-ID 1, instance CIS-ID 2
Service CS-ID 1, instance CIS-ID 3
Service CS-ID 2,
: +------+
:<------| C-PS |<----------------------------------+
: +------+ <------+ +--------+ |
: ^ | +--|CS-ID 1 | |
: | | | |CIS-ID 1| |
: | +----------------+ | +--------+ |
: | | C-SMA |---|Service Site 2|
: | +----------------+ | +--------+ |
: | |CATS-Forwarder 2| +--|CS-ID 1 | |
: | +----------------+ |CIS-ID 2| |
+--------+ : | | +--------+ |
| Client | : Network | +----------------------+ |
+--------+ : metrics | | +-------+ | |
| : +-----| C-NMA | | +-----+
| : | | +-------+ | |C-SMA|<-+
+----------------+ <---+ | | +-----+ |
|CATS-Forwarder 1|---------| | ^ |
+----------------+ | Underlay | | |
: | Infrastructure | +--------+|
: | | |CS-ID 1 ||
: +----------------------+ +--|CIS-ID 3||
: | | +--------+|
: +----------------+------------+ |
: |CATS-Forwarder 3| Service Site 3 |
: +----------------+ |
: | : +-------+ |
: +-------:------|CS-ID 2|-----+
: : +-------+
:<-------------------------------:
Service CS-ID 1, instance CIS-ID 3
Service CS-ID 2
]]>If the CATS framework is implemented using an hybrid model, the
metric can be distributed, e.g., as illustrated in the . For example, the metrics 1,2,3 associated
with the CS-ID1 are collected by the centralized C-PS, and the metrics
4 and 5 are distributed via distributed protocols to the ingress
CATS-Forwarder directly. For a service with CS-ID2, all the metrics
are collected by the centralized C-PS. The CATS-computed path result
will be distributed to the Ingress CATS-Forwarders from the C-PS by
considering both the metrics from the C-SMA and C-NMA. Furthermore,
the Ingress CATS-Forwarder may also have some ability to compute the
path for the subsequent service accessing packets.An Example of CATS Metric Distribution in Hybrid Model
Service CS-ID 1, instance CIS-ID 2
Service CS-ID 1, instance CIS-ID 3
Service CS-ID 2,
: +------+
:<------| C-PS |<----------------------------------+
: +------+ <------+ +--------+ |
: ^ | +--|CS-ID 1 | |
: | | | |CIS-ID 1| |
: | +----------------+ | +--------+ |
: | | C-SMA |---|Service Site 2|
: | +----------------+ | +--------+ |
: | |CATS-Forwarder 2| +--|CS-ID 1 | |
: | +----------------+ |CIS-ID 2| |
+--------+ : | | +--------+ |
| Client | : Network | +----------------------+ |
+--------+ : metrics | | +-------+ | |
| : +-----| C-NMA | | +-----+
| : | | +-------+ | |C-SMA|<-+
+----------------+ <---+ | | +-----+ |
|CATS-Forwarder 1|---------| | ^ |
|----------------+ | Underlay | | |
|C-PS| : | Infrastructure | +--------+|
+----+ : | | |CS-ID 1 ||
: +----------------------+ +--|CIS-ID 3||
: | | +--------+|
: +----------------+------------+ |
: |CATS-Forwarder 3| Service Site 3 |
: +----------------+ |
: | : +-------+ |
: +-------:------|CS-ID 2|-----+
: : +-------+
:<-------------------------------:
Service CS-ID 1, instance CIS-ID 3,
Service CS-ID 2
]]>Service Access ProcessingA C-PS computes paths that lead to Egress CATS-Forwarders according
to both service and network metrics that were advertised. A C-PS may
be collocated with an Ingress CATS-Forwarder (as shown in ) or logically centralized (in a
centralized model or hybrid model).This document does not specify any algorithm for path computation
and selection purposes to be supported by C-PSes. These algorithms are
out of the scope of this document. However, it is expected that a
service request or local policy may feed the C-PS computation logic
with Objective Functions that provide some information about the path
characteristics (e.g., in terms of maximum latency) and the selected
service contact instance.In the example shown in ,
the client sends a service access via the network through the
"CATS-Forwarder 1", which is an Ingress CATS-Forwarder. Note that, a
service access may consist of one or more service packets (e.g.,
Session Initiation Protocol (SIP) , HTTP , IPv6 , SRv6 or Real-Time Streaming Protocol (RTSP) ) that carry the CS-ID and potential parameters. The
Ingress CATS-Forwarder classifies the packets using the information
provided by the CATS classifier (C-TC). When a matching classification
entry is found for the packets, the Ingress CATS-Forwarder
encapsulates and forwards them to the C-PS selected Egress
CATS-Forwarder. When these packets reach the Egress CATS-Forwarder,
the outer header of the possible overlay encapsulation will be removed
and the inner packets will be sent to the relevant service contact
instance.
Note that multi-homed clients may be connected to multiple CATS
infrastructures that may be operated by the same or distinct
service providers. This version of the framework does not cover
multihoming specifics.
Service Contact Instance AffinityInstance affinity means that packets that belong to a flow
associated with a service should always be sent to the same service
contact instance. Furthermore, packets of a given flow should be
forwarded along the same path to avoid mis-ordering and to prevent the
introduction of unpredictable latency variations. Specifically, the
same Egress CATS-Forwarder may be sollicited to forward the
packets.The affinity is determined at the time of newly formulated service
requests.Note that different services may have different notions of what
constitutes a 'flow' and may, thus, identify a flow differently.
Typically, a flow is identified by the 5-tuple transport coordinates
(source and destination addresses, source and destination port
numbers, and protocol). However, for instance, an RTP video stream may
use different port numbers for video and audio channels: in that case,
affinity may be identified as a combination of the two 5-tuple flow
identifiers so that both flows are addressed to the same service
contact instance.Hence, when specifying a protocol to communicate information about
service contact instance affinity, a certain level of flexibility for
identifying flows should be supported. Or, from a more general
perspective, there should be a flexible mechanism to specify and
identify the set of packets that are subject to a service contact
instance affinity.More importantly, the means for identifying a flow for the purpose
of ensuring instance affinity should be application-independent to
avoid the need for service-specific instance affinity methods.
However, service contact instance affinity information may be
configurable on a per-service basis. For each service, the information
can include the flow/packets identification type and means, affinity
timeout value, etc.This document does not define any mechanism for defining or
enforcing service contact instance affinity.Security ConsiderationsThe computing resource information changes over time very frequently,
especially with the creation and termination of service contact
instances. When such an information is carried in a routing protocol,
too many updates may affect network stability. This issue could be
exploited by an attacker (e.g., by spawning and deleting service contact
instances very rapidly). CATS solutions must support guards against such
misbehaviors. For example, these solutions should support aggregation
techniques, dampening mechanisms, and threshold-triggered distribution
updates.The information distributed by the C-SMA and C-NMA agents may be
sensitive. Such information could indeed disclose intel about the
network and the location of compute resources hosted in service sites.
This information may be used by an attacker to identify weak spots in an
operator's network. Furthermore, such information may be modified by an
attacker resulting in disrupted service delivery for the clients, up to
and including misdirection of traffic to an attacker's service
implementation. CATS solutions must support authentication and
integrity-protection mechanisms between C-SMAs/C-NMAs and C-PSes, and
between C-PSes and Ingress CATS-Forwarders. Also, C-SMA agents need to
support a mechanism to authenticate the services for which they provide
information to C-PS computation logics, among other CATS functions.Privacy ConsiderationsMeans to prevent that on-path nodes in the underlay infrastructure to
fingerprint and track clients (e.g., determine which client accesses
which service) must be supported by CATS solutions. More generally,
personal data must not be exposed to external parties by CATS beyond
what is carried in the packet that was originally issued by the
client.Since the service will, in some cases, need to know about
applications, clients, and even user identity, it is likely that the
C-PS computed path information will need to be encrypted if the
client/service communication is not already encrypted.For more discussion about privacy, refer to
and .IANA ConsiderationsThis document makes no requests for IANA action.Informative ReferencesComputing-Aware Traffic Steering (CATS) Problem Statement,
Use Cases, and RequirementsChina MobileHuawei TechnologiesOrangeTelefonicaHuawei TechnologiesHuawei TechnologiesChina UnicomAlibaba GroupDistributed computing is a tool that service providers can use
to achieve better service response time and optimized energy
consumption. In such a distributed computing environment,
providing services by utilizing computing resources hosted in
various computing facilities aids support of services such as
computationally intensive and delay sensitive services. Ideally,
compute services are balanced across servers and network resources
to enable higher throughput and lower response times. To achieve
this, the choice of server and network resources should consider
metrics that are oriented towards compute capabilities and
resources instead of simply dispatching the service requests in a
static way or optimizing solely on connectivity metrics. The
process of selecting servers or service instance locations, and of
directing traffic to them on chosen network resources is called
"Computing-Aware Traffic Steering" (CATS). This document provides
the problem statement and the typical scenarios for CATS, which
shows the necessity of considering more factors when steering
traffic to the appropriate computing resource to best meet the
customer's expectations and deliver the requested service.Overview and Principles of Internet Traffic
EngineeringOld Dog ConsultingThis document describes the principles of traffic engineering
(TE) in the Internet. The document is intended to promote better
understanding of the issues surrounding traffic engineering in IP
networks and the networks that support IP networking, and to
provide a common basis for the development of traffic engineering
capabilities for the Internet. The principles, architectures, and
methodologies for performance evaluation and performance
optimization of operational networks are also discussed. This work
was first published as RFC 3272 in May 2002. This document
obsoletes RFC 3272 by making a complete update to bring the text
in line with best current practices for Internet traffic
engineering and to include references to the latest relevant work
in the IETF.Service Function Chaining (SFC) ArchitectureThis document describes an architecture for the specification,
creation, and ongoing maintenance of Service Function Chains
(SFCs) in a network. It includes architectural concepts,
principles, and components used in the construction of composite
services through deployment of SFCs, with a focus on those to be
standardized in the IETF. This document does not propose
solutions, protocols, or extensions to existing protocols.BGP - Link State (BGP-LS) Advertisement of IGP Traffic
Engineering Performance Metric ExtensionsThis document defines new BGP - Link State (BGP-LS) TLVs in
order to carry the IGP Traffic Engineering Metric Extensions
defined in the IS-IS and OSPF protocols.A Path Computation Element (PCE)-Based ArchitectureConstraint-based path computation is a fundamental building
block for traffic engineering systems such as Multiprotocol Label
Switching (MPLS) and Generalized Multiprotocol Label Switching
(GMPLS) networks. Path computation in large, multi-domain,
multi-region, or multi-layer networks is complex and may require
special computational components and cooperation between the
different network domains.This document specifies the architecture for a Path Computation
Element (PCE)-based model to address this problem space. This
document does not attempt to provide a detailed description of all
the architectural components, but rather it describes a set of
building blocks for the PCE architecture from which solutions may
be constructed. This memo provides information for the Internet
community.Provider Provisioned Virtual Private Network (VPN)
TerminologyThe widespread interest in provider-provisioned Virtual Private
Network (VPN) solutions lead to memos proposing different and
overlapping solutions. The IETF working groups (first Provider
Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have
discussed these proposals and documented specifications. This has
lead to the development of a partially new set of concepts used to
describe the set of VPN services.To a certain extent, more than one term covers the same
concept, and sometimes the same term covers more than one concept.
This document seeks to make the terminology in the area clearer
and more intuitive. This memo provides information for the
Internet community.Domain names - concepts and facilitiesThis RFC is the revised basic definition of The Domain Name
System. It obsoletes RFC-882. This memo describes the domain style
names and their used for host address look up and electronic mail
forwarding. It discusses the clients and servers in the domain
name system and the protocol used between them.OSPF for IPv6This document describes the modifications to OSPF to support
version 6 of the Internet Protocol (IPv6). The fundamental
mechanisms of OSPF (flooding, Designated Router (DR) election,
area support, Short Path First (SPF) calculations, etc.) remain
unchanged. However, some changes have been necessary, either due
to changes in protocol semantics between IPv4 and IPv6, or simply
to handle the increased address size of IPv6. These modifications
will necessitate incrementing the protocol version from version 2
to version 3. OSPF for IPv6 is also referred to as OSPF version 3
(OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for
IPv6 as described herein include the following. Addressing
semantics have been removed from OSPF packets and the basic Link
State Advertisements (LSAs). New LSAs have been created to carry
IPv6 addresses and prefixes. OSPF now runs on a per-link basis
rather than on a per-IP-subnet basis. Flooding scope for LSAs has
been generalized. Authentication has been removed from the OSPF
protocol and instead relies on IPv6's Authentication Header and
Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6
are almost as compact as those in OSPF for IPv4. Most fields and
packet- size limitations present in OSPF for IPv4 have been
relaxed. In addition, option handling has been made more
flexible.All of OSPF for IPv4's optional capabilities, including demand
circuit support and Not-So-Stubby Areas (NSSAs), are also
supported in OSPF for IPv6. [STANDARDS-TRACK]SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an
application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include Internet telephone calls, multimedia
distribution, and multimedia conferences. [STANDARDS-TRACK]HTTP/1.1The Hypertext Transfer Protocol (HTTP) is a stateless
application-level protocol for distributed, collaborative,
hypertext information systems. This document specifies the
HTTP/1.1 message syntax, message parsing, connection management,
and related security concerns.This document obsoletes portions of RFC 7230.Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol
(IPv6). It obsoletes RFC 2460.IPv6 Segment Routing Header (SRH)Segment Routing can be applied to the IPv6 data plane using a
new type of Routing Extension Header called the Segment Routing
Header (SRH). This document describes the SRH and how it is used
by nodes that are Segment Routing (SR) capable.Real-Time Streaming Protocol Version 2.0This memorandum defines the Real-Time Streaming Protocol (RTSP)
version 2.0, which obsoletes RTSP version 1.0 defined in RFC
2326.RTSP is an application-layer protocol for the setup and control
of the delivery of data with real-time properties. RTSP provides
an extensible framework to enable controlled, on-demand delivery
of real-time data, such as audio and video. Sources of data can
include both live data feeds and stored clips. This protocol is
intended to control multiple data delivery sessions; provide a
means for choosing delivery channels such as UDP, multicast UDP,
and TCP; and provide a means for choosing delivery mechanisms
based upon RTP (RFC 3550).Report from the Internet Privacy WorkshopOn December 8-9, 2010, the IAB co-hosted an Internet privacy
workshop with the World Wide Web Consortium (W3C), the Internet
Society (ISOC), and MIT's Computer Science and Artificial
Intelligence Laboratory (CSAIL). The workshop revealed some of the
fundamental challenges in designing, deploying, and analyzing
privacy-protective Internet protocols and systems. Although
workshop participants and the community as a whole are still far
from understanding how best to systematically address privacy
within Internet standards development, workshop participants
identified a number of potential next steps. For the IETF, these
included the creation of a privacy directorate to review
Internet-Drafts, further work on documenting privacy
considerations for protocol developers, and a number of
exploratory efforts concerning fingerprinting and anonymized
routing. Potential action items for the W3C included investigating
the formation of a privacy interest group and formulating guidance
about fingerprinting, referrer headers, data minimization in APIs,
usability, and general considerations for non-browser-based
protocols.Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect
the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is
not an Internet Standards Track specification; it is published for
informational purposes.Privacy Considerations for Internet ProtocolsThis document offers guidance for developing privacy
considerations for inclusion in protocol specifications. It aims
to make designers, implementers, and users of Internet protocols
aware of privacy-related design choices. It suggests that whether
any individual RFC warrants a specific privacy considerations
section will depend on the document's content.Computing and Network Information Awareness (CNIA) system
architecture for CATSChina MobileRuijie NetworksChina MobileNew H3C TechnologiesNew H3C TechnologiesThis document describes a Computing and Network Information
Awareness (CNIA)system architecture for Computing-Aware Traffic
Steering (CATS). Based on the CATS framework, this document
further describes a proposal detailed awareness architecture about
the network information and computing information. It includes a
new component and the corresponding interfaces and workflows in
the CATS control plane.AcknowledgementsThe authors would like to thank Joel Halpern, John Scudder, Dino
Farinacci, Adrian Farrel, Cullen Jennings, Linda Dunbar, Jeffrey Zhang,
Peng Liu, Fang Gao, Aijun Wang, Cong Li, Xinxin Yi, Jari Arkko, Mingyu
Wu, Haibo Wang, Xia Chen, Jianwei Mao, Guofeng Qian, Zhenbin Li, Xinyue
Zhang, and Nagendra Kumar for their comments and suggestions.Some text about various deployment models was originally documented
in .ContributorsZTEhuang.guangping@zte.com.cnVerizon Inc.hayabusagsm@gmail.comChina Mobileyaohuijuan@chinamobile.comHuawei Technologiesliyizhou@huawei.comHuawei Technologiesdirk.trossen@huawei.comHuawei Technologiesluigi.iannone@huawei.comHuawei Technologiesshihang9@huawei.comNew H3C Technologieslinchangwang.04414@h3c.comCICTxswang@fiberhome.comRuijie Networkswangxuewei1@ruijie.com.cnOrangechristian.jacquenet@orange.com