Internet-Draft Service Routing Based on Databases October 2022
Zhou & Yuan Expires 13 April 2023 [Page]
Workgroup:
INTAREA
Internet-Draft:
draft-compute-aware-advertise-route-san-database-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
F. Zhou
ZTE Corporation
D. Yuan
ZTE Corporation

Computing Status Awareness, Advertisement and Service Routing methods of SAN Based on Databases

Abstract

This draft proposes a unified method to perceive and advertise the running status of computing resources in a Service Awareness Network by introducing a distributed database. The forwarding operation in a fine-grained service routing policy is correspondingly defined which is completely decoupled from conventional IP routing. In the scheme proposed, the impact of high frequency changes of computing resources is avoided and the compatibility of the network is enhanced.

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

Table of Contents

1. Introduction

With computing resource continuously migrating to edges, services residing distributedly turns to be delivered in a dynamic way. More fine-grained networking policies awaring of service SLA requirements are urgently required.

As illustrated in [I-D.huang-service-aware-network-framework], a typical SAN framework consists of service client, service server, SAN ingress, SAN relay and SAN egress. A fine-grained networking policy can be achieved through successive procedures:

The mentioned procedures are shown in Figure 1:


                            (1)Perception<---------------------+
                                   |                           |
                                   v                           |
                           (2)Advertisement                    |
                                   |                  Status of|
                   +---------------+--------------+   Computing|
                   |               |              |   Resources|
                   v               v              v            |
                                                               |
      (3)Service Routing                                       |
+-------+ -------->                                        +-------+
|Service|    +-----------+   +----------+   +----------+   |Service|
|       +----+SAN Ingress+---+SAN  Relay+---+SAN egress+---+       |
|Client |    +-----------+   +----------+   +----------+   |Server |
+-------+          |                                       +-------+
    |              |                                           |
    |              |                                           |
    |              |<-----SAN Fowarding and Routing Domain---->|
    |                                                          |
    |                                                          |
    |<---------------Service Identification Domain------------>|

Figure 1: Computing Resource Perception and Advertisement in SAN

Since the perception and advertisement procedures are the premises to achieve service routing, enabling the network to be aware of the running status timely is regarded to be a significant problem.

Currently, the perception of computing resources can be commonly achieved by application protocols, FTP for instance. With the connection between clients and the server establishd, the cloud side is required to spontaneously upload the running status of computing resources. The process of advertising computing resource information is commonly fulfilled by extending IGP or BGP. Packets with a designated format carrying information of computing resources flood in the network to complete the learning process.

In current schemes, service routing is strongly coupled with traditional IP routing which results in the following deficiencies:

According to the analysis above, the following problems are required to be solved:

This draft proposes computing resources perception and advertisement method by introducing a distributed database to fulfill service routing decoupled from conventional IP routing.

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

4. The Perception of the Status of Computing Resources

The computing resources information of the cloud-side server is used to reflect the performance and a running status of resource pools. It is obtained to facilitate unified collaborative invocation of computing power resources.

It is noted that identical services can be provided by multiple resource pools which connects to different gateways and status of resource pools varies from each other. Thus, the description of computing resource may include the following attributes as shown in Figure 2:


+------------+-----------------+-----------------------------------+
|   SAN ID   | Service Gateway |  Service Descriptions Index(1-n)  |
+------------+-----------------+-----------+-----------+-----------+
| Service  1 |       GW1       |   CPU 1   | Memory  1 |   O/I 1   |
+------------+-----------------+-----------+-----------+-----------+
| Service  2 |       GW2       |   CPU 2   | Memory  2 |   O/I 2   |
+------------+-----------------+-----------+-----------+-----------+
| Service  3 |       GW2       |   CPU 3   | Memory  3 |   O/I 3   |
+------------+-----------------+-----------+-----------+-----------+
| Service  3 |       GW3       |   CPU 4   | Memory  4 |   O/I 4   |
+------------+-----------------+-----------+-----------+-----------+
| Service  1 |       GW3       |   CPU 5   | Memory  5 |   O/I 5   |
+------------+-----------------+-----------+-----------+-----------+

Figure 2: Status Table of Computing Resources

Since the status of computing resources can be modeled as a collection of key-value pairs with keys as unique identifiers, this draft introduced a distributed database to store and update the running status. As shown in Figure 2, a service identification defined as a SAN ID(Service ID) in [I-D.service-identification-header-of-san] to represent a globally unique service semantic identification and its connected gateway should be configured as the key for the extracted data model.

A distributed system has the advantages of advanced performance, high availability and simple extensibility. It is highly partitionable and allows horizontal scaling which satisfies the practical scenarios of large scale of service instances. Also, both keys and values can be anything from simple objects to complex compound objects, and thus heterogeneous computing resources can be described and stored.

After the key-value pairs are extracted and further written into the database by the cloud side as multiple DB-Agents, the perception of the status of computing resources is fulfilled.

5. The Advertisement of the Status of Computing Resources


+-------------+
|   +--------+|                      +-----------------------------+
|VM |Database||<---------------------|           DB-Agent          |
|   +--------+|        Write         |                             |
+-------------+                      |                 +---------+ |
       | Read                        |        +--------+Service 1| |
       v                             |        |        +---------+ |
