Internet-Draft Coordination for Service IP in MEC January 2023
Du Expires 20 July 2023 [Page]
Network Working Group
Intended Status:
Z. Du
China Mobile

Coordination for Service IP in Multi-access Edge Computing


This document describes a coordinatable mechanism for the Service IP in Multi-access Edge Computing. The Service IP means that an IP address is associated with a specific service in the network. For example, the IP address is deployed as an anycast address for Computing Aware Networking (CAN).

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

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

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 20 July 2023.

Table of Contents

1. Introduction

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 [I-D.liu-can-gap-reqs] and [I-D.liu-can-ps-usecases]. 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.

2. Problem Statement

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.

 +--------+   +---------+   +-------+   +---------+   +----------------+
 | Client |---| Ingress |---| Nodes |---| Egress1 |---|  MEC1 (Server1 |
 +--------+   +---------+   +-------+   +---------+   | with Service1) |
                             |   |                    +----------------+
                             |   |      +---------+   +----------------+
                             |   |------| Egress2 |---|  MEC2 (Server2 |
                             |          +---------+   | with Service1) |
                             |                        +----------------+
                             |          +---------+   +----------------+
                             |----------| Egress3 |---|  MEC3 (Server3 |
                                        +---------+   | with Service1) |
  Figure 1: Topology for the Coordinatable CAN network in which the
              servers in the MEC can be active or inactive

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.

3. Coordinatable CAN

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 [RFC4217], 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.

4. IANA Considerations


5. Security Considerations


6. Acknowledgements


7. References

7.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, DOI 10.17487/RFC4217, , <>.

7.2. Informative References

Liu, P., Jiang, T., Eardley, P., Trossen, D., Li, C., and D. Huang, "Computing-Aware Networking (CAN) Gap Analysis and Requirements", Work in Progress, Internet-Draft, draft-liu-can-gap-reqs-00, , <>.
Liu, P., Eardley, P., Trossen, D., Boucadair, M., Contreras, L. M., Li, C., and Y. Li, "Computing-Aware Networking (CAN) Problem Statement and Use Cases", Work in Progress, Internet-Draft, draft-liu-can-ps-usecases-00, , <>.

Author's Address

Zongpeng Du
China Mobile
No.32 XuanWuMen West Street