| Internet-Draft | Requirements and Use Cases | October 2022 |
| Zhou, et al. | Expires 25 April 2023 | [Page] |
This draft introduces the new challenges for the network brought by massive access services under the background of the convergence of the cloud and the network which acquires the network to identify and convey the information of fine-grain user and application requirements, aiming to fulfill differentiated service provisioning and improve the comprehensive utilization of network resources. The draft raises the scope of current solution gap analysis and further proposes the definition of DB-ORS in which network capabilities are abstracted as atomic services and can be orchestrated by applications. Scenarios of cloud access and DCI are outlined to clarify the concepts and principles of DB-ORS in overcoming challenges.¶
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 25 April 2023.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Currently, network always provides best-effort services for application endpoints. When the network generally stays a light-weight load status, most requirements from the clients can be satisfied within best-effort traffic.¶
With the rapid development and comprehensive utilization of cloud computing and mobile Internet, cloud becomes a popular and major platform for various enterprises and government departments to host data and applications. Data explosion and massive access to the cloud have been proved to be an inevitable inclination, resulting in accelerating growth of traffic traversing through the network domain to the cloud. Conventional networks which provide carrier-class connections are confronted with serious challenges which can be concluded as follows:¶
Fine-granularity services provisioning :¶
Conventional networks only provide customers with coarse-grained connection services. However, massive access services have proposed different requirements of multiple attributes including network delays, jitters, and bandwidths. An existing 5-tuple-based network service differentiation manner is not able to provide fine-granularity SLAs satisfying specific requirements. Services which are insensitive to network qualities may be served overly, however, diversified and flexible requirements cannot be guaranteed, resulting in a waste of network resources. Thus, network capabilities should be orchestrated in accordance with acquired requirements to achieve fine-granularity services provisioning.¶
Network resources utilization enhancement :¶
Since the growth of traffic traversing through the network domain into the cloud and the accelerating number of deployed, sufficient network capacity and bandwidth resources are urgently demanded. However, the network resources are not orchestrated appropriately and the resource utilization proves to be relatively low for about 30% -50%. Therefore, enhancing network resources utilization requires other solutions.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
With the increase of cloud services, various applications with diversity put forward differentiated requirements. Popular applications such as VR/AR, cloud games, and industrial Internet require high-quality network experiences. Therefore, quick access to the cloud has proved to be a basic requirement. Under these circumstances, cloud service providers always establish multiple POP access points in different areas to improve the convenience for clients, and configures MPLS dedicated lines from POP points to the data center for satisfying network performance. However, existing problems in the current strategy are clarified below:¶
SD-WAN handles this problem by monitoring the latency of multiple backup paths by applying a dynamic multipath optimization algorithm, which enables traffic to be automatically steered into the most appropriate path at any given time.¶
However, dynamic multipath optimization algorithms require traffic detection techniques to obtain information such as bandwidth, delay, and jitter of multiple reachable paths, so as to support SD-WAN to implement path orchestration and routing calculation. Accuracy and immediacy can hardly be guaranteed simply by statistics collected by current traffic detection techniques. Thus, when instantaneous jitter occurs on a monitored link, the current traffic is usually switched over to a standby path, which results in a waste of network resources. Furthermore, the introduction of network probing schemes also exerts extra burden on the network.¶
SD-WAN is also capable of configuring different priorities in accordance with requirements from the client, and further generate and publish the corresponding QoS policies to ensure service delivery. Latency-sensitive traffic such as VoIP and web conferencing are configured with higher priority and is further steered into specific paths with better performance, while services like file backups are assigned lower priority since they are less time-sensitive and may even result in blocks on network links.¶
Conventional service identification and diversion policies based on 5-tuple (source IP address, destination IP address, source port, destination port, and protocol), configured priorities, or VlanID have respective defects attributed to the lack of fine-granularity information.¶
To sum up, the deficiencies of the current solutions lie in the fact that the network presents a "black box" status for applications, which results in the failure to make optimal utilization of network capabilities. Although option-based extensible capabilities of SRv6 are introduced to enhance the perception ability of the network and Segment List based orchestration methods are performed to extend the routing capability, problems stay unsolved since the cloud and the network are administered independently and SRv6 policies can not traverse the boundaries between different domains.¶
Under current circumstances, besides bandwidth resources, the network is granted with multiple capabilities such as deterministic capability, service function chaining, and network slicing. Suppose the network exposes these capabilities as services and is assisted with the programmable abilities by SRv6, applications which subscribe a specific service can orchestrate these services of the network. With the network capabilities abstracted and services subscription, the utilization of the entire network resources can be greatly improved and the applications can be served in a fine-granularity manner.¶
Definitions of network capabilities, such as bandwidth link, determinism, security abilities, and network slicing, methods to open these abilities and to subscribe the services are covered and included in the framework of DB-ORS, aiming to enable applications to understand the current "black box" status of the network domain. Implementations and components in DB-ORS include network capabilities abstraction, service subscription and service orchestration.¶
As shown in Figure 1, suppose APP1 has strict requirements of low network delay while APP2 can tolerate relatively unsatisfied network conditions. The traffic from APP2 traverses the underlay network and reaches the data center through the edge device. Ideally, traffic from APP1 is steered into underlay network 1 to cloud gateway of SaaS_A1 since the network path of underlay network 1 has low latency and high bandwidth. For APP2, traffic is commonly steered into SaaS_A2. However, the mentioned scheduling strategy is difficult to fulfill by existing issues. With the introduction of DB-ORS and SRv6 policies, not only the traffic from APP1 can be steered to corresponding cloud gateway along the underlay network 1, but also the traffic from APP2 can be guided with the identical path when network resources are sufficient in network 1, thus improving the resource utilization. Suppose underlay network 1 experiences a short jitter and delay of the path increases, to ensure the access experience of the APP1, on one hand, traffic from APP1 is switched to a standby path, and at the same time, traffic from APP2 is switched immediately to another data center along the path of underlay network 2. In conclusion, the framework of DB-ORS improves the utilization of network resources in cloud access scenarios.¶
.-----. .-----.
( ) ( )
.--( )--. .--( )--.
( ) ( )
( SaaS_A1 ) ( SaaS_A2 )
( ) ( )
( ) ( )
.-----------------. .-----------------.
^ ^
| |
| |
+-----+-----+ +--------------+ +-----+-----+
| gateway +<--------+ Orchestrator +-------->+ gateway |
+-----+-----+ +---+---+---+--+ +-----+-----+
^ | | | ^
| +----------+ | | | +----------+ |
| | database +<-+ | +->+ database | |
.-----. +----^-----+ | +----^-----+ .-----.
( ) | | | ( )
.--( )-----+ v +-----( )--.
( ) +------+ ( )
( underlay network1 )<--------+ edge |-------->( underlay network2 )
( ) +------+ ( )
.--( )--. ^ ^ .--( )--.
( ) | | ( )
.-----. | | .-----.
| |
+-------+ | | +-------+
| APP_1 +--+ +--+ APP_2 |
+-------+ +-------+
In order to achieve high availability and better access performance of services, SaaS providers usually deployed multiple data centers among distributed regions, districts or cities and thus data synchronization between remote data centers proves to be indispensable. Commonly, dedicated lines are configured between data centers to ensure network quality. Furthermore, attempts are made to avoid remote accessing services from different places. MPLS dedicated lines are relatively costly, and the period of service deployment and provisioning is comparatively long. In addition, delays, packet losses and interruptions also still occur. Enhancing and improving infrastructures blindly or expanding the bandwidth of configured dedicated line may give rise to a waste of resources. The granularity for processing services can not achieved only based on conventional 5-tuple-based methods. As shown in Figure 2, with the introduction of DB-ORS, previously organized network atomic services are written into distributed databases. The cloud controllers subscribe accordingly, so that the logical topology (including network paths and relevant information of latency and bandwidth) of interconnections between data centers can be grasped. Network paths can be re-orchestrated and binded in accordance with fine-granularity services, achieving differentiated service provisioning.¶
+------------+
+----->+ database +<-----+
| +------------+ |
| |
| |
| |
| .--------.
.-----. ( ) .-----.
( ) .--( )--. ( )
.--( )--. ( SRv6 Core ) .--( )--.
( ) ( ) ( )
( SaaS_A1 )------( DCI Network )------( SaaS_A2 )
( ) .--( )--. ( )
.---------------. ( ) .---------------.
.--------.
TBA¶
TBA¶
TBD.¶