Requirements and Use Cases of DB-ORS (Database-based Open Resource Service)

Requirement Analysis 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology

DB-ORS: Database-based Open Resource Service
SRv6: Segment Routing over IPv6
MPLS: Multi-Protocol Label Switching
DCI: Data Center Interconnection

Solution Gap Analysis 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:

Complexity in configuration and maintenance.
Long period of provisioning cycle.
Access constrained by fixed POP points and dependency on network operators.
Coarse-granularity services provisioning.
SD-WAN: Software Defined Wide Area Network

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.

Scope of DB-ORS 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.

Network capabilities abstraction: Abstract the information including underlay network topology, delay, bandwidth, and deterministic attributes, end-to-end service determinism of the network for instance.
Network service publication and subscription: Network services are abstracted in a key-value scheme to a distributed database while applications can subscribe specific services in need.
Network service orchestration: Third party devices, controllers, or orchestrators can be informed of the updated information of corresponding services from the distributed database and further orchestrates the services.

Use Cases

Cloud Access Scenario 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.

Cloud Access Scenario + gateway | +-----+-----+ +---+---+---+--+ +-----+-----+ ^ | | | ^ | +----------+ | | | +----------+ | | | database +<-+ | +->+ database | | .-----. +----^-----+ | +----^-----+ .-----. ( ) | | | ( ) .--( )-----+ v +-----( )--. ( ) +------+ ( ) ( underlay network1 )<--------+ edge |-------->( underlay network2 ) ( ) +------+ ( ) .--( )--. ^ ^ .--( )--. ( ) | | ( ) .-----. | | .-----. | | +-------+ | | +-------+ | APP_1 +--+ +--+ APP_2 | +-------+ +-------+ ]]>

DCI Scenario 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.

DCI Scenario + database +<-----+ | +------------+ | | | | | | | | .--------. .-----. ( ) .-----. ( ) .--( )--. ( ) .--( )--. ( SRv6 Core ) .--( )--. ( ) ( ) ( ) ( SaaS_A1 )------( DCI Network )------( SaaS_A2 ) ( ) .--( )--. ( ) .---------------. ( ) .---------------. .--------. ]]>

Security Considerations TBA

Acknowledgements TBA

IANA Considerations TBD.