Service Information Updating in Computing and Network Convergence

Abstract

This document introduces a service information updating method in the scenario of computing and network convergence.¶

1. Introduction

One of the evolvement directions of the network is to converge with the service. In the scenarios of Computing and Network Convergence (CNC) or Computing Force Network (CFN), the network is aware of the service information, and can make a better choice in the traffic steering. In this situation, both the network metric and the service-specific metric are considered instead of only the network metric. Thus, the network resource and the computing resource can be utilized more efficiently.¶

In fact, the scheduling mechanism in the cloud scenarios can also support load balance according to the load of different servers for the same service. However, the decision point for the traffic steering is relatively high. The mechanism described in [I-D.li-dyncast-architecture] can support that the decision point is on the network node. One of the advantages of this mechanism is that the network node is on the data path, and can respond more quickly than the centralized mechanism.¶

However, this cross-layer designation may cause some problems as mentioned in [I-D.liu-dyncast-ps-usecases]. One of the problems is that the service-specific metric is more dynamic. It is hard to refresh the status on the network nodes frequently.¶

In this document, we introduce a mechanism that can update service information on the network nodes more efficiently. In the mechanism, we notify the service information on the control plane, and for some parameters that change frequently, we refresh them on the data plane.¶

2. General Procedure

As described in Figure1, the MEC1/2/3 can all support Service1, and announce the anycast IP address <ServiceID1>. In the network, the ingress node will have the route for <ServiceID1>. According to the current anycast mechanism, one of the egress nodes will be the next hop for the <ServiceID1> on the ingress. For example, Egress2 is the next hop on the ingress node for the <ServiceID1>.¶

                                           _______       _______
                 _________________________|       |     |       |
                |                         |Egress1| --- |  MEC1 |
                |                         |       |     |       |
                |                          -------       -------
                |                               |         Service1
    ______     _______                     _______       _______
   |      |   |       |                   |       |     |       |
   |Client|---|Ingress|                   |Egress2| --- |  MEC2 |
   |      |   |       |                   |       |     |       |
    ------     -------                     -------       -------
                |                               |         Service1
                |                          _______       _______
                |                         |       |     |       |
                |                         |Egress3| --- |  MEC3 |
                |                         |       |     |       |
                |                          -------       -------
                |              Network          |        Service1
                 -------------------------------

   Figure 1: Load balance among MECs in CNC or CFN

In the first step, the client which wants to access Service1 will send a packet with the <source, destination> pairs as <ClientIP, ServiceID1>.¶

In the second step, the Ingress node receives the packet, and encapsulates the packet in a tunnel as <IngressIP, EgressIP2><ClientIP, ServiceID1>.¶

In the third step, the Egress2 decapsulates the packet and send it to the MEC2.¶

In the fourth step, the server in the MEC2 will response a packet with the <source, destination> pairs as <ServerIP2, ClientIP>. Here, the source address is a normal IP address, and is not the anycast address.¶

In the fifth step, the Egress2 encapsulates the packet in a tunnel as <EgressIP2, IngressIP><ServerIP2, ClientIP>.¶

In the sixth step, the Ingress decapsulates the packet and send it to the MEC2, with the <source, destination> pairs as <ServerIP2, ClientIP>.¶

In the seventh step, the client receives the packet, correlates with the packet <ClientIP, ServiceID1>, and then uses <ServerIP2> as the destination address to continue the communication.¶

The main point of the CNC is in Step 2. In the current mechanism, the target for <ServiceID1> is relatively static. In the CNC, the Ingress should support dynamic load balance according to the computing load in MEC1/2/3, and the latency to the Egress1/2/3.¶

For example in the CNC, if the MEC2 has a heavy load, the Ingress may steer the traffic with the destination address <ServiceID1> to Egress1/3.¶

3. Service Information Informing on the Control Plane

In the CNC mechanism, the Egress1/2/3 should be able to collect the load information for ServiceID1, and inform the service information to the Ingress on the control plane. For example, the service information can be carried in the BGP message that announces the anycast IP address <ServiceID1>.¶

However, if the load information for ServiceID1 changes frequently, we should not send too many BGP messages into the network.¶

4. Service Information Updating on the Data Plane

In this document, we suggest updating the service information that changes frequently based on the data plane programming. The reason is that it is more efficient to do this kind of simple and repeated actions on the data plane.¶

For example, the Egress 1/2/3 can monitor the packets targeting to the Ingress, and add the service information in the DoH of the packets [RFC4291]. Then, the Ingress can monitor the changes of the load of Service1 in the MECs. Other insertion methods can also be considered here. The information can also be inserted by the server into some place of the IPv6 extension headers.¶

8. References