Internet DRAFT - draft-zhou-alto-dbors-requirement-usecase

draft-zhou-alto-dbors-requirement-usecase







ALTO                                                             F. Zhou
Internet-Draft                                                   S. Wang
Intended status: Standards Track                                 D. Yuan
Expires: 25 April 2023                                   ZTE Corporation
                                                         22 October 2022


   Requirements and Use Cases of DB-ORS (Database-based Open Resource
                                Service)
              draft-zhou-alto-dbors-requirement-usecase-00

Abstract

   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.

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 25 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Zhou, et al.              Expires 25 April 2023                 [Page 1]

Internet-Draft         Requirements and Use Cases           October 2022


   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.

Table of Contents

   1.  Requirement Analysis  . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Solution Gap Analysis . . . . . . . . . . . . . . . . . . . .   3
   5.  Scope of DB-ORS . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Cloud Access Scenario . . . . . . . . . . . . . . . . . .   6
     6.2.  DCI Scenario  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  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



Zhou, et al.              Expires 25 April 2023                 [Page 2]

Internet-Draft         Requirements and Use Cases           October 2022


   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.

2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Terminology

   *  DB-ORS: Database-based Open Resource Service

   *  SRv6: Segment Routing over IPv6

   *  MPLS: Multi-Protocol Label Switching

   *  DCI: Data Center Interconnection

4.  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:



Zhou, et al.              Expires 25 April 2023                 [Page 3]

Internet-Draft         Requirements and Use Cases           October 2022


   *  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



Zhou, et al.              Expires 25 April 2023                 [Page 4]

Internet-Draft         Requirements and Use Cases           October 2022


   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.

5.  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.

6.  Use Cases











Zhou, et al.              Expires 25 April 2023                 [Page 5]

Internet-Draft         Requirements and Use Cases           October 2022


6.1.  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.





























Zhou, et al.              Expires 25 April 2023                 [Page 6]

Internet-Draft         Requirements and Use Cases           October 2022


          .-----.                                        .-----.
         (       )                                      (       )
     .--(         )--.                              .--(         )--.
    (                 )                            (                 )
   (      SaaS_A1      )                          (      SaaS_A2      )
  (                     )                        (                     )
   (                   )                          (                   )
    .-----------------.                            .-----------------.
             ^                                              ^
             |                                              |
             |                                              |
       +-----+-----+         +--------------+         +-----+-----+
       |  gateway  +<--------+ Orchestrator +-------->+  gateway  |
       +-----+-----+         +---+---+---+--+         +-----+-----+
             ^                   |   |   |                  ^
             |     +----------+  |   |   |  +----------+    |
             |     | database +<-+   |   +->+ database |    |
          .-----.  +----^-----+      |      +----^-----+ .-----.
         (       )      |            |           |      (       )
     .--(         )-----+            v           +-----(         )--.
    (                 )          +------+          (                 )
   ( underlay network1 )<--------+ edge |-------->( underlay network2 )
    (                 )          +------+          (                 )
     .--(         )--.             ^  ^             .--(         )--.
         (       )                 |  |                 (       )
          .-----.                  |  |                  .-----.
                                   |  |
                        +-------+  |  |  +-------+
                        | APP_1 +--+  +--+ APP_2 |
                        +-------+        +-------+



                     Figure 1: Cloud Access Scenario


6.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



Zhou, et al.              Expires 25 April 2023                 [Page 7]

Internet-Draft         Requirements and Use Cases           October 2022


   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      )
 (                 )        .--(            )--.        (                 )
  .---------------.             (          )             .---------------.
                                 .--------.



                        Figure 2: DCI Scenario


7.  Security Considerations

   TBA

8.  Acknowledgements

   TBA

9.  IANA Considerations

   TBD.

10.  Normative References



Zhou, et al.              Expires 25 April 2023                 [Page 8]

Internet-Draft         Requirements and Use Cases           October 2022


   [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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Fenlin Zhou
   ZTE Corporation
   No.50 Software Avenue
   Nanjing
   Jiangsu, 210012
   China
   Email: zhou.fenlin@zte.com.cn


   Sheng Wang
   ZTE Corporation
   No.50 Software Avenue
   Nanjing
   Jiangsu, 210012
   China
   Email: wang.sheng7@zte.com.cn


   Dongyu Yuan
   ZTE Corporation
   No.50 Software Avenue
   Nanjing
   Jiangsu, 210012
   China
   Email: yuan.dongyu@zte.com.cn















Zhou, et al.              Expires 25 April 2023                 [Page 9]