| Internet-Draft | DB-ORS Framework | October 2022 |
| Zhou, et al. | Expires 25 April 2023 | [Page] |
This document proposes the framework of Database-based Open Resource Service. It contributes to the overall integration of network and cloud by providing fine-granularity differentiated services and increasing resource utilization rate over the cloud and network.¶
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.¶
With the rapid development of cloud computing and profound utilization of mobile Internet, the cloud has become an increasingly popular platform for hosting software applications and daily information in a variety of domains such as e-retail, finance, news, and social networking. The demand to connect the clouds accelerates urgently for not only enterprises and companies but also government departments which leads to rapid growth of traffic between terminals and clouds or different data centers.¶
However, gaps exist among current solutions including complexity in configuration, time-consuming provisioning cycle, constrained access and coarse-granularity services provisioning as clarified in [I-D.zhou-alto-dbors-requirement-usecase] .¶
Therefore, a systematic architecture to perform integrated operation of clouds and the network for future scenarios which is defined as Database-based Open Resource Service is proposed in this draft, aiming to provide fine-granularity differentiated services and increase resource utilization rate over the cloud and network.¶
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.¶
Network functions are possible to be shared as services by abstracting and encapsulating its resources. Applications subscribe services on their interests and further binds them, so as to satisfy the fine-gained SLA requirements in the context of multiple clouds connected by a unique network area.¶
DB-ORS abstracts the atomic service capabilities of the network and by introducing common database techniques, realizes service delivery which merely requires single point access. DB-ORS expands and enhances perception abilities of the network by successive procedures including the abstraction of services and capabilities, service publishment and re-orchestration of network services which is shown in Figure 1.¶
+---------------------+ +--------------------+
| | +--------------------+ |
| Cloud-Network | | | |
| Orchestrator | | Cloud Application's| |
| | | Terminal / CPE | |
+---------------------+ | |-+
| ^ +--------------------+
v | ^
+------------+ Subscribe |
| |-------------------------+
| Database |-----------------------+
| |<--------------------+ |
+------------+ | |
| ^ | |
| | Network Cloud | |
Subscribe | | Information Information | | Subscribe
| | Export Export | |
v | | |
+-------------------------+ | | .-------.
| Network Controller | | v( )
| | .-------. )
| Atomic Resource Services| ( ) )--
| +-------------------+ | ( ) Cloud 2 )
| | VDLink | | --( )-- )
| | VTLink | | ( Cloud 1 ) )
| +-------------------+ | ( ) )
| ^ | ( Cloud Controller ) )
| |Abstraction | ( +-----------------+ ) )
| | | ( | Computational | ) )
| Basic Physical Functions| ( | Scheduling | ) )
| +--------------------+ | ( | | ) )
| | Physical Link | | ( | Data Center | ) )
| | Tunnel | | ( | Interconnection | ) )
| +--------------------+ | ( +-----------------+ ) )
+-------------------------+ ( ^ ) )
^ ( | ) )
| ( v ) )
v ( +-----------------+ ) )
+-------------------------+ ( | Cloud Resources | ) )
| | ( +-----------------+ ) )
| Underlay Networks | ( )---'
| | ( )
+-------------------------+ '-----------------'
The key components are introduced as follows.¶
The key interfaces are introduced as follows.¶
The network controller in the bearer network processes the service abstraction of network capabilities which translates basic networking functions into a series of open atomic services. The outcoming atomic services of bearer network are modeled by applying a key-value scheme and further stored into a designated database. Here, distributed databases, ETCD for instance, are recommended for which sustains strong consistency among its operators or visitors. Since the bearer network and cloud applications commonly communicates with the database, a typical subscribe/publish mechanism is applied. To be noted, the unification of a specific key-value scheme is indispensable since multiple manufacturers of network devices and cloud providers are possible to be involved and released information needs to be identified by every participants. So a schema description file is proposed and utilized to unify various descriptions as a template.¶
The cloud controller subscribes the updated information of network's atomic services published by the network which stored in the database, and further parses them out referring to the schema description file. Then the cloud controller rearrange and bind the services according to designated principles. Mapping relationships and updated results can also be informed back to the database in need.¶
Currently, clouds communicate with the network through specific interfaces, Restful for instance. Since the cloud and the network locates in separate domains, third-party infrastructures addressed as super controllers is highly demanded to orchestrate traffic bi-directionally. When a newly registered service capability is provided by the network to deliver to the cloud, a respective application program interface (API) is required which has deficiencies in scalability and simplicity. Also, as analyzed in [I-D.zhou-alto-dbors-requirement-usecase] , fine-granular service provisioning and enhanced resources utilization is urgently required. Thus, DB-ORS handles the mentioned requirements:¶
Cloud applications are regarded to be important customers of bearer network. In order to meet the customized requirements from different cloud applications at the same time, the bearer network needs to reserve link resources (layer 2) or topology resources (layer 3) in advance respectively, and enable the corresponding cloud applications to invoke the resources allocated to them exclusively.¶
The resources reserved by the bearer network can be abstracted into the following atomic services:¶
VDLink is a virtual direct link abstracted from a physical direct link. With the definition physical direct link of BGP-LS in [RFC7752] , VDLink is identified by local node descriptor, remote node descriptor, local interface address, remote interface address, and other fields about its resource capabilities.¶
The attributes of VDLink include: Logic ID, Local Node Descriptor, Local Node Interface Address, Remote Node Descriptor, Remote Node Interface Address, Minimal Unidirectional Link Delay, Maximal Unidirectional Link Delay, Maximal Reservable Link Bandwidth, Unidirectional Link Loss, IGP Metric, TE Metric, END.X SID. The definitions of Logic ID, Local Node Descriptor, Local Node Interface Address, Remote Node Descriptor, Remote Node Interface Address, Maximal Reservable Link Bandwidth, IGP Metric and TE Metric are described in [RFC7752] . The definitions of Minimal Unidirectional Link Delay, Maximal Unidirectional Link Delay and Unidirectional Link Loss are illustrated in [RFC8571] . The definitions of End.X SID are stated in [I-D.ietf-idr-bgpls-srv6-ext] and [RFC9086] .¶
VTLink is a virtual tunnel. There are multiple tunnel types over different dataplanes and SRv6 dataplane is analyzed as an instance in this draft. A VTLink can be abstracted from a SRv6 policy tunnel and its attributes include: Logic ID, Local Node Descriptor, Remote Node Descriptor, Minimal Unidirectional Link Delay, Maximal Unidirectional Link Delay, Maximal Reservable Link Bandwidth, Unidirectional Link Loss, IGP Metric, TE Metric, Binding SID. The definitions of mentioned attributes are described in [RFC7752] , [RFC8571] , [I-D.ietf-idr-bgpls-srv6-ext] and [RFC9086] .¶
Among them, Maximal Reservable Link Bandwidth is the maximum constrained bandwidth in SRv6 Policy reserved for the VTLink. It should be substracted from physical bandwidth when any VTLink is allocated, which is similar to the process in VDLink.¶
Minimal/Maximal Unidirectional Link Delay is the accumulation of the minimal/maximal delay of each node and each segment in segment-list. If multiple sigment-lists are applied, the largest accumalation among all segment-lists is adopted.¶
IGP Metric is the accumulation of IGP metric of each segment in segment-list. If there are multiple segment-lists in a path, the largest accumulation among all segment-lists is adopted.¶
TE Metric is the accumulation of TE metric of each segment in segment-list. If there are multiple segment-lists in a path, the largest accumulation among all segment-lists is adopted.¶
Unidirectional Link Loss is the quotient of the total packets lost in each segment in segment-lists divided by the total number of sent packets. If there are multiple segment-lists in a path, the largest quotient among all segment-lists is adopted.¶
Regarded as a virtual SRv6 policy tunnel, VTLink can be abstracted as a link whose granularity is optional according to service scenario. For instance, for the scenarios of interconnection between data centers, the number of required nodes orchestrated in the segment-list is 2 or 3. However, fulfillment of communications between a teminal and applications in clouds, a VTLink may be a complete SRv6 policy path, and the number of required nodes orchestrated in the segment-list may reach 10.¶
To facilitate path calculation and routing in cloud, a new logic-id is defined to identify a VDLink or VTLink. The logic-id should be globally unique in the network domain. Its data type is unsigned integer.¶
The format of virtual link identifier is shown below.¶
Bit 0 to 4: Cloud-ID (CI), which is used to differentiate applications (such as different cloud service providers).¶
Bit 5 and 6 are reserved bits for future usage.¶
Bit 7: Link Type(LT), value 0 stands for VDLink while value 1 stands for VTLink.¶
Bit 8 to 31: the value of Logic-id, thich ranges from 1 to 16777215 and value 0 is reserved.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cloud-ID|R LT| Logic-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
On the basis of the original physical link, VDLink and VTLink are abstracted, and by identifying designated logic-id and cloud-ID, different virtual links and cloud applications can be distinguished.¶
For a particular virtual link, cloud applications may only focus on the upper bound of the SLA attributes. For example, the maximum value of the original physical link represents the metric and delay. Bandwidth resources of virtual link SHOULD be reserved in the original physical link. Therefore, cloud controller directly orchestrates VDLink and VTLink instead of orginal physical link and a unique network logical topology is constituted for cloud applications.¶
The bearer network models the abstracted network atomic services in a key-value scheme and writes them into a database. Since network devices may be produced by different manufacturers while cloud applications may also be provided from different cloud vendors, network atomic services need to be described in a unified schema in order to enable interoperability among different device manufacturers and cloud vendors.¶
The key-value database adopts publishing/subscription mechanism to publish network atomic services. The information stored and published in the database include but are not limited to:¶
Based on the published network atomic services, unified service orchestration, path calculation and routing can be fulfilled at an integrated layer of the cloud and the network by an overall cloud-network orchestrator as shown in Figure 1.¶
In a typical scenario of data center inteconnection, the cloud have relatively powerful processing capabilities compared to network terminals. When the cloud controller is informed of its lateset assigned virtual links from the bearer network through a subscription scheme, it combines the network information with the collected cloud information and further performs an integrated orchestration. Under current conditions, various services running in the cloud raise respective differetiated requirements for the network. As mentioned above, the cloud is configured as a starting point of the service which also obtains the network open atomic services. After re-orchestration, various paths that satisfy the requirements of different services respectively are calculated. The binding relationship between paths and specific service traffic which help to achieve fine-grained perception for network services.¶
In another scenario when terminals access cloud services, some POP points or terminals do not have sufficient capabilities to process complex calculation. Information about virtual links like VTLink or VDLink will not published to the network domain. As a substitute, the Cloud-Network orchestrator maps virtual links to an specific identifier, namely a SAN-ID described in [I-D.service-identification-header-of-san] . The SAN-ID represents the SLA information of the network, which is published to a terminal or a CPE. The terminal or CPE carries the SAN-ID in the IPv6 packet as described in [I-D.encapsulation-of-san-header] , and the network edge router forwards it according to the SAN-ID matching the required network path in reference to [I-D.computing-segment-for-service-routing] and [I-D.compute-aware-advertise-route-san-database] .¶
As shown in Figure 3, when terminals access the cloud to acquire specific applications, the orchestration process within the architecture of DB-ORS mainly includes:¶
.-----. .-----.
( ) ( )
.--( )--. .--( )--.
( ) ( )
( SaaS_A1 ) ( SaaS_A2 )
( ) ( )
( ) ( )
.-----------------. .-----------------.
^ ^
| |
| |
+-----+-----+ +--------------+ +-----+-----+
| gateway +<--------+ Orchestrator +-------->+ gateway |
+-----+-----+ +---+---+---+--+ +-----+-----+
^ | | | ^
| +----------+ | | | +----------+ |
| | database +<-+ | +->+ database | |
.-----. +----^-----+ | +----^-----+ .-----.
( ) | | | ( )
.--( )-----+ v +-----( )--.
( ) +------+ ( )
( underlay network1 )<--------+ edge |-------->( underlay network2 )
( ) +------+ ( )
.--( )--. ^ ^ .--( )--.
( ) | | ( )
.-----. | | .-----.
| |
+-------+ | | +-------+
| APP_1 +--+ +--+ APP_2 |
+-------+ +-------+
As shown in Figure 4, When data centers interconnects with each other, the orchestration process within the architecture of DB-ORS mainly includes:¶
+------------+
+----->+ database +<-----+
| +------------+ |
| |
| |
| |
| .--------.
.-----. ( ) .-----.
( ) .--( )--. ( )
.--( )--. ( SRv6 Core ) .--( )--.
( ) ( ) ( )
( SaaS_A1 )------( DCI Network )------( SaaS_A2 )
( ) .--( )--. ( )
.---------------. ( ) .---------------.
.--------.
Considering the network domain, revealing internal resources obviously brings security problems that must be considered. The exposure of internal topologies, metrics and other privacies in the network is possible to encounter more malicious attacks. The unawakened security drawbacks within database or cloud will also increase the risk. So security protection measures such as anti DDOS attack methods, network security audit, database anti attack schemes, database intrusion detections, access authorization and verification of the database, and other necessary techniques SHOULD be applied. Specific methods will be discussed in detail in the future.¶
The framework of DB-ORS described in this document takes the cloud and the network as a whole for resource allocation and service orchestration, thus improving the service delivery efficiency and enhancing user experiences. Furthermore, It is easy to expand more opened services beyond the link resource services described in this document, such as topology services, security resource services, and deterministic QoS services, which make the framework of DB-ORS be capable of satisfying future requirements appearing with the trend of the convergence of the cloud and the network.¶
TBA.¶
TBA.¶