Network Working Group Z. Li
Internet-Draft S. Peng
Intended status: Standards Track Huawei Technologies
Expires: November 26, 2021 D. Voyer
Bell Canada
C. Xie
China Telecom
P. Liu
China Mobile
Z. Qin
China Unicom
G. Mishra
Verizon Inc.
K. Ebisawa
Toyota Motor Corporation
S. Previdi
Huawei Technologies
J. Guichard
Futurewei Technologies Ltd.
May 25, 2021
Problem Statement and Use Cases of Application-aware Networking (APN)
draft-li-apn-problem-statement-usecases-02
Abstract
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 unware 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 satifying 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.
Li, et al. Expires November 26, 2021 [Page 1]
Internet-Draft Problem Statement and Use cases of APN May 2021
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 26, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Challenges of lack of fine-granularity service
information . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Challenges of Traditional Differentiated Service
Provisioning . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Challenges of Supporting New 5G and Edge Computing
Li, et al. Expires November 26, 2021 [Page 2]
Internet-Draft Problem Statement and Use cases of APN May 2021
Technologies . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Elements of Application-aware Networking (APN) . . . . . 7
5. Use cases for Application-aware Networking (APN) . . . . . . 8
5.1. Application-aware SLA Guarantee . . . . . . . . . . . . . 8
5.2. Application-aware network slicing . . . . . . . . . . . . 8
5.3. Application-aware Deterministic Networking . . . . . . . 9
5.4. Application-aware Service Function Chaining . . . . . . . 10
5.5. Application-aware Network Measurement . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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 use cases are
described in this document. APN takes advantage of network
programmability by conveying application related information in the
data plane to facilitate network operators to provide fine-grained
services.
2. Terminology
ACL: Access Control List
APN: Application-aware Networking
APN6: Application-aware Networking for IPv6/SRv6
DPI: Deep Packet Inspection
PBR: Policy Based Routing
QoE: Quality of Experience
SDN: Software Defined Networking
SLA: Service Level Agreement
Li, et al. Expires November 26, 2021 [Page 3]
Internet-Draft Problem Statement and Use cases of APN May 2021
MPLS: Multiprotocol Label Switching
SR: Segment Routing
SRv6: Segment Routing over IPv6 dataplane
SR-MPLS: Segment Routing over MPLS dataplane
VPN: Virtual Private Network
TE: Traffic Engineering
FRR: Fast Reroute
CAPEX: Capital expenditures
OPEX: Operating expenditures
3. Problem Statement
This 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.
3.1. Challenges of lack of fine-granularity service information
In today's networks, the infrastructure through which the traffic is
forwarded is not able to obtain the fine-granularity service
information. 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 to satisfy
their SLA requirements.
Li, et al. Expires November 26, 2021 [Page 4]
Internet-Draft Problem Statement and Use cases of APN May 2021
Network Slicing: provides the ability to define a number of network
slices with guaranteed resources to satisfy highly demanding service
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
utilised, 3) a fine-granularity service scheduling and measurement
cannot be achieved.
3.2. Challenges of Traditional Differentiated Service Provisioning
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:
1. 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.
2. 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.
3. 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:
Li, et al. Expires November 26, 2021 [Page 5]
Internet-Draft Problem Statement and Use cases of APN May 2021
A. The whole loop is long and time-consuming which is not
suitable for fast service provisioning for critical
applications;
B. Too many interfaces are involved in the loop, as shown in
Figure 1, which introduce challenges of standardization and
inter-operability.
+--------------+
+-----| Orchestrator | -------------------+
| +--------------+ Resource |
APP Req. | | Management |
+---------+ +---------+ & +---------+
|SDN Ctrl1| |SDN Ctrl2| Service |SDN Ctrl3|
+---------+ +---------+ Provisioning +---------+
App Req./ | | \ | \
/ | | \ | \
/ | | \ | \
+---+ +-----+ +--------+ +-------+ +-------+ +-------+
|APP| | DCN | |Network |..|Network| |Network|..|Network|
+---+ +-----+ | D1 | | D3 | | D4 | | D6 |
+--------+ +-------+ +-------+ +-------+
Figure 1: Multiple interfaces involved in the long service-
provisioning loop
In [I-D.peng-apn-scope-gap-analysis], 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.
3.3. Challenges of Supporting New 5G and Edge Computing Technologies
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.
Li, et al. Expires November 26, 2021 [Page 6]
Internet-Draft Problem Statement and Use cases of APN May 2021
4. Key Elements of Application-aware Networking (APN)
Application-aware Networking (APN) aims to address the problems
mentioned in Section 3, 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). APN ID can be derived through the mapping from the
existing information of the packet header and the APN parameters can
be applied for the APN ID according to the local policy. The typical
APN parameters are the network performance requirements.
APN has the following key elements:
1. 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.
2. 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.
3. 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.
Li, et al. Expires November 26, 2021 [Page 7]
Internet-Draft Problem Statement and Use cases of APN May 2021
APN Network
Element 1: Conveying ------------------->
/|\
APN attribute | Network capabilities
| (SLA guarantee)
| /|\
Element 2: Matching |
|
Element 3: Network Measurement
Figure 2: Illustration of the key elements of APN
5. Use cases for Application-aware Networking (APN)
This section illustrates some of the use cases that can benefit from
APN. The corresponding requirements for APN are also outlined.
5.1. Application-aware SLA Guarantee
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. Differentiated service provisioning is also desired.
The APN architecture MUST address the following requirements:
o APN needs to perform the three key elements as described in
Section 4.
o Support application group-level fine-granularity traffic operation
that may include finer QoS scheduling.
5.2. Application-aware network slicing
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
Li, et al. Expires November 26, 2021 [Page 8]
Internet-Draft Problem Statement and Use cases of APN May 2021
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 architecture MUST address the following requirements:
o APN needs to perform the three key elements as described in
Section 4 in the context of network slicing.
o For the element 2, the APN architecture MUST allow to assign a
given traffic flow to specific network slice according to the APN
attribute carried in the APN packet.
o For the element 3, the APN architecture MUST allow the network
measurement of each network slice.
5.3. Application-aware Deterministic Networking
[RFC8578] 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 architecture MUST address the following requirements:
o APN needs to perform the three key elements as described in
Section 4 in the context of deterministic networking.
o For the element 2, the APN architecture MUST allow to assign a
given traffic flow to a specific deterministic path according to
the APN attribute carried in the APN packet.
o For the element 3, the APN architecture MUST allow the network
measurement of each application-aware deterministic path.
Li, et al. Expires November 26, 2021 [Page 9]
Internet-Draft Problem Statement and Use cases of APN May 2021
5.4. Application-aware Service Function Chaining
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) [RFC7665].
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 architecture MUST address the following requirements:
o APN needs to perform the three key elements as described in
Section 4 in the context of service function chaining.
o For the element 1, class information can be conveyed.
o For the element 2, the APN architecture 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.
o For the element 3, the APN architecture MUST allow the network
measurement of each application-aware service function chain.
5.5. Application-aware Network Measurement
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 architecture MUST address the following requirements:
o APN needs to perform the two key elements as described in
Section 4 in the context of network measurement. The network
measurement in the element 3 does not need to be considered here.
Li, et al. Expires November 26, 2021 [Page 10]
Internet-Draft Problem Statement and Use cases of APN May 2021
6. IANA Considerations
This document does not include an IANA request.
7. Security Considerations
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.
8. Acknowledgements
The authors would like to acknowledge Robert Raszuk (Bloomberg LP)
and Yukito Ueno (NTT Communications Corporation) for their valuable
review and comments.
9. Contributors
Daniel Bernier
Bell Canada
Canada
Email: daniel.bernier@bell.ca
Liang Geng
China Mobile
China
Li, et al. Expires November 26, 2021 [Page 11]
Internet-Draft Problem Statement and Use cases of APN May 2021
Email: gengliang@chinamobile.com
Chang Cao
China Unicom
China
Email: caoc15@chinaunicom.cn
Chang Liu
China Unicom
China
Email: liuc131@chinaunicom.cn
Cong Li
China Telecom
China
Email: licong@chinatelecom.cn
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
10.2. Informative References
Li, et al. Expires November 26, 2021 [Page 12]
Internet-Draft Problem Statement and Use cases of APN May 2021
[]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), October 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Garvia, P. C., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", draft-ietf-spring-srv6-
network-programming-28 (work in progress), December 2020.
[I-D.peng-apn-scope-gap-analysis]
Peng, S. and Z. Li, "APN Scope and Gap Analysis", draft-
peng-apn-scope-gap-analysis-01 (work in progress),
February 2021.
Authors' Addresses
Zhenbin Li
Huawei Technologies
China
Email: lizhenbin@huawei.com
Shuping Peng
Huawei Technologies
China
Email: pengshuping@huawei.com
Daniel Voyer
Bell Canada
Canada
Email: daniel.voyer@bell.ca
Chongfeng Xie
China Telecom
China
Email: xiechf@chinatelecom.cn
Li, et al. Expires November 26, 2021 [Page 13]
Internet-Draft Problem Statement and Use cases of APN May 2021
Peng Liu
China Mobile
China
Email: liupengyjy@chinamobile.com
Zhuangzhuang Qin
China Unicom
China
Email: qinzhuangzhuang@chinaunicom.cn
Gyan Mishra
Verizon Inc.
USA
Email: gyan.s.mishra@verizon.com
Kentaro Ebisawa
Toyota Motor Corporation
Japan
Email: ebisawa@toyota-tokyo.tech
Stefano Previdi
Huawei Technologies
Italy
Email: stefano@previdi.net
James N Guichard
Futurewei Technologies Ltd.
USA
Email: jguichar@futurewei.com
Li, et al. Expires November 26, 2021 [Page 14]