Problem Statement
and Use Cases of Application-aware Networking (APN)Huawei TechnologiesChinalizhenbin@huawei.comHuawei TechnologiesChinapengshuping@huawei.comBell CanadaCanadadaniel.voyer@bell.caChina TelecomChinaxiechf@chinatelecom.cnChina MobileChinaliupengyjy@chinamobile.comChina UnicomChinaqinzhuangzhuang@chinaunicom.cnVerizon Inc.USAgyan.s.mishra@verizon.com
Routing
Network operators are facing the challenge of providing better
network services for users. As the ever-developing 5G and industrial
verticals evolve, more and more services that have diverse network
requirements such as ultra-low latency and high reliability are
emerging, and therefore differentiated service treatment is desired by
users. On the other hand, as network technologies such as Hierarchical
QoS (H-QoS), SR Policy, and Network Slicing keep evolving, the network
has the capability to provide more fine-granularity differentiated
services. However, network operators are typically unaware of the
applications that are traversing their network infrastructure, which
means that not very effective differentiated service treatment can be
provided to the traffic flows. As network technologies evolve including
deployments of IPv6, SRv6, Segment Routing over MPLS dataplane, the
programmability provided by IPv6 and Segment Routing can be augmented by
conveying application related information into the network satisfying the
fine-granularity requirements.This document analyzes the existing problems caused by lack of
service awareness, and outlines various use cases that could benefit
from an Application-aware Networking (APN) framework.Due to the requirement for differentiated traffic treatment driven by
diverse new services, the ability to convey the application-aware
information and program the network infrastructure accordingly to
provide fine-grained services is becoming increasingly necessary for
network operators. The Application-aware Networking (APN) framework is
being defined to address the requirements and some use cases are described in
this document. APN takes advantage of network programmability by
conveying application related information in the data plane so to
facilitate network operators in providing fine-grained services.One of the key objectives of APN is for network operators to provide
fine-granularity SLA guarantees instead of coarse-grain traffic
operations. This will allow to provide differentiated services for
different applications and increase revenue accordingly. Among
various applications being carried and running in the network, some
revenue-producing applications such as online gaming, video
streaming, and enterprise video conferencing have much more demanding
performance requirements such as low network latency and high
bandwidth. In order to achieve better Quality of Experience (QoE)
for end users and engage customers, the network needs to be able to
provide fine-granularity and even application group-level SLA
guarantee. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119RFC 8174 when, and only when, they appear in all
capitals, as shown here. ACL: Access Control ListAPN: Application-aware NetworkingAPN6: Application-aware Networking for IPv6/SRv6DPI: Deep Packet InspectionPBR: Policy Based RoutingQoE: Quality of ExperienceSDN: Software Defined NetworkingSLA: Service Level AgreementMPLS: Multiprotocol Label SwitchingSR: Segment RoutingSRv6: Segment Routing over IPv6 dataplaneSR-MPLS: Segment Routing over MPLS dataplaneVPN: Virtual Private NetworkTE: Traffic EngineeringFRR: Fast RerouteCAPEX: Capital expendituresOPEX: Operating expendituresThis section summarizes the challenges currently faced by network
operators when attempting to provide fine-grained traffic operations to
satisfy the various requirements demanded by new applications that
require differentiated service treatment.In today's networks, the infrastructure through which the traffic is forwarded is not able to provide fine-granularity SLAs satisfying specific requirements. It is therefore difficult for network operators to
provide fine-grained traffic operations for various
performance-demanding applications. In order to satisfy the SLA
requirements network operators continue to increase the network
bandwidth but only carrying very light traffic load (in general,
around 30%-40% of its capacity).As network technologies keep evolving, the network capability has
been greatly enhanced and is able to provide fine-granularity service
provisioning. For example,H-QoS: provides hierarchical fine-grained QoS services.SR Policy: provides the ability to handle a large number of
explicit and flexible SR paths in order for services to select the policy that satisfies their SLA requirements.Network Slicing: provides the ability to define a number of isolated network slices having different set of requirements.IOAM: provides more accurate performance measurement of the traffic
flow.In summary, driven by the ever-emerging diverse demanding services,
the lack of the fine-granularity information about the services in the
network will cause the following issues: 1) the service information is
not clearly described and known by the network, 2) the
fine-granularity service provisioning capability is not fully
utilized, 3) a fine-granularity service scheduling and measurement
cannot be achieved.The traditional ways used to provide fine-grained service
provisioning face some challenges. The network devices mainly rely on
the 5-tuple of the packets or DPI. However, there are some challenges
for these traditional methods in differentiated service
provisioning:Five Tuples used for ACL/PBR: five tuples are widely used for
ACL/PBR matching of traffic. However, these features cannot
provide enough information for the fine-grained service process,
and can only provide indirect application-level information which
needs to be translated. Generally, ACLs involve high overhead on
the forwarding process. Moreover, in some cases such as tunnel
encapsulation and IPv6 data plane with a list of extension
headers, it becomes impossible to resolve the 5 tuples due to the
transport layer information being pushed very deep in the
packet.Deep Packet Inspection (DPI): If more information is needed, it
must be extracted using DPI which can inspect deep into the
packets for application specific information. However, this will
introduce more CAPEX and OPEX for the network operator and impose
security and privacy challenges.Orchestration and SDN-based Solution: In the era of SDN,
typically, an SDN controller is used to manage and operate the
network infrastructure and orchestrator elements introduce
application requirements so that the network is programmed
accordingly. The SDN controller can be aware of the service
requirements of the applications on the network through the
interface with the orchestrator, and the service requirement is
used by the controller for traffic management over the network.
However, this method raises the following problems:The whole loop is long and time-consuming which is not
suitable for fast service provisioning for critical
applications;Too many interfaces are involved in the loop, as shown in
, which introduce challenges of
standardization and inter-operability.In , some
mechanisms that have been specified in IETF and using
attribute/identifier to perform traffic steering and service
provisioning are analyzed. The existing solutions are specific to a
particular scenario or data plane, and a generalized method used for
fine-grained service provisioning is still missing.New technologies such as 5G, IoT, and edge computing, are
continuously developing leading to more and more new types of services
accessing the network. Large volumes of network traffic with diverse
requirements such as low latency and high reliability are therefore
rapidly increasing. If traditional methods for differentiation of
traffic continue to be utilized, it will cause much higher CAPEX and
OPEX to satisfy the ever-developing applications' diverse
requirements.Application-aware Networking (APN) aims to address the problems
mentioned in , associated with
fine-grained traffic operations that are required in order to satisfy
the various application-awareness requirements demanded by new services
that need differentiated service treatment.In APN, the application-aware information (APN Attribute) is derived
according to the existing information in the packet header and
encapsulated along with the encapsulation of the tunnel. With the APN
attribute, fine-granularity network services can be provisioned within
the APN domain accordingly. The APN attribute can include
application-aware ID (APN ID) and application-aware parameters (APN
Parameters). The APN ID can be derived, and applied to the packet, through a mapping mechanism leveraging the existing
information in the packet header. The APN parameters can be applied
for the corresponding APN ID according to the local policy. The typical APN parameters
are the network performance requirements.APN has the following key elements:Application-aware information (APN attribute) is conveyed in the
data plane through augmentation of existing encapsulations such as
IPv6, SRv6 and MPLS. The conveyed APN attribute includes APN ID
and/or APN parameters. This information is acquired at the edge of
the APN domain according to the existing information in the packet
header. When a data packet uses APN and conveys the
application-aware information, it is referred in this document as an
APN packet.Application-aware information and network service provisioning
matching providing fine-granularity network service provisioning
(traffic operations) and SLA guarantee based on the APN attribute
carried in APN packets. According to the APN attribute, appropriate
network services are selected, provisioned, and provided to the
demanding applications to satisfy their service requirements.Measurement of the network performance so to maintain the match
between the applications requirements and corresponding network
services for a better fine-granularity SLA compliance. The network
measurement methods include in-band and out-of-band, passive,
active, per-packet, per-flow, per node, end-to-end, etc. These
methods can also be integrated.1. SD-WAN scenarioThe SD-WAN scenario is shown in the following figure. With APN, at
the edge node, i.e. CPE, of the SD-WAN, the 5-tuple, plus information
related to user or application group-level requirements is constructed
into the APN attribute. When the packet is sent from the CPE, the
attribute is added along with the tunnel encapsulation. This attribute
is only meaningful for the network operators to apply various policies
in different nodes/service functions, which can be enforced from the
Controllers.2. Home broadband scenarioIn the home broadband scenario, generally a home broadband user is
authorized by the BNG. If the validation is passed and the access
control is released, the user group can start enjoying the
value-added service. With APN, when the traffic traverses the metro
network, the traffic flow can be indicated by the APN attribute that is
added/removed at the edge devices of the Metro Network (APN domain)
based on the mapping from the existing information (e.g. the QinQ which
is composed of C-VLAN and S-VLAN) in the packet header and then carried
in the tunnel encapsulation header. The APN attribute will facilitate
the fine-granular service in the APN domain. Once the packets leave the
APN domain, the APN attribute will be removed together with the tunnel
encapsulation header.3. Mobile broadband scenarioIn the mobile broadband scenario, a UE is authorized by the 5GC
function, and the traffic steering and QoS policy are enforced by the
UPF (User Plane Function) node. If the validation is passed and the
access control is released, the user can start enjoying the
value-added service. With APN, when the traffic traverses the mobile
transport network, the traffic flow can be indicated by the APN
attribute that is added at the edge devices of the mobile transport
network (APN domain) based on mapping from the existing information
(e.g. GTP-u tunnel encapsulation information) in the packet header and
then carried in the tunnel encapsulation header. The APN attribute will
facilitate the fine-granular service in the APN domain. Once the packets
leave the APN domain, the APN attribute will be removed together with
the tunnel encapsulation header. This section illustrates some of the use cases that can benefit from
APN. The corresponding requirements for APN are also outlined.As stated in section 1, among
various applications being carried and running in the network, some
revenue-producing applications such as online gaming, video streaming,
and enterprise video conferencing have much more demanding performance
requirements such as low network latency and high bandwidth. In order
to achieve better Quality of Experience (QoE) for end users and engage
customers, the network needs to be able to provide fine-granularity
and even application group-level SLA guarantee. Differentiated service
provisioning is also desired.The APN framework MUST address the following requirements:APN needs to perform the three key elements as described in
.Support application group-level fine-granularity traffic
operation that may include finer QoS scheduling.More and more applications/services with diverse requirements are
being carried over and sharing a common operators' network
infrastructure. However, it is still desirable to have customized
network transport that can support some applications' specific
requirements, taking into consideration service and resource
isolation, which drives the concept of network slicing.Network slicing provides ways to partition the network
infrastructure in either the control plane or data plane into multiple
network slices that are running in parallel. These network slices can
serve diverse services and fulfill their various requirements at the
same time. For example, the mission critical application that requires
ultra-low latency and high reliability can be provisioned over a
separate network slice.The APN framework MUST address the following requirements:APN needs to perform the three key elements as described in
in the context of network
slicing.For the element 2, the APN framework MUST allow to assign a
given traffic flow to specific network slice according to the APN
attribute carried in the APN packet.For the element 3, the APN framework MUST allow the network
measurement of each network slice. documents use cases for diverse industry
applications that require deterministic flows over multi-hop paths.
Deterministic flows provide guaranteed bandwidth, bounded latency, and
other properties relevant to the transport of time-sensitive data, and
can coexist on an IP network with best-effort traffic. It also
provides for highly reliable flows through provision for redundant
paths.The APN framework MUST address the following requirements:APN needs to perform the three key elements as described in
in the context of deterministic
networking.For the element 2, the APN framework MUST allow to assign a
given traffic flow to a specific deterministic path according to
the APN attribute carried in the APN packet.For the element 3, the APN framework MUST allow the network
measurement of each application-aware deterministic path.End-to-end service delivery often needs to go through various
service functions including traditional network service functions such
as firewalls, DPIs as well as new application-specific functions, both
physical and virtual. The definition and instantiation of an ordered
set of service functions and subsequent steering of the traffic
through them is called Service Function Chaining (SFC) . SFC is applicable to both fixed and mobile
networks as well as data center networks.Generally, in order to manipulate a specific traffic flow along the
SFC, a DPI needs to be deployed as the first service function of the
chain to detect the application, which will impose high CAPEX and
consume long processing time. For encrypted traffic, it even becomes
impossible to inspect the traffic flow.The APN framework MUST address the following requirements:APN needs to perform the three key elements as described in
in the context of service function
chaining.For the element 1, class information can be conveyed.For the element 2, the APN framework MUST allow to assign a
given traffic flow to a specific service function chain and MUST
allow the subsequent steering according to the APN attribute
carried in the APN packets.For the element 3, the APN framework MUST allow the network
measurement of each application-aware service function chain.Network measurement can be used for locating silent failure and
predicting QoE satisfaction, which enables real-time SLA
awareness/proactive OAM. Operations, Administration, and Maintenance
(OAM) refers to a toolset for fault detection and isolation, and
network performance measurement. In-situ Operations, Administration,
and Maintenance (IOAM) records operational and telemetry information
in the packet while the packet traverses a path between two points in
the network.The APN framework MUST address the following requirements:APN needs to perform the two key elements as described in in the context of network measurement. The
network measurement in the element 3 does not need to be
considered here.This document does not include an IANA request.In the APN work, in order to reduce the privacy and security issues,
the APN attribute MUST be conveyed along with the tunnel information in
the APN domain. The APN attribute is encapsulated and removed at the
edge of the APN domain. The APN ID MUST be acquired from the existing
available information in the packet header without interference into the
payload.According to the above specifications, the APN attribute is only
produced and used locally within the APN domain without the involvement
of the host/application side.In order to prevent the malicious attack through the APN attribute,
the following policies can be configured at the network devices of the
APN domain. If the APN attribute is conveyed without the tunnel
information, the packet MUST be dropped. If the APN attributes are not
known to the APN domain, it should trigger the alarm information. The
packet can be forwarded without being processed or dropped depending on
the local policy. If the network service requirements exceed the
specification for the specific APN ID, it should trigger the alarm
information. The packet should be discarded to prevent abusing of the
resources. There should be rate-limiting policy at the edge of the APN
domain to prevent the traffic belonging to a specific APN ID from
exceeding the preset limit.The authors would like to acknowledge Robert Raszuk (Bloomberg LP)
and Yukito Ueno (NTT Communications Corporation) for their valuable
review and comments.Email: ebisawa@toyota-tokyo.techEmail: stefano@previdi.netEmail: jguichar@futurewei.comEmail: daniel.bernier@bell.caEmail: gengliang@chinamobile.comEmail: caoc15@chinaunicom.cnEmail: liuc131@chinaunicom.cnEmail: licong@chinatelecom.cn