Internet DRAFT - draft-du-coordination-for-serivce-ip-in-mec
draft-du-coordination-for-serivce-ip-in-mec
Network Working Group Z. Du
Internet-Draft China Mobile
Intended status: Informational 16 January 2023
Expires: 20 July 2023
Coordination for Service IP in Multi-access Edge Computing
draft-du-coordination-for-serivce-ip-in-mec-00
Abstract
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 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 20 July 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Du Expires 20 July 2023 [Page 1]
Internet-Draft Coordination for Service IP in MEC January 2023
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Coordinatable CAN . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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.
Du Expires 20 July 2023 [Page 2]
Internet-Draft Coordination for Service IP in MEC January 2023
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.
Du Expires 20 July 2023 [Page 3]
Internet-Draft Coordination for Service IP in MEC January 2023
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.
Du Expires 20 July 2023 [Page 4]
Internet-Draft Coordination for Service IP in MEC January 2023
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
TBD.
5. Security Considerations
TBD.
6. Acknowledgements
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
DOI 10.17487/RFC4217, October 2005,
<https://www.rfc-editor.org/info/rfc4217>.
7.2. Informative References
[I-D.liu-can-gap-reqs]
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, 23 October 2022,
<https://www.ietf.org/archive/id/draft-liu-can-gap-reqs-
00.txt>.
[I-D.liu-can-ps-usecases]
Liu, P., Eardley, P., Trossen, D., Boucadair, M.,
Contreras, L. M., Li, C., and Y. Li, "Computing-Aware
Du Expires 20 July 2023 [Page 5]
Internet-Draft Coordination for Service IP in MEC January 2023
Networking (CAN) Problem Statement and Use Cases", Work in
Progress, Internet-Draft, draft-liu-can-ps-usecases-00, 23
October 2022, <https://www.ietf.org/archive/id/draft-liu-
can-ps-usecases-00.txt>.
Author's Address
Zongpeng Du
China Mobile
No.32 XuanWuMen West Street
Beijing
100053
China
Email: duzongpeng@foxmail.com
Du Expires 20 July 2023 [Page 6]
