Coordination for Service IP in Multi-access Edge Computing

In Computing Aware Networking (CAN), the network nodes need to be aware of the statues of the service, so as to do a more reasonable Load Balancing (LB) job in a distributed way for the service as mentioned in and . In this situation, the destination address of a CAN packet is a service IP or called a service ID, because it is not only an IP address for the location, but also an ID related to a specific service. In CAN, it is assumed that multiple places including the cloud and the MECs in the network have deployed a specific service, and multiple places will announce the route for the service IP which works as an anycast address. In the traditional anycast mechanism, the network will forward an anycast packet to a nearest server normally in a cloud without considering whether the server is busy or not. In the MEC scenarios, the computing ability is limited, and thus there is a higher possibility that the server is busy in the MEC. Therefore, in the CAN mechanism, the anycast mechanism is extended to enable the network to be aware of the service information, so as to make a better LB. However, comparing to the centralized mechanism, in which we assume that a central scheduler is aware of all the service statuses in different places, the distributed mechanisms in CAN are short of coordination abilities among different service places. In this document, we introduce a mechanism to coordinate different service points that are providing the same service associated with the service IP, and thus can improve the resource utilization.

We assume that three servers in different MECs are providing the same service associated with the same service IP. In the CAN mechanism, the Ingress node in the network can obtain the service information, and forward the CAN packet targeted to the Server IP to a proper Egress and server.

In the CAN mechanism, the Egress nodes can obtain the service information in the MEC. The Ingress can obtain the service information from the Egress nodes by using BGP for example. Thus, the Ingress node can make a LB with considering both the network and the service information. The information on the Ingress will be updated continuingly, so that if a specific server is heavy load, the Ingress node can change the target Egress and server. In the situation that many clients are accessing the Service1, the Ingress node will make a LB among the servers in different MECs because the "best" server is dynamic. If there are fewer clients of Service1, an MEC, such as MEC3, may close the Service1 instance, so that it can provide other services better or save the electricity. In this situation, the Ingress node will not forward any CAN packet to Egress3. However, if there are more clients need to access Service1 in the network again, we need to reactivate the Server3. In a centralized mechanism, a central scheduler can reactivate the Server3 after detecting the load statuses of the Server1 and the Server2. As a comparison, we have no mechanism currently to reactivate the Server3 in the MEC3 in the distributed scenarios in which we do not have a central scheduler that knows all the statuses.

In fact, the Egress3 or the Ingress can monitor the computing or service load information for Service1 announced by the Egress1 and the Egress2. After it detects the MEC2 and the MEC3 are both heavy load, it can trigger the reactivation of the Service1 in the Server3. As we announce the service information from Egress nodes to Ingress nodes by using BGP , we need to support the trigger in BGP, too. In addition, if the Egress and the gateway of the MEC are also communicating the service information by using BGP, the Egress can also send the reactivation trigger to the gateway. For the reactivation trigger, we propose a general mechanism by using BGP for it. The main procedures are as follows: Step1: Egress1 and Egress2 will notify that they can support Service1 and the service information, such as the server load. Egress3 should notify that it can support Service1, but it is inactive now. Step2: After receiving the information from the Egress nodes, accordingly, Ingress will only use the Egrees1 and Egress2 to make the LB process. Step3: When necessary, the decision point, which wants to active the Service1 in the Server3, triggers the reactivation of the Service1 in the Server3 by sending a message to Egress3. Further, the Egress3 may trigger the reactivation of the Service1 in the Server3 by sending a message to the gateway of the MEC3. The way of communications between the gateway and the Server3 is out of scope of this document. Step4: The Service1 instance is reactivated in the Server3, and the Egress3 receives the service information in the Server3. Step5: Egress3 notifies the Ingress that it can support the Service1, and the related service information. In the notification, the active Flag should be changed from inactive to active. Step6: After receiving the information from the Egress3, accordingly, Ingress will use the Egrees1, Egress2, and Egress3 to make the LB process. As there is no message for service reactivation in BGP currently, we suggest enhancing the BGP Refresh message to notify the service reactivation demand. In this situation, the enhanced BGP Refresh message should target to a specific service IP, and a specific Flag should be occupied to indicate the service reactivation demand.

TBD.