Database-based Open Resource Service Framework

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

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
VDLink: Virtual Direct Link
VTLink: Virtual Tunnel Link
SID: Segment Identifier
CPE: Customer Premise Equipment
DCI: Data Center Interconnection

DB-ORS Framework and Key Components

DB-ORS Framework Description 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.

DB-ORS Framework The key components are introduced as follows.

Network controller: the controller for the network domain, whose specially assigned duty in this framework is to draw an abstraction towards network basic physical functions like link and tunnel by extracting key attributes while neglecting unnecessary details, and further encapsulate them into a series of virtual services. Each service can be treated as an unique atomic element without interfering any other services.
Cloud-Network Orchestrator: an orchestrator for both the network domain and the cloud domain.
Database: a distributed Key-Value database owned by the Cloud-Network orchestor and shared by both the cloud and Network, with the publish/subscribe mechanism.
Application Terminal and CPE: terminals and customer premise equipment which turn out to be service customers, which subscribe their required services from the database.

The key interfaces are introduced as follows.

The Northbound Interface (NBI) of the Network Controller: the network capabilities and physical functions is abstracted and exported via this interface to the distributed database, which will be translated into key-value schemes.
The Southbound Interface (SBI) of the Network Controller: the network physical topology and fine-granular network information are enforced via this interface from the underlay network. The candidate protocols for this interface are PCEP, BGP, YANG-based protocols, etc.

DB-ORS Implementation Procedures 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.

DB-ORS Handling Requirements 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 , fine-granular service provisioning and enhanced resources utilization is urgently required. Thus, DB-ORS handles the mentioned requirements:

With network capabilities abstracted as atomic services, fine-granularity service identification, provisioning can be achieved.
With services subscribed by orchestrators, explicit information of the network domain reveals which enables intelligent traffic orchestration and scheduling and increases network resources utilization.
Since the database communicates the network domain and the cloud and the inherent publish/subscribe mechanism, the communication framework is flattened and thus the interactions is relatively simplified which brings a profound integration and convergence of cloud and network.

Illustration and Designs

Services Abstraction 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:

virtual direct link (VDLink)
virtual tunnel link (VTLink)

VDlink VDLink is a virtual direct link abstracted from a physical direct link. With the definition physical direct link of BGP-LS in , 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 . The definitions of Minimal Unidirectional Link Delay, Maximal Unidirectional Link Delay and Unidirectional Link Loss are illustrated in . The definitions of End.X SID are stated in and .

VTlink 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 , , and . 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.

Link Identification 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.

Format of Virtual Link Identifier

Link Employment 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.

Services Publishing 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:

VDLink: As described in 5.1.1.
VTLink: As described in 5.1.2.
Cross domain link: The bearer network collects the following information about the link between the network and cloud gateway which is a cross AS link and writes it into the database, including: cross domain link ID, source node ROUTEID, source AS, destination node ROUTEID, destination AS, PeerNode SID, PeerAdj SID, local interface address, remote interface address, delay, bandwidth, packet loss rate, TE metric.
Node: The information of head node and tail node in a real layer 3 link, including, IGP ROUTE ID, AS index, etc.

Services Orchestration 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 . 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 , and the network edge router forwards it according to the SAN-ID matching the required network path in reference to and .

Use Cases

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

A Cloud-Network orchestrator is deployed over the network and cloud domain, and a key-value sheme database is configured. The cloud controller informs the running status of computing resources and service SLA requirements to the database.
The bearer network allocates exclusive resource for the cloud application which is abstracted as open atomic services like VTLink and is further written into the database.
Based on the information collected from the cloud and the network, the Cloud-Network orchestrator implements path calculation, generates appropriate SRv6 policies and assigns a unique SAN-ID to bind respective policies. Then, the SRv6 policy and SAN-ID are written into the database in a key-value scheme.
Terminals to access the cloud obtains a specific SAN-ID from the database by subscription while the bearer network controller obtains the SRv6 policy and SAN-ID and advertises the information to all edge routers which serve as traffic entrance by BGP, NETCONF or other feasible means.
Service traffic to the cloud sent from the terminal is encapsulated with SAN-ID at CPE. When receiving a packet, edge routers of the bearer network match a specific policy by the identified SAN-ID, and forward the packet to the gateway of the cloud.

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

DCI Scenario As shown in Figure 4, When data centers interconnects with each other, the orchestration process within the architecture of DB-ORS mainly includes:

Based on the demand for the interconnection between data centers, the bearer network allocates exclusive resources respectively which are abstracted as atomic services and stored in a key-value scheme database.
Respective controllers subscribe concerning information, and observes variations promptly including additions, deletions and modifications.
Controllers perform analysis through the unified schema template to obtain the latest network atomic services like VTLink and VDLink. Based on the latest visible topology within both the inner and outer domain of the cloud, the re-orchestration and path calculation can be achieved for the interconnection between data centers.

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

Security Considerations 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.

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

Acknowledgements TBA.

IANA Considerations TBA.