+----------------------+             | +------+------+             |
|       DB-Agent       |             | |Load Balancer|   ......    |
|                      |             | +------+------+             |
| +----+        +----+ |             |        |        +---------+ |
| |PE 1| ...... |PE n| |             |        +--------+Service n| |
| +----+        +----+ |             |                 +---------+ |
|                      |             |                             |
| Network Edge Devices |             |             Cloud           |
+----------------------+             +-----------------------------+

Figure 3: The status of computing resources learning procedures

With the introduction of a distributed database, the data of the computing resources can be stored in hierarchically organized directories. A typical form is described as below:

As shown in Figure 3, a group of edge devices in the network domain observes the key value information through a publish-subscribe mechanism. Specific keys or directories can be watched for changes and multiple clients can react to changes in values. Since multiple edge devices simultaneously observe the variations, the running status is advertised to all edge devices. It is concluded that, by introducing a database, functions of perception and advertisement are unified.

It can be understood that in the mentioned writing and reading process, there is no necessity to perform additional authentication on a management protocol and network layer protocols, thereby simplifying the overall procedure.

6. Service Routing Decoupled from IP Routing


+-----------------------------+
|           DB-Agent          |
|+---------------------------+|
||    Computing Resource &   ||
||    Network  Information   ||
||     Perception  Module    ||
|+---------------------------+|
+-----------------------------+
              |                    +-------------------------+
              |<-------------------|    Networking Policy    |
              |                    +-------------------------+
              |                    +-------------------------+
              |<-------------------|Service Addressing Policy|
              |                    +-------------------------+
              v
  +-----------------------+                    +------------------+
  | Service Routing Table +<------------------>+ IP Routing Table |
  +-----------------------+                    +------------------+

Figure 4: Service Routing Decoupled from IP Routing

As shown in Figure 4, after the current computing status is obtained, a proper resource pool can be selected to satisfy the service SLA requirements, so as to quickly and accurately guide data forwarding. Together with path metrics in the network, a specific service routing table is formulated.

Since the service routing table is generated additionally, it is completely decoupled from the conventional IP routing table. As shown in Figure 5, for services with requirements for computing resources, the service routing table maps to the IP routing table to complete a forwarding operation. With the service gateway determined, an Interface IP or an SRv6 policy can be indexed. For conventional services which are not sensitive to computing resources, a forwarding operation can be implemented simply in the original way.


      Service Routing Table                 IP Routing Table
+------------+-----------------+    +---------------+--------------+
| Service ID | Service Gateway |    |Prefix(Gateway)|   Next Hop   |
+------------+-----------------+    +---------------+--------------+
| Service  1 | GW1 (Node SID1) |<-->|      GW1      | Interface IP |
+------------+-----------------+    +---------------+--------------+
| Service  2 | GW2 (Node SID2) |    |               | SRv6  Policy |
+------------+-----------------+<-->|      GW2      |  (Endpoint+  |
| Service  3 | GW2 (Node SID2) |    |               |    Color)    |
+------------+-----------------+    +---------------+--------------+

Figure 5: Service Routing Table Maps to IP Routing Table

With the introduction of a distributed database, the service routing procedure is decoupled from traditonal IP routing which enhances the compatibility of different services carried in the network.

7. Use Case

As shown in Figure 6, suppose CPU load is a sample attribute and 70% is configured to be a threshold. If the CPU load beyonds 70%, the traffic needs to be steered to another satisfied resource pool .

The procedure of learning and processing updated computing resource status is described as follows:


      Network Domain                             Cloud Domain
+-------------------------+                +-----------------------+
|+------------+ +--------+|   +--------+   |+--------+ +----------+|
||Edge Devices| |DB-Agent||   |Database|   ||DB-Agent| |Cloud Side||
|+------------+ +--------+|   +--------+   |+--------+ +----------+|
+-------------------------+                +-----------------------+
        |            |             |<-------------|           |
        |            |             |              |           |
        |            |  watch      | (/Service    |           |
        |            |  (/Service  | Instances/   |           |
        |            |  Instances  | CPU Load 70) |           |
        |            |  prefix/)   |              |           |
        |            |------------>|              |           |
        |            |             |              |           |
        |            |<------------|              |           |
        |            |  notify     |              |           |
        |notify      |  (/Service  |              |           |
        |(/Service   |  Instances  |              |           |
        |Instances/  |  prefix/)   |              |           |
        |SAN ID/     |             |              |           |
        |CPU Load 70)|             |              |           |
        |<-----------|             |              |           |
        |            |             |              |           |

Figure 6: An Example of Database-Based Computing Resource Perception Procedure

8. Security Considerations

TBA

9. Acknowledgements

TBA

10. IANA Considerations

TBA

11. Normative References

[I-D.huang-service-aware-network-framework]
Huang, D. and B. Tan, "Service Aware Network Framework", Work in Progress, Internet-Draft, draft-huang-service-aware-network-framework-00, , <https://www.ietf.org/archive/id/draft-huang-service-aware-network-framework-00.txt>.
[I-D.service-identification-header-of-san]
Ma, L., Zhou, F., and H. Li, "Service Identification Header of Service Aware Network", Work in Progress, Internet-Draft, draft-service-identification-header-of-san-00, , <https://www.ietf.org/archive/id/draft-service-identification-header-of-san-00.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

Fenlin Zhou
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Dongyu Yuan
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